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. Server: cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2 On client mount | grep mwalsh 192.168.122.221:/home/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=192.168.122.1,local_lock=none,addr=192.168.122.221) 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
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.
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.
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.
I'm sure too. I did it years ago. I think I still have the code. I'll check when I get home.
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?
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.
Ok So need close to the same types/roles/users.
Moving this to Rawhide, since it seems to be Request for enhancement, but i guess we need to release note/Document it.
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.
Created attachment 799060 [details] New LSM to allow for no real LSM to be present and Labeled NFS to work
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.
Security guys are CC'd on this list, but we should send this for upstream review.
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.
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.
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: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.