My /home is a soft link to a directory within a separate filesystem. I'm trying to figure out how to label it properly, such that I can setenforce 1 and be able to ssh into this box as myself using public-key authentication. If I setfiles /etc/security/selinux/file_contexts /home, it does nothing. The /home soft link and the /home/. dir remain with default_t. If I setfiles ... /home/., it labels /home/. as if it was a home directory, so /home/.mozilla/* would be labeled as user_mozilla_rw_t, but /home/aoliva/.mozilla would be labeled as just user_home_t. If I setfiles ... /home/aoliva, it labels things correctly. But then, .ssh is a soft link as well. So I label /home/aoliva/.ssh, and it doesn't relabel the soft link nor the directory contents. Relabeling /home/aoliva/.ssh/. *seems* to label things correctly, such that .ssh and its contents are user_home_ssh_t. However, sshd still fails to stat64() /home/aoliva/.ssh/authorized_keys, with permission denied. Even if I use lsetfilecon() to adjust the context of the soft links such that they match those of the directories they point to, it still doesn't work. Worse yet: ssh claims it can't chdir to my home dir after I enter a password, even though, after it lets me in, I can cd to it. The error I get is avc: denied { read } for pid=2920 exe=/usr/sbin/sshd name=home dev=dm-2 ino=26 scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:home_root_t tclass=lnk_file Is there any special treatment I have to give to such soft links to get them to work? Anyhow, the main point of this issue was that we're missing a way to label links in the command line. Ideally, setfiles, if given a soft link in the command line, should label this soft link appropriately, and then follow the link and label the pointed-to file or directory, along with its sub-tree (not following additional links within it, though). Additionally, setfilecon should probably accept a command-line flag (-h, like chown/mod/grp) to affect a soft link instead of the file pointed-to by the link. Version-Release number of selected component (if applicable): libselinux-1.11.1-1
chcon is the command you are looking for. I believe getting setfiles to work differently on sym links could be a security problem. One of the things we are discussing is getting something like chcon to be perminant, So an admin could set file contexts the way they want on certain files and then setfiles would not revert them back. Dan
I don't see how it could be a security problem, but silently relabeling the pointed-to file instead of the soft link, and not recursing if it turns out to be a directory, feels even more flawed to me. It should either not follow the soft link at all, or follow it entirely. Although I must admit that the current behavior is consistent with other tools that change properties of files or directories (chmod, chown, chgrp, etc), and that require -h to affect the symlink, and fail to recurse just the same. The big difference is that, if you do mean them to recurse, you can just add a trailing `/.', and it will have the right effect, except in the case of setfiles, because the `/.' is not sanitized out of the pathname when computing the file context. Unfortunately, canonicalizing the pathname before attempting to find a match regexp, which is the obvious solution that springs to mind, defeats the very attempt to get setfiles to label files following the logical access paths to the files (i.e., through the soft links within my home dir), instead of the physical pathnames. Heck, this is tricky! :-(
With current policy you should be able to change homedir within /usr/sbin/addusers and the file_context will get set correctly.
Homedirs in other locations are currently handled, chekc. getting fixfiles/setfiles to follow soft links, on the other hand, isn't, and it would be nice if it was. But maybe that's to be handled in a separate bug report...