fedora-selinux August 2010 archive
Main Archive Page > Month Archives  > fedora-selinux archives
fedora-selinux: Re: dac_override and dac_read_search ... again!

Re: dac_override and dac_read_search ... again!

From: Mr Dash Four <mr.dash.four_at_nospam>
Date: Sat Aug 07 2010 - 23:43:25 GMT
To: Daniel J Walsh <dwalsh@redhat.com>

Some progress made today - I found what is causing the problem, though I
have no explanation why it happens - I am simply lost for words.

As part of the image-building process I extract a group of files in the
%post section of my kickstart file:

========%post section
tar -zxf resources.tar.gz

======tar -ztf resources.tar.gz
./etc/init.d/<xxx> (startup scripts for various programs)
./etc/ssh/<xxx> (sshd configuration files)

After the image is built and booted in this way I am getting the various
failures I described in the initial post of this thread.

However, if I do this:

========%post section
tar -zxf resources.tar.gz ./etc/shorewall/* ./etc/my.cnf ./etc/init.d/*
./etc/ssh/* ./usr/bin/torctl ./usr/share/tor/geoip

and then boot the image all is OK - not a single AVC whatsoever and my
auditd daemon runs perfectly!

Here is the place to mention that resources.tar.gz was built with 'tar
-zcf resources.tar.gz .' executed from the directory where I have these
files (a separate directory on which these resources are), so there is
nothing fancy about creating the tar.gz file.

After doing this, I started to investigate to try and find out what
might be the problem. I have extracted the files, but this time I did
the following:

========%post section
tar -zxf resources.tar.gz ./etc/shorewall/* ./etc/my.cnf ./etc/init.d/*
./etc/ssh/* ./usr/*

After booting up, auditd runs perfectly, but I've got the following
variety of avcs (I have the paths after switching auditctl to watch over
/usr and /etc):

======service start smartd==========
type=AVC msg=audit(1281210535.957:2018): avc: denied { dac_override }
for pid=1606 comm="smartd" capability=1
tcontext=system_u:system_r:fsdaemon_t:s0 tclass=capability
type=AVC msg=audit(1281210535.957:2018): avc: denied { dac_read_search
} for pid=1606 comm="smartd" capability=2
tcontext=system_u:system_r:fsdaemon_t:s0 tclass=capability
type=SYSCALL msg=audit(1281210535.957:2018): arch=40000003 syscall=195
success=no exit=-13 a0=bfb92030 a1=bfb92088 a2=642ff4 a3=bfb92030
items=1 ppid=1 pid=1606 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smartd"
exe="/usr/sbin/smartd" subj=system_u:system_r:fsdaemon_t:s0 key=(null)
type=CWD msg=audit(1281210535.957:2018): cwd="/"
type=PATH msg=audit(1281210535.957:2018): item=0

repeated many times over.

-rw-r--r--. root root system_u:object_r:locale_t:s0

So I do not see that there is a permission problem. I've also had quite
a few avcs with paths originating from /usr when I tried to restart
Shorewall. If I build the image with this:

========%post section
tar -zxf resources.tar.gz ./etc/* ./usr/*

neither auditd nor any of my startup services start properly. This tells
me that something is happening when the files are unpacked from the tar
archive, though I could not, for the life of me, figure out what that
might be!

At first I thought that it may be a labelling problem (i.e. if I saved
the SELinux attributes in the archive and then when they are not
extracted properly), but at the end of the kikstart file I execute
'restorecon -ripF /', which relabels everything and there are NO obvious
problems. Besides, 'tar -zcf' by default does not include SELinux
attributes as far as I know.

The problem seems to be that tar 'extracts' ./etc and ./usr in a way,
which messes things up. /etc is needed by auditd as auditd.conf is there.

Again, this only happens with policy versions -39 and -41! With -37 I do
NOT have this! In other words, if I extract all the files with 'tar -zxf
resources.tar.gz' I have no problems with -37, but with -39 and -41 I do!

I have no idea what causes this, so any help is appreciated.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux