RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1291606 - RFE: Add support for filesystem subtypes in SELinux
Summary: RFE: Add support for filesystem subtypes in SELinux
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Ondrej Mosnacek
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On: 1272868
Blocks: 1230671 1256635 1408949 1468983 1563506 1683899
TreeView+ depends on / blocked
 
Reported: 2015-12-15 09:25 UTC by Bipin Kunal
Modified: 2021-09-09 11:44 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1272868
: 1683899 (view as bug list)
Environment:
Last Closed: 2019-02-27 12:05:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bipin Kunal 2015-12-15 09:25:16 UTC
+++ This bug was initially created as a clone of Bug #1272868 +++

Description of problem:

If we mount any fuse filesystem in SELinux environment, SELinux labels it with type "fusefs_t".
SELinux does not understand fuse subsystem, meaning that SELinux only understands FUSE not the actual file system which is built on top of fuse like glusterfs etc.

So as of now all the different available FUSE filesystem are treated as same by SELinux.

And when we try to change the context using chcon command we get "Operation not supported" error as below:

[root@dhcp210-110 mnt]# mount | grep /mnt
10.65.233.230:pure-replica-3 on /mnt type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

[root@dhcp210-110 mnt]# ll -Z 
drwxr-xr-x. root root system_u:object_r:fusefs_t:s0    bipin

[root@dhcp210-110 /]# ps -ax | grep glusterfs | grep selinux
26661 ?        Ssl    0:00 /usr/sbin/glusterfs --selinux --volfile-server=10.65.233.230 --volfile-id=pure-replica-3 /mnt

[root@dhcp210-110 mnt]# chcon -t usr_t bipin/
chcon: failed to change context of `bipin/' to `system_u:object_r:usr_t:s0': Operation not supported  <<---ERROR


While checking for SELinux labeling support for FUSE subsystem, I found that a patch was submitted in Kernel long back and later it was reverted.

Actual patch: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=102aefdda4d8275ce7d7100bc16c88c74272b260

Revert : 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4d546f81717d253ab67643bf072c6d8821a9249c

or

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=29b1deb2a48a9dd02b93597aa4c055a24c0e989f

--- Additional comment from Bipin Kunal on 2015-10-19 02:12:25 EDT ---

---------- Forwarded message ----------
From: Paul Moore <pmoore>
Date: Fri, Oct 16, 2015 at 3:59 AM
Subject: Re: [selinux-internal] Selinux labeling for FUSE subsystem
To: Bipin Kunal <bkunal>, Eric Paris <eparis>
Cc: Daniel J Walsh <dwalsh>, selinux-internal-list, Pranith Kumar Karampuri <pkarampu>, Brian Foster <bfoster>, Niels de Vos <ndevos>

According to Eric the issue is that the sb->s_subtype information isn't
available until after the security_sb_kern_mount() hook.  From spending a
little bit of time looking at the code just now, it appears that the subtype
doesn't get set until after vfs_kern_mount() returns.

It is also a bit annoying that the subtype doesn't appear to be propagated
into vfs_kern_mount() which makes this more difficult.  If we are going to
solve this problem I suspect we will need to change
vfs_kern_mount()/mount_fs() to pass the full fs type string into
security_sb_kern_mount().  Does that sound right to you Eric, or am I missing
something?

--
paul moore
security @ redhat

--- Additional comment from Bipin Kunal on 2015-10-19 02:13:20 EDT ---

---------- Forwarded message ----------
From: Brian Foster <bfoster>
Date: Fri, Oct 16, 2015 at 9:05 PM
Subject: Re: [selinux-internal] Selinux labeling for FUSE subsystem
To: Paul Moore <pmoore>
Cc: Bipin Kunal <bkunal>, Eric Paris <eparis>, Daniel J Walsh <dwalsh>, selinux-internal-list, Pranith Kumar Karampuri <pkarampu>, Niels de Vos <ndevos>

