bloody links!

[Dominick Grift]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100702/15495ce2/attachment.bin