On 07/02/2010 12:53 AM, Mr Dash Four wrote: > >>> type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906 >>> comm="rsyslogd" name="log" dev=dm-0 ino=16386 >>> scontext=system_u:system_r:syslogd_t:s0 >>> tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file >>> >>> There is a similar one with "mingetty" as well, but >>> scontext=system_u:system_r:getty_t:s0 >>> >> >> This symlink is mislabeled. What/who created it? if you , yourself >> created it, then you may be able to make things work by labeling the >> symlink type bin_t or type var_log_t, provided that the source of the >> interaction (in this case syslogd_t and getty_t) have access to the >> target of the symlink. >> > Up until yesterday I used this on the real partition and it worked. > Today, after deploying a new version I am getting the same errors again > in addition to another (similar) error during console login: > > ===from dmesg as /var/log/messages does not exist as access is denied=== > type=1400 audit(1278020473.778:4): avc: denied { read } for pid=914 > comm="rsyslogd" name="log" dev=dm-0 ino=6188 > scontext=system_u:system_r:syslogd_t:s0 > tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file > type=1400 audit(1278020487.171:22): avc: denied { read } for pid=1007 > comm="mingetty" name="log" dev=dm-0 ino=6188 > scontext=system_u:system_r:getty_t:s0 > tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file > type=1400 audit(1278020566.762:38): avc: denied { read } for pid=1007 > comm="login" name="log" dev=dm-0 ino=6188 > scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file > =================================================== > > > here is the layout of the files/directories in question: > > ls -lasZ /var > ~~~~~~~~ > lrwxrwxrwx. root root system_u:object_r:var_log_t:s0 log -> /apps/var/log > > ls -lasZ /apps > ~~~~~~~~~ > drwx--x--x. root root system_u:object_r:var_t:s0 var > > ls -lasZ /apps/var > ~~~~~~~~~~~~ > drwx--x--x. root root system_u:object_r:var_t:s0 . > drwxr-xr-x. root root system_u:object_r:default_t:s0 .. > drwxr-xr-x. root root system_u:object_r:var_log_t:s0 log > > ls -lasZ /apps/var/log > ~~~~~~~~~~~~~~ > drwxr-xr-x. root root system_u:object_r:var_log_t:s0 . > drwx--x--x. root root system_u:object_r:var_t:s0 .. > -rw-r--r--. root root system_u:object_r:var_log_t:s0 dmesg > drwxr-x---. exim exim system_u:object_r:default_t:s0 exim > -rw-rw-r--. root utmp system_u:object_r:wtmp_t:s0 wtmp > > > > What am I doing wrong?! A few things look wrong to me: 1. syslogd_t cannot interact with lnk_files that are labelled with the generic type for objects in /var/log (var_log_t): > $ sesearch --allow -SC -s syslogd_t -t var_log_t -c lnk_file > 2. Unrelated to the above AVC denial but sure to also cause issues is the mislabelling of /apps/var/log/exim. This directory is labelled with an type reserved for unknown locations to SELinux. It means that SELinux currently has no file context specification for this location: > $ matchpathcon /apps/var/log/exim > /apps/var/log/exim system_u:object_r:default_t:s0 In Fedora 13 there is option for the semanage command called equivalence. This option can be used to clone file context specification. In the "man semanage" there is an example that should apply to you configuration: > For home directories under top level directory, for example /disk6/home, > execute the following commands. > # semanage fcontext -a -t home_root_t "/disk6" > # semanage fcontext -a -e /home /disk6/home > # restorecon -R -v /disk6 Translating the above to your scenario would look like this: sudo semanage fcontext -a -t root_t "/apps" sudo semanage fcontext -a -e /var /apps/var sudo restorecon -R -v /apps If you make sure to use similar locations in /apps are the usual /var, then stuff should get labelled properly. This will not fix you "read var_log_t lnk_file" issue though. I would probably try labelling the symlink type bin_t, and see if that works.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux