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
On Tue, 2005-03-22 at 15:30 +0000, Ruth Ivimey-Cook wrote:
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
This suggests that your filesystem isn't labeled. Touch /.autorelabel and reboot, or manually boot single-user and run /sbin/fixfiles relabel. Did you install with SELinux enabled, or try enabling it later? How did you enable it?
This suggests that your filesystem isn't labeled. Touch /.autorelabel and reboot, or manually boot single-user and run /sbin/fixfiles relabel. Did you install with SELinux enabled, or try enabling it later? How did you enable it?
It is a fresh install of FC3, installed with targetted as default policy. I.e. I have changed nothing since the install (except updating rpms with "yum".
Is there some doc on what relabelling means?
Ruth
On Tue, 2005-03-22 at 16:11 +0000, Ruth Ivimey-Cook wrote:
It is a fresh install of FC3, installed with targetted as default policy. I.e. I have changed nothing since the install (except updating rpms with "yum".
Did you preserve any existing filesystems from a prior install of Fedora Core? If so, then they wouldn't get labeled automatically.
Is there some doc on what relabelling means?
Assigning security contexts (labels) to the files, stored as extended attributes of the inode.
http://fedora.redhat.com/docs/selinux-faq-fc3/ http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ http://www.nsa.gov/selinux/papers/policy2/t1.html
Did you preserve any existing filesystems from a prior install of Fedora Core? If so, then they wouldn't get labeled automatically.
This was a fresh install fs-wise, although I did copy files from the previous setup using /bin/cp. The old filesystems aren't in use anymore however.
I'll do the relabel thing and see...
Ruth
On Tue, 2005-03-22 at 16:11 +0000, Ruth Ivimey-Cook wrote:
This suggests that your filesystem isn't labeled. Touch /.autorelabel and reboot, or manually boot single-user and run /sbin/fixfiles relabel. Did you install with SELinux enabled, or try enabling it later? How did you enable it?
It is a fresh install of FC3, installed with targetted as default policy. I.e. I have changed nothing since the install (except updating rpms with "yum".
Did you perhaps create a new filesystem (md1)? Any new filesystems that contain data used by a targeted daemon have to be labeled.
This Fedora FAQ is relevant: http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2826352
Is there some doc on what relabelling means?
There's some documentation here:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/rh...
On Tue, 2005-03-22 at 10:48 -0500, Stephen Smalley wrote:
This suggests that your filesystem isn't labeled. Touch /.autorelabel and reboot, or manually boot single-user and run /sbin/fixfiles relabel.
I've done that, and it does seem to have fixed the problems with named and dhcpd. At least, there are no more avc messages.
However, it seems to have disabled my web server. I guess this is because I'm strange and prefer the web root to be /web, not /var/www.
I have tried adding lines (below) into apache.fc and then running 'make' in src/policy, but it didn't help.
HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t /web(/.*)? system_u:object_r:httpd_sys_content_t /web/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t /var/www(/.*)? system_u:object_r:httpd_sys_content_t /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t
I later tried adding the audit2allow lines to apache.te and running make, but that failed too.
allow httpd_t default_t:dir { getattr search }; allow httpd_t default_t:file { getattr read }; allow httpd_t default_t:lnk_file read;
What am I doing wrong?
Ruth
Try running
restorecon -v -R /web
after the apache.fc changes and running make reload.
you will probably see a ls -Z /web does not show up as system_u:object_r:httpd_sys_content_t. Before you run the restorecon.
Eric
On Tue, 2005-03-22 at 21:09 +0000, Ruth Ivimey-Cook wrote:
On Tue, 2005-03-22 at 10:48 -0500, Stephen Smalley wrote:
This suggests that your filesystem isn't labeled. Touch /.autorelabel and reboot, or manually boot single-user and run /sbin/fixfiles relabel.
I've done that, and it does seem to have fixed the problems with named and dhcpd. At least, there are no more avc messages.
However, it seems to have disabled my web server. I guess this is because I'm strange and prefer the web root to be /web, not /var/www.
I have tried adding lines (below) into apache.fc and then running 'make' in src/policy, but it didn't help.
HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t /web(/.*)? system_u:object_r:httpd_sys_content_t /web/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t /var/www(/.*)? system_u:object_r:httpd_sys_content_t /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t
I later tried adding the audit2allow lines to apache.te and running make, but that failed too.
allow httpd_t default_t:dir { getattr search }; allow httpd_t default_t:file { getattr read }; allow httpd_t default_t:lnk_file read;
What am I doing wrong?
Ruth
On Tue, 2005-03-22 at 16:13 -0500, Eric Paris wrote:
restorecon -v -R /web
after the apache.fc changes and running make reload.
you will probably see a ls -Z /web does not show up as system_u:object_r:httpd_sys_content_t. Before you run the restorecon.
Yea! That did it.
Thanks,
selinux@lists.fedoraproject.org
-
Colin Walters -
Eric Paris -
Ruth Ivimey-Cook -
Stephen Smalley