-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/07/2010 07:43 PM, Mr Dash Four wrote:
> 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.
WHat is the permission on /etc
ls -ld /etc /usr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxkGZUACgkQrlYvE4MpobNd9QCgr9fXhHt4cZ77ShO+FO7lrBRu
3LkAn2vDl6LLMjVjfVfUl5TtoUk2clDt
=yi1J
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
