FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-01-2010, 10:53 PM
Mr Dash Four
 
Default bloody links!

>> 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_ubject_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_ubject_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_ubject_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_ubject_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_ubject_r:var_log_t:s0 log -> /apps/var/log

ls -lasZ /apps
~~~~~~~~~
drwx--x--x. root root system_ubject_r:var_t:s0 var

ls -lasZ /apps/var
~~~~~~~~~~~~
drwx--x--x. root root system_ubject_r:var_t:s0 .
drwxr-xr-x. root root system_ubject_r:default_t:s0 ..
drwxr-xr-x. root root system_ubject_r:var_log_t:s0 log

ls -lasZ /apps/var/log
~~~~~~~~~~~~~~
drwxr-xr-x. root root system_ubject_r:var_log_t:s0 .
drwx--x--x. root root system_ubject_r:var_t:s0 ..
-rw-r--r--. root root system_ubject_r:var_log_t:s0 dmesg
drwxr-x---. exim exim system_ubject_r:default_t:s0 exim
-rw-rw-r--. root utmp system_ubject_r:wtmp_t:s0 wtmp



What am I doing wrong?!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 06:26 AM
Paul Howarth
 
Default bloody links!

On Thu, 01 Jul 2010 23:53:42 +0100
Mr Dash Four <mr.dash.four@googlemail.com> 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_ubject_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_ubject_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_ubject_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_ubject_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_ubject_r:var_log_t:s0 log
> -> /apps/var/log
>
> ls -lasZ /apps
> ~~~~~~~~~
> drwx--x--x. root root system_ubject_r:var_t:s0 var
>
> ls -lasZ /apps/var
> ~~~~~~~~~~~~
> drwx--x--x. root root system_ubject_r:var_t:s0 .
> drwxr-xr-x. root root system_ubject_r:default_t:s0 ..
> drwxr-xr-x. root root system_ubject_r:var_log_t:s0 log
>
> ls -lasZ /apps/var/log
> ~~~~~~~~~~~~~~
> drwxr-xr-x. root root system_ubject_r:var_log_t:s0 .
> drwx--x--x. root root system_ubject_r:var_t:s0 ..
> -rw-r--r--. root root system_ubject_r:var_log_t:s0 dmesg
> drwxr-x---. exim exim system_ubject_r:default_t:s0 exim
> -rw-rw-r--. root utmp system_ubject_r:wtmp_t:s0 wtmp
>
>
>
> What am I doing wrong?!

Using bind mounts instead of symlinks will help.

Fix the context of /apps too:
# semanage fcontext -a -t root_t /apps
# restorecon -Fv /apps

And fix the context of /apps/var/log/*:
# semanage fcontext -a -e /var/log /apps/var/log
# restorecon -rvF /apps/var/log

Paul.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 08:03 AM
Dominick Grift
 
Default bloody links!

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_ubject_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_ubject_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_ubject_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_ubject_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_ubject_r:var_log_t:s0 log -> /apps/var/log
>
> ls -lasZ /apps
> ~~~~~~~~~
> drwx--x--x. root root system_ubject_r:var_t:s0 var
>
> ls -lasZ /apps/var
> ~~~~~~~~~~~~
> drwx--x--x. root root system_ubject_r:var_t:s0 .
> drwxr-xr-x. root root system_ubject_r:default_t:s0 ..
> drwxr-xr-x. root root system_ubject_r:var_log_t:s0 log
>
> ls -lasZ /apps/var/log
> ~~~~~~~~~~~~~~
> drwxr-xr-x. root root system_ubject_r:var_log_t:s0 .
> drwx--x--x. root root system_ubject_r:var_t:s0 ..
> -rw-r--r--. root root system_ubject_r:var_log_t:s0 dmesg
> drwxr-x---. exim exim system_ubject_r:default_t:s0 exim
> -rw-rw-r--. root utmp system_ubject_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_ubject_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.


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 02:58 PM
Mr Dash Four
 
Default bloody links!

>> What am I doing wrong?!
>>
>
> Using bind mounts instead of symlinks will help.
>
It did!

I added "/apps/var/log /var/log none bind 0 0" to my fstab file and 2 of
the three alerts are now gone. I am still getting this though:

kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for
pid=1557 comm="login" name="log" dev=sdc ino=16386
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_ubject_r:var_log_t:s0 tclass=dir

This happens when I try to log in to the console. Any ideas?

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 03:06 PM
Mr Dash Four
 
Default bloody links!

>> What am I doing wrong?!
>>
>
> A few things look wrong to me:
>
> $ sesearch --allow -SC -s syslogd_t -t var_log_t -c lnk_file
>
This returns no matches.


> 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_ubject_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.
>
>
I did just that - restorecon from /apps (recursive) seemed to restore
all permissions in that directory once I used mount (--bind) to bind
/apps/var/log to /var/log. 2 of the alerts are now gone, though I am
still getting one when I log in to the console.

kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for
pid=1557 comm="login" name="log" dev=sdc ino=16386
scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_ubject_r:var_log_t:s0 tclass=dir

> 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.
>
>
I have just discovered this 'magical' type. I use xtunnels (voip proxy)
and was worried that I would need to define a whole new policy for it
(it 'binds' to one particular port, but then uses a whole range of
random ports 1024-65535 to connect externally) - I was dreading it, but
when I started it it did bind to the port (no alerts!) and later on I
discovered that it has a "bin_t" type. Interesting!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 04:12 PM
Paul Howarth
 
Default bloody links!

On 02/07/10 15:58, Mr Dash Four wrote:
>
>>> What am I doing wrong?!
>>
>> Using bind mounts instead of symlinks will help.
> It did!
>
> I added "/apps/var/log /var/log none bind 0 0" to my fstab file and 2 of
> the three alerts are now gone. I am still getting this though:
>
> kernel: type=1400 audit(1278074918.050:4): avc: denied { write } for
> pid=1557 comm="login" name="log" dev=sdc ino=16386
> scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
> tcontext=system_ubject_r:var_log_t:s0 tclass=dir
>
> This happens when I try to log in to the console. Any ideas?

It's probably trying to create a new file in your log directory. Try
logging in with the system in permissive mode so you can see which file
it's trying to create, then create an empty file with the right
ownership and permissions (regular and SELinux) in your log directory
and try again in enforcing mode.

Paul.

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-02-2010, 07:54 PM
Mr Dash Four
 
Default bloody links!

>>
>> This happens when I try to log in to the console. Any ideas?
>
> It's probably trying to create a new file in your log directory. Try
> logging in with the system in permissive mode so you can see which
> file it's trying to create, then create an empty file with the right
> ownership and permissions (regular and SELinux) in your log directory
> and try again in enforcing mode.
It worked - /var/log/lastlog was the culprit! This has now been fixed.

A common problem I found is that if a particular file does not exist in
/var/log (standard log directory), and as this directory has the
(standard) var_log_t type, almost any process wishing to write to this
directory fails miserably (notable exceptions to this is mysqld and
shorewall - they have no problems creating the appropriate files if they
do not exist!).

I had the exact same problem with the audit daemon as well (auditd) -
unless I create a directory (say, /var/log/audit) with the proper
permissions (auditd_log_t in this case) it fails to start if audit.log
does not exist. I guess if I want to keep one log directory and limit
the number of subdirectories I have to remember to keep a copy of the
appropriate log files ("touch /var/log/XXX" and then set the permissions
with semanage).
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 04:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org