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.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
