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.