is there a common standard for Fedora where to locate the NFS home directories? In Solaris it used to be /export/home. I cannot export and mount the whole /home directory, since it contains also local account. I first do do not want some local accounts home directories be exported and second I do not want some client’s local home directories overlayed.
Once there is some common standard it would be easy to define selinux policy for that parallel homedir structure. Nowadays I suffer some difficulties regarding selinux and probable bugs in selinux which would be easily came over by having such structure and having stock selinux policy for such structure.
Well, there was probabaly some misunderstanding. I am aware of a way, how to export filesystem and how to mount it. I am wondering if there exists some standard path where NFS home directories are expected to be. I would need some common agreement across community. This is due to the need of standard stock selinux filesystem labeling. I do not want a directory at my will. I have it like this now and I experience problems with selinux.
This is solution for the server for example. But when you run fixfiles on the client who does not have the policy configured or you have malicious client, he is able to relabel. This is why I would like to have stock policy with nfs home directories. It will not help against malisious clients but at least not configured ones would be solved.
The need is to have same path on the server and on the client. Home directory is read from ldap on server and on the client. Is /srv/nfs/home suitable then?
regarding selinux:
semanage fcontext -l | grep /srv
/srv all files system_u:object_r:var_t:s0
This would relabel all the home directories to var_t on the client.
It is not feasible to add labels on all the clients if it is not the default stock policy.
This means your infrastructure does not support what you want to achieve.
Configuration management must be deployed before setting up homes on NFS.
Otherwise you are limited to SELinux defaults and unable to provide an alternative home location, or have to abandon the idea with local users.
SELinux offers additional security by locking down the capabilities of services provided in Red Hat Enterprise Linux. By default, NFS mounts have the SELinux context nfs_t, independent of the SELinux context they have on the server that provides the export.
Furthermore,
The NFS server can be forced to properly export the SELinux context of a share by switching to NFS version 4.2. This specification currently only exists as an Internet draft. It is already implemented in the NFS server shipped by CentOS/RHEL 7 but needs to be turned on explicitly.
This still doesn’t answer the question about the standard location for exported home directories. I suspect no standard were ever formulated.
this is quite old information. In the past the client has seen all the nfs mount as nfs_t. these times everything was working OK, only server managed the contexts. But nowadays the client sees the labels and is able to relabel. Unfortunately, it seems to be a bug, you are allowed to relabel also files I think you should not be able to relabel. when you are root on a client and have mounted the share exported with root_squash, you normally have permissions as some guest user (uid 65534 or similar). But you are able to relabel all the files you have read permissions to. I am trying to achieve situation when nfs home directories are labeled by stock policy. But this needs an agreement on the community to have such path and also the selinux policy administrators to agree to set the policy on it. I do not know how to proceed. Is there some comitee sho can decide the standard path? Or is not it already in the Linux filesystem hierarchy standard?
it seems the only viable solution is to follow Vladislav’s suggestion with semanage and asking all the local admins to apply the command to kindly stopping relabeling server files. I found no way to standardize the nfs homedir localtion and also no response on the bug report. I thought that security is a priority.
Well, I did give you a context and a location for this to be standardized in your environment. It’s how I or my team would have handled it when I was doing such things years ago.
The fact is to reiterate, there is no standard way. Logic would say if the context exist already for one, use it as “good practice”.
regarding the security is a priority I meant the probable selinu bug I am suffering. The client root is able to relabel any files on the NFS filesystem he is able to list even if the NFS share is exported with root_squash. Sorry I was not explicit on this.
Maybe, On the NFS share map the clients root to an unprivileged user.
Edit the /etc/exports file and add the all_squash option along with the user mapping option.
Maybe a poor example : /path/to/share *(rw,sync,all_squash,user_squash)
Define the user mapping using the rpc_user option. Here, map the client’s root (UID 0) to a specific unprivileged user (e.g., nfsuser ) on the server, /path/to/share *(rw,sync,all_squash,user_squash,root_squash="nfsuser") Important: Create the nfsuser user beforehand and set appropriate permissions.
Restart the NFS service:
sudo systemctl restart nfs-kernel-server
Let me know what you think here. If you need more help in understanding I can talk some more about this. It ahs been some time since I used such tooling, but maybe I still remember some things. . .
Consider relabeling the NFS share with SELinux.
Futire Edit :
I actually found 2 more VERY LONG notes on this or similar topic. 1 is a wholey SELinux solution that is very involved. The other is similar to this. one where the client/root is remapped to an unprivlaged user on the NFS server.
if I use all_squash, I cannot use the share as nfs home. I need users to have the possibility to create their files. Also no problem to have the possibility to relabel files by user.
Once I run relabel on the server, fiels are labeled correctly. Once I relabel on the client as root, I get wrong labels, if I do not have the policy upgated by the above semenage command.
If there is a malicious client root admin, he can create any labels at will and relabel files on the nfs share at will.
Currently all user home directories have drwx------ permissions so the relabel operation from the client root cannot descend into the home directory and relabel files there, until some user does not modify permissions to allow all users to descend into the directory. But the home directories itself can be freely relabeled by the client root.
For sure using the root_squash the root user is mapped to nfsnobody (uid 65534). The unix provileges works fine, the root user is not able to modify files or read files not readable by 65534 uid. But the selinux labels can be changed! I suppose this is selinux’s security bug.
There are specific steps you can take to mitigate the risk of malicious relabeling by a client root user while still allowing legitimate users to create and manage their files on the NFS share.
Continue using root_squash:
Ensure that root_squash is enabled to map the root user on the client to the nfsnobody user on the server. This prevents the client root user from having root privileges on the NFS share.
Restrict SELinux relabeling capabilities:
Create a custom SELinux policy to restrict the ability to relabel files on the NFS share. This involves creating a policy module that prevents the nfsnobody user from relabeling files.
And finally. . .
Creating the SELinux policy module
This is going to require me to go through some docs I have pieced together over time and some changes that were made to SELinux. I’m really nearing the edge of my knowledge without re-reading current docs and ensuring things are correct.
I’m providing information on this I and my former team deemed best practice.
This should provide you with a good amount of information without me feeling uncomfortable providing security labels for things I haven’t done in years
Given some time, i could contribute more to this thread. . .
That is a very different question IMO. Gimme some minutes here to get back to you. I need to swim through some notes.