Something like the attached patch, perhaps? Note that this is quickly
hacked together, completely untested and probably not something I would
send upstream as-is. For one, any changes here should probably be
included with the selinux bits for appropriate justification. I'd also
expect to kill the vfs_kern_mount_subtype() hack as that was just for
expediency (but I suppose that could be rfc'd just as well).

Brian

--- Additional comment from Bipin Kunal on 2015-10-19 02:14 EDT ---



--- Additional comment from Bipin Kunal on 2015-10-19 02:14:52 EDT ---

---------- Forwarded message ----------
From: Paul Moore <pmoore>
Date: Fri, Oct 16, 2015 at 11:42 PM
Subject: Re: [selinux-internal] Selinux labeling for FUSE subsystem
To: Brian Foster <bfoster>, Eric Paris <eparis>
Cc: Bipin Kunal <bkunal>, Daniel J Walsh <dwalsh>, selinux-internal-list, Pranith Kumar Karampuri <pkarampu>, Niels de Vos <ndevos>

I didn't look too closely, but yes, something like that.  I do wonder if it
would be possible to just change vfs_kern_mount() to take the subtype
parameter and not bother with vfs_kern_mount_subtype().  Maybe not.  You
likely no more about what the VFS devs find acceptable than I do.

However, I'd like to hear from Eric about what he remembers from when he
touched this last time.  I know he has moved on to the cloooooouuuud, but I'd
like to try and avoid making the same mistakes twice.

--
paul moore
security @ redhat

--- Additional comment from Bipin Kunal on 2015-10-19 02:15:38 EDT ---


---------- Forwarded message ----------
From: Brian Foster <bfoster>
Date: Fri, Oct 16, 2015 at 11:58 PM
Subject: Re: [selinux-internal] Selinux labeling for FUSE subsystem
To: Paul Moore <pmoore>
Cc: Eric Paris <eparis>, Bipin Kunal <bkunal>, Daniel J Walsh <dwalsh>, selinux-internal-list, Pranith Kumar Karampuri <pkarampu>, Niels de Vos <ndevos>

As mentioned above, I only did that so I didn't have to go and change
all of the other vfs_kern_mount() callers. :) We should probably kill
that, but it's not necessary to see if the core change solves the
problem with the original selinux patch (if we confirm that in fact was
the original problem).

Brian

--- Additional comment from Bipin Kunal on 2015-10-19 02:16:04 EDT ---

---------- Forwarded message ----------
From: Paul Moore <pmoore>
Date: Sat, Oct 17, 2015 at 12:10 AM
Subject: Re: [selinux-internal] Selinux labeling for FUSE subsystem
To: Brian Foster <bfoster>
Cc: Eric Paris <eparis>, Bipin Kunal <bkunal>, Daniel J Walsh <dwalsh>, selinux-internal-list, Pranith Kumar Karampuri <pkarampu>, Niels de Vos <ndevos>


Fair enough, it sounds like we're on the same page :)

If I don't see anything from Eric by early next week I'll hunt him down on IRC
and pick his brain a bit on this.

--
paul moore
security @ redhat

Comment 2 Bipin Kunal 2016-01-19 12:15:38 UTC
Paul,

Can we prioritize this Bug?

Thanks,
Bipin Kunal

Comment 3 Paul Moore 2016-01-19 13:53:54 UTC
(In reply to Bipin Kunal from comment #2)
> Paul,
> 
> Can we prioritize this Bug?

Considering that this is a RFE, not a bug/regression, and we do not currently have any serious patches implementing this feature, just some basic design discussions, I don't believe this is suitable for RHEL7.3.  We can revisit this feature in the RHEL7.4 timeframe.  In the meantime, if you have any customer requirements or any other material that you feel would be helpful in setting priorities, I would suggest you leave a comment in this BZ.

Comment 5 Daniel Walsh 2016-02-26 20:50:58 UTC
Can we get this into Fedora release?

Comment 6 Paul Moore 2016-02-26 21:27:35 UTC
Sure, once we have it fixed upstream ... and we currently don't have it fixed upstream.

Comment 12 Zdenek Pytela 2019-02-27 12:05:04 UTC
This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.


Note You need to log in before you can comment on or make changes to this bug.