Bug 1005398 - Labeled NFS does not seem to work on a Disabled SELinux Server
Labeled NFS does not seem to work on a Disabled SELinux Server
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: nfs-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-09-06 16:01 EDT by Daniel Walsh
Modified: 2016-07-19 06:21 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-19 06:21:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
New LSM to allow for no real LSM to be present and Labeled NFS to work (3.23 KB, application/gzip)
2013-09-17 23:14 EDT, David Quigley
no flags Details

  None (edit)
Description Daniel Walsh 2013-09-06 16:01:39 EDT
For some reasons SELinux Labels are not supported when a server machine does not have SELinux enabled.  This should work.

Not sure if this is a bug in the kernel or nfs-utils.

Client support Labels. Server supports NFS 4.2, but labels are not working.


cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2

On client
mount | grep mwalsh on /home/mwalsh type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=,local_lock=none,addr=

touch /home/mwlsh/dan
chcon user_u:object_r:user_home_t:s0 /home/mwalsh/dan
chcon: failed to change context of ‘dan’ to ‘user_u:object_r:user_home_t:s0’: Operation not supported
ls -lZ dan
-rw-r--r--. root root system_u:object_r:nfs_t:s0       dan
Comment 1 Daniel Walsh 2013-09-06 16:16:47 EDT
Dave Quigley informs me

> We can't have SELinux
> disabled and Labeled NFS working. We use the LSM to put the labels in
> place. Without SELinux enabled then you can't use the LSM for that.
Comment 2 Stephen Smalley 2013-09-06 16:21:34 EDT
That's if the server is Linux.  For another OS, it can certainly implement NFSv4.2 support without needing SELinux; it just needs to provide storage for the labels.
Comment 3 Stephen Smalley 2013-09-06 16:25:10 EDT
Also, I'm sure one could implement a trivial LSM that does nothing other than support storage and fetching of the labels if you wanted a Linux server that provided the functionality but no actual policy.
Comment 4 David Quigley 2013-09-06 17:19:32 EDT
I'm sure too. I did it years ago. I think I still have the code. I'll check when I get home.
Comment 8 Daniel Walsh 2013-09-07 06:31:00 EDT
I am pretty sure someone will ask for this.  With some comment about performance.  But for now, we can tell them to just run the machine in permissive mode.  If you install the machine without policy and run in permissive mode, will it work?
Comment 9 David Quigley 2013-09-07 23:36:13 EDT
The LSM hooks use the policy engine to determine if labels are valid so I'd imagine that wouldn't work. You'll need a policy running similar if not exact to your client environment so they validate.
Comment 10 Daniel Walsh 2013-09-10 11:33:57 EDT
Ok So need close to the same types/roles/users.
Comment 11 Daniel Walsh 2013-09-10 11:35:52 EDT
Moving this to Rawhide, since it seems to be Request for enhancement, but i guess we need to release note/Document it.
Comment 12 David Quigley 2013-09-17 23:13:18 EDT
I am attaching my implementation of a dummy lsm which allows you in the kernel config to set the xattr to store the label in and also what the default label should be for a file which does not have label information.
Comment 13 David Quigley 2013-09-17 23:14:11 EDT
Created attachment 799060 [details]
New LSM to allow for no real LSM to be present and Labeled NFS to work
Comment 14 J. Bruce Fields 2013-09-18 09:03:42 EDT
Thanks!  You probably know all this, but:

- that nfsd fixup should be folded into the patch making the interface change.
- this should be sent upstream and cc'd to security folks (as I probably wouldn't know the right questions to ask about a new lsm.)
- It will need to come with a good justification.  Something more than just "someone might want this".  Even if the idea's basically fine, it's another configuration knob to document and another thing to test and maintain, so we need some argument that this is worthwhile.
Comment 15 Daniel Walsh 2013-09-18 11:22:50 EDT
Security guys are CC'd on this list, but we should send this for upstream review.
Comment 16 David Quigley 2013-09-18 14:18:40 EDT
Something to realize with these patches is that I wrote them as a proof of concept about 3 or 4 years ago now. At the time Steve helped me with them but they still need a very heavy review. I wrote it just so I could have a simple dumb server backend for LNFS without having to have people worry about SELinux on the server. It does 0 verification of labels so as long as you sent the right setfattr command to the server with some data it will set the label to that data. I don't know if it is the right way to handle the problem because it provides 0 validity checking of the labels and doesn't protect them at all.

I don't remember why there are nfsd changes in there for this but I'd imagine they will not really affect the test matrix for NFS that much. The code for Labeled NFS still used the LSM hooks we put in place for Labeled NFS and this just implements those necessary hooks that LNFS needs to work. Again this was just a POC and there is no guarantee its even the right approach. We need a lot of discussion about this before we try to push it as a solution.
Comment 17 David Quigley 2013-09-18 14:24:34 EDT
Ahh I see now (looking through the code). I tried a long time ago to remove the dependency for passing a dentry to {set,get}xattr but unfortunately that isn't possible. So instead I change the interface to take a dentry so we can internally make a call to set/getxattr inside the dummy LSM hook.
Comment 18 Jaroslav Reznik 2015-03-03 10:02:44 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
Comment 19 Fedora End Of Life 2016-07-19 06:21:15 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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