Trying SELinux again on CentOS 5.1 - local script problems

Daniel J Walsh dwalsh at redhat.com
Mon Mar 3 20:53:33 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Nichols wrote:
> Being masochistic by nature, I decided to take another crack at getting
> SELinux running on my system, and ran into a couple of problems with
> some important local scripts.  First, some system information:
> 
>   System: CentOS 5.1 on an Intel Pentium 4 CPU
>   kernel-2.6.18-53.1.13.el5
>   selinux-policy-targeted-2.4.6-106.el5_1.3
>   setools-3.0-3.el5
> 
> Problem 1:
> 
> Here, my dhclient-exit-hooks script is examining the 'named' configuration
> file to verify that the local DNS server will be forwarding queries to the
> servers assigned by DHCP.  The script will reconfigure and restart 'named'
> if necessary, and that would undoubtedly result in more AVCs.  Testing
> every
> combination of things that might happen is impractical, so just running
> audit2allow on these AVCs is almost certainly insufficient.  Operation of
> this script absolutely must not be blocked.  How can I open the door wide
> enough to ensure that?
> 
> avc:  denied  { search } for  pid=2551 comm="dhclient-script"
> name="named" dev=hda6 ino=267649 scontext=system_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:named_zone_t:s0 tclass=dir
> avc:  denied  { search } for  pid=2551 comm="dhclient-script"
> name="chroot" dev=hda6 ino=267651 scontext=system_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:named_conf_t:s0 tclass=dir
> avc:  denied  { getattr } for  pid=2551 comm="dhclient-script"
> path="/var/named/chroot/etc/named.conf" dev=hda6 ino=267674
> scontext=system_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:named_conf_t:s0 tclass=file
> avc:  denied  { read } for  pid=2599 comm="grep" name="named.conf"
> dev=hda6 ino=267674 scontext=system_u:system_r:dhcpc_t:s0
> tcontext=system_u:object_r:named_conf_t:s0 tclass=file
> 
> Problem 2:
> 
> Here, my ifup-local script is starting a tcpdump capture on eth1.  It is
> important to me that this capture begin automatically with the eth1 link
> is started.  The actual directory where the capture files are stored has
> been given a context system_u:object_r:netutils_tmp_t, and that works
> without complaint (and does not appear below).  Is there a way to make
> this work other than blindly running audit2allow on all these AVCs?
> Other than perhaps the stderr file (/root/eth1-cap.out), I don't see any
> possibility of adjusting target contexts.  (Why
> system_u:system_r:netutils_t
> should be denied search and read permission in /proc is puzzling.)
> 
> avc:  denied  { write } for  pid=2670 comm="tcpdump"
> path="/root/eth1-cap.out" dev=hda2 ino=43920
> scontext=system_u:system_r:netutils_t:s0
> tcontext=user_u:object_r:user_home_t:s0 tclass=file
> avc:  denied  { search } for  pid=2670 comm="tcpdump" name="nscd"
> dev=hda6 ino=283420 scontext=system_u:system_r:netutils_t:s0
> tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir
> avc:  denied  { search } for  pid=2670 comm="tcpdump" name="sys"
> dev=proc ino=-268435428 scontext=system_u:system_r:netutils_t:s0
> tcontext=system_u:object_r:sysctl_t:s0 tclass=dir
> avc:  denied  { search } for  pid=2670 comm="tcpdump" name="kernel"
> dev=proc ino=-268435416 scontext=system_u:system_r:netutils_t:s0
> tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir
> avc:  denied  { read } for  pid=2670 comm="tcpdump" name="ngroups_max"
> dev=proc ino=-268435369 scontext=system_u:system_r:netutils_t:s0
> tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file
> avc:  denied  { search } for  pid=2670 comm="tcpdump" name="/" dev=hdb1
> ino=2 scontext=system_u:system_r:netutils_t:s0
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> 
> That last AVC is puzzling, because the root directory ("/") is not located
> on hdb1.  That device holds the directory where the capture files are
> being stored.  Inode 2 on /dev/hdb1 is on mount point "/x" in the
> filesystem.
> 
Simplest thing is to run this through
# grep avc /var/log/audit2allow | audit2allow -M mypol
# semodule -i mypol.pp


You might want to first update to the U2 preview policy, available on
http://people.redhat.com/dwalsh/SELinux/RHEL5

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfMZUwACgkQrlYvE4MpobP6BQCfRuiyKhp3dQfk6/eDhj2ZXY3k
qGUAn2jzSJsPWOB5pKNF2LwgCvMI26LI
=Jq+9
-----END PGP SIGNATURE-----




More information about the fedora-selinux-list mailing list