Recent SEL problems on FC3 box - named & dhcpd

Ruth Ivimey-Cook Ruth.Ivimey-Cook at ivimey.org
Tue Mar 22 15:30:10 UTC 2005


Hi folks,

I have just started having some problems with selinux. I'm using FC3 with the
targetted policy. It was running enforced; now merely permissive because of the
problems. The box is running BIND/named in master mode (i.e. it is master for
some domains, but not supplying those domains to other demons) and a dhcp
server. I have today used yum to update both daemons from the updates-released
repo, and am now getting errors of this sort (note this is a sample - there are
many more):

...
audit(1111501062.397:0): avc:  denied  { search } for  pid=6809
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501062.397:0): avc:  denied  { search } for  pid=6809
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501107.559:0): avc:  denied  { search } for  pid=6828
exe=/usr/sbin/named name=/ dev=md1 ino=2 scontext=root:system_r:named_t
tcontext=system_u:object_r:file_t tclass=dir
...
audit(1111501250.295:0): avc:  denied  { write } for  pid=6873
exe=/usr/sbin/named name=log dev=tmpfs ino=8452 scontext=root:system_r:named_t
tcontext=user_u:object_r:device_t tclass=sock_file
audit(1111501250.295:0): avc:  denied  { sendto } for  pid=6873
exe=/usr/sbin/named path=/dev/log scontext=root:system_r:named_t
tcontext=user_u:system_r:unconfined_t tclass=unix_dgram_socket
audit(1111501302.433:0): avc:  denied  { search } for  pid=6896
exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111501302.433:0): avc:  denied  { search } for  pid=6896
exe=/usr/sbin/dhcpd name=etc dev=md1 ino=1368193 scontext=root:system_r:dhcpd_t
tcontext=root:object_r:file_t tclass=dir
audit(1111501302.437:0): avc:  denied  { read } for  pid=6896
exe=/usr/sbin/dhcpd name=libc.so.6 dev=md1 ino=295646
scontext=root:system_r:dhcpd_t tcontext=root:object_r:file_t tclass=lnk_file
...

Using audit2allow on the full set gives the following:

allow dhcpd_t device_t:sock_file write;
allow dhcpd_t file_t:dir { add_name search write };
allow dhcpd_t file_t:file { append create execute getattr link read unlink
write };
allow dhcpd_t file_t:lnk_file read;
allow dhcpd_t unconfined_t:unix_dgram_socket sendto;
allow named_t device_t:sock_file write;
allow named_t file_t:dir search;
allow named_t file_t:file { execute getattr read };
allow named_t file_t:lnk_file read;
allow named_t unconfined_t:unix_dgram_socket sendto;

Now, would you expect that I should need to modify the settings?
Might it be appropriate to recompile the policy even though I've not changed it
myself?

I have also been seeing many avc:s from attempts to run rndc. The following
might be indicative (I just "prompted" these by doing service named status):

audit(1111505098.098:0): avc:  denied  { search } for  pid=12690
exe=/usr/sbin/rndc name=/ dev=md1 ino=2 scontext=root:system_r:ndc_t
tcontext=system_u:object_r:file_t tclass=dir
audit(1111505098.114:0): avc:  denied  { search } for  pid=12690
exe=/usr/sbin/rndc name=etc dev=md1 ino=1368193 scontext=root:system_r:ndc_t
tcontext=root:object_r:file_t tclass=dir
audit(1111505098.114:0): avc:  denied  { read } for  pid=12690
exe=/usr/sbin/rndc name=ld.so.cache dev=md1 ino=1370938
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file
audit(1111505098.114:0): avc:  denied  { getattr } for  pid=12690
exe=/usr/sbin/rndc path=/etc/ld.so.cache dev=md1 ino=1370938
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file
audit(1111505098.114:0): avc:  denied  { read } for  pid=12690
exe=/usr/sbin/rndc name=libcrypto.so.4 dev=md1 ino=211792
scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=lnk_file
audit(1111505098.118:0): avc:  denied  { execute } for  pid=12690
path=/lib/libcrypto.so.0.9.7a dev=md1 ino=214229 scontext=root:system_r:ndc_t
tcontext=root:object_r:file_t tclass=file






More information about the fedora-selinux-list mailing list