For amd64 (and probably other 64 bit platforms), the /lib on the root device is created as a symlink to /lib64 instead of as a normal directory. When selinux is installed and asked to label a filesystem with the strict policy, setfiles will use a system_u:object_r:default_t as a default context, ie: # setfiles -d /etc/selinux/strict/contexts/files/file_contexts /lib setfiles: labeling files under /lib setfiles: /lib matched by system_u:object_r:default_t matchpathcon_filespec_eval: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: Done. (Note that I'm using an unstable selinux/2006.1 profile and thus using the strict reference policy vs the old example policy that would come with a stable 2005.1/selinux) AS a result of the default labeling, a number of avc denials messages will be logged on system startup as the /lib directory should be labeled as system_u:object_r:lib_t. Since I'm running in permissive mode, nothing keeps the system from coming up. However I suspect that we wouldn't be getting far in strict mode. Reproducible: Always Steps to Reproduce: 1.Install selinux on an amd64 arch 2.label the filesystem 3.boot with selinux in permissive mode and look at your dmesg for avc denials Actual Results: Here's some filtered denials from dmesg: Here's a smattering from dmesg of /lib denials that pop up right after the policy is loaded: audit(1181500172.270:5): avc: denied { read } for pid=1 comm="init" name="lib" dev=hda2 ino=49153 scontext=system_u:system_r:init_t tcontext=system_u:object_r:default_t tclass=lnk_file audit(1181500172.292:7): avc: denied { read } for pid=945 comm="hotplug" name="lib" dev=hda2 ino= 49153 scontext=system_u:system_r:hotplug_t tcontext=system_u:object_r:default_t tclass=lnk_file audit(1181500172.509:12): avc: denied { read } for pid=1046 comm="rc" name="lib" dev=hda2 ino=491 53 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:default_t tclass=lnk_file audit(1181500172.827:14): avc: denied { read } for pid=1048 comm="consoletype" name="lib" dev=hda 2 ino=49153 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:default_t tclass=lnk _file Expected Results: No denials I'm not sure if this is a fix for gentoo or for the Tresys guys who manage the reference policy development. The following rule needs to be put into the file /etc/selinux/strict/contexts/files/file_contexts: /lib -l system_u:object_r:lib_t This should take precedence over the rule for a normal /lib directory which looks like: /lib/.* system_u:object_r:lib_t With the new symlink rule in effect, setfiles output should be as follows: # setfiles -d /etc/selinux/strict/contexts/files/file_contexts /lib setfiles: labeling files under /lib setfiles: /lib matched by system_u:object_r:lib_t matchpathcon_filespec_eval: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: Done. and the resulting /lib symlink should look like: # ls -Z / | grep lib lrwxrwxrwx root root system_u:object_r:lib_t lib drwxr-xr-x root root system_u:object_r:lib_t lib32 drwxr-xr-x root root system_u:object_r:lib_t lib64
fixed upstream