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
%post
tar -zxf resources.tar.gz
....
%end
=================
======tar -ztf resources.tar.gz
./
./etc/
./etc/shorewall/
./etc/shorewall/shorewall.conf
./etc/my.cnf
./etc/init.d/<xxx> (startup scripts for various programs)
./etc/ssh/
./etc/ssh/<xxx> (sshd configuration files)
./usr/
./usr/bin/
./usr/bin/torctl
./usr/share/
./usr/share/tor/
./usr/share/tor/geoip
======================
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
%post
tar -zxf resources.tar.gz ./etc/shorewall/* ./etc/my.cnf ./etc/init.d/*
./etc/ssh/* ./usr/bin/torctl ./usr/share/tor/geoip
...
%end
=================
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
&post
tar -zxf resources.tar.gz ./etc/shorewall/* ./etc/my.cnf ./etc/init.d/*
./etc/ssh/* ./usr/*
...
%end
=================
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
scontext=system_u:system_r:fsdaemon_t:s0
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
scontext=system_u:system_r:fsdaemon_t:s0
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
name="/usr/share/zoneinfo/GMT"
=============================
repeated many times over.
-rw-r--r--. root root system_u:object_r:locale_t:s0
/usr/share/zoneinfo/GMT
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
%post
tar -zxf resources.tar.gz ./etc/* ./usr/*
...
%end
=================
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
