Bug 244167 - SELinux set to Enforcing prevents /etc/resolv.conf being written on start-up
Summary: SELinux set to Enforcing prevents /etc/resolv.conf being written on start-up
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 6
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-14 09:44 UTC by David Hislop
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-09-14 17:45:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Messages about resolv.conf in /var/log/messages* (2.59 KB, text/plain)
2007-06-22 10:06 UTC, David Hislop
no flags Details
Output of dmesg in SELinux Enforcing mode (86.11 KB, text/plain)
2007-06-30 04:33 UTC, David Hislop
no flags Details
Output of dmesg in SELinux Permissive mode (22.75 KB, text/plain)
2007-06-30 04:34 UTC, David Hislop
no flags Details

Description David Hislop 2007-06-14 09:44:09 UTC
Description of problem:
DNS lookups stopped working. I tracked it down to an empty /etc/resolv.conf. I
guessed it was an issue with SELinux and used the big hammer and disabled it
(OK, in retrospect, that wasn't such a great idea, and Permissive would have
been a better first step).
After rebooting, /etc/resolv.conf was filled in properly by dhclient-script and
DNS lookups worked again.

Version-Release number of selected component (if applicable):
selinux-policy - 2.4.6-74.fc6.noarch - SELinux policy configuration

How reproducible:
Very, until I turned off SELinux.

Steps to Reproduce:
Not really sure, but I suspect that it was the last set of updates I installed
earlier this week that caused the issue. Evidence is that I'd installed a set of
updates a couple of weeks ago that required a reboot, and internet access was
working fine then. After the last reboot, I'd had no more update notifications
(which I considered a little strange), then the first time I directly tried
internet access, it couldn't find the server. Or any server.
  
Actual results:


Expected results:


Additional info:

Comment 1 Daniel Walsh 2007-06-14 13:15:44 UTC
Does 

restorecon /etc/resolv.conf

Fix your problem?

Somehow it must have gotten mislabeled.  You can use restorecond to make sure
the context stays correct.

Comment 2 David Hislop 2007-06-14 22:54:41 UTC
I'll set SELinux back to Enforcing and try it, but I expect that just setting it
to Enforcing will relabel the entire file system anyway.

This might not be related, as I have two machines with the same log messages,
but there are a few messages like this in the log file going back before I
noticed this issue:
Jun 13 19:33:54 narbalek restorecond: Will not restore a file with more than one
hard link (/etc/resolv.conf) Invalid argument

I'll update this after re-enabling SELinux.

thanks - David

Comment 3 David Hislop 2007-06-15 00:07:36 UTC
Changing SELinux to Enforcing relabelled the file system, but didn't fix the
problem. /etc/resolv.conf was blank after boot. /etc/resolv.conf/predhclient
contained the expected entries.

/sbin/restorecon -v /etc/resolv.conf showed no changes being made.

When I had the problem before, and now after re-enabling SELinux, I get 7 log
messages like this one every 15 seconds:
Jun 15 09:13:10 narbalek kernel: audit(1181862790.877:233): avc:  denied  {
node_bind } for  pid=1891 comm="nscd" scontext=system_u:system_r:nscd_t:s0
tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=udp_socket

Does that have anything to do with it?

I have another near-identical but working system that is NOT getting those errors.

regards - David

Comment 4 Daniel Walsh 2007-06-15 12:50:36 UTC
What file is hard linked to resolv.conf?  This might be causing your problem.

ls -lZ /etc/resolv.conf

I have never seen nscd try to bind to that node before, but might be related.



Comment 5 David Hislop 2007-06-16 00:02:47 UTC
It's linked to /etc/sysconfig/networking/profiles/default/resolv.conf
Same on my other machine. I've just checked and it's getting the same messages
in the log file, so I don't think that's the issue.

Ran the command above:
[root@narbalek david]# ls -lZ /etc/resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t     /etc/resolv.conf

I also found similar audit errors on the other machine, but there is one error
about every hour from 8:30am yesterday to 1:30pm, then none after that, plus two
groups of two 30 seconds apart at 9:38am. Interestingly, that'a about when I was
composing Comment #3.

Comment 6 Daniel Walsh 2007-06-18 16:10:55 UTC
And you are seeing no avc messages about net_conf_t or resolv.conf in
/var/log/audit/audit.log or /var/log/messages?

Comment 7 David Hislop 2007-06-22 10:06:26 UTC
Created attachment 157604 [details]
Messages about resolv.conf in /var/log/messages*

Comment 8 David Hislop 2007-06-22 11:47:22 UTC
1. I have no /var/log/audit directory.

2. There are no messages at all in /var/log/messages* about net_conf_t.

3. All the messages in /var/log/messages* about resolv.conf are in the
attachment varlogmessages.txt.

thanks - David

Comment 9 Daniel Walsh 2007-06-22 15:04:25 UTC
Does dmesg show anything?

This is strange.  If you boot in permissive mode "enfocing=0"  Does the file get
created with the correct context?

Comment 10 David Hislop 2007-06-30 04:29:26 UTC
Booted again in Enforcing, and the problem was the same: /etc/resolv.conf was
blank. Note that /etc/resolv.conf.predhclient was created correctly, so it seems
to be an error occurring when /sbin/dhclient-script updates /etc/resolv.conf.

I've attached the output of dmesg in Enforcing as bootmessages_enforcing.txt.

Booted again in Permissive, and the problem goes away. /etc/resolv.conf is
correct, and DNS access works.

Ran this again, same results as before with Enforcing on.
[root@narbalek regression]# ls -lZ /etc/resolv.conf
-rw-r--r--  root root system_u:object_r:net_conf_t     /etc/resolv.conf

I've attached the output of dmesg in Permissive as bootmessages_permissive.txt.

regards - David

Comment 11 David Hislop 2007-06-30 04:33:25 UTC
Created attachment 158284 [details]
Output of dmesg in SELinux Enforcing mode

Comment 12 David Hislop 2007-06-30 04:34:03 UTC
Created attachment 158285 [details]
Output of dmesg in SELinux Permissive mode

Comment 13 David Hislop 2007-09-04 07:22:20 UTC
Was the dmesg output I sent a couple of months ago of no help with this bug?

Comment 14 Daniel Walsh 2007-09-04 13:37:18 UTC
Sorry you dropped between the cracks.

This looks like you have a tmp directory labeled public_content_rw_t
This is most likely wrong

audit2allow -i /tmp/t | grep public_content_rw_t
allow automount_t public_content_rw_t:dir mounton;
allow dhcpc_t public_content_rw_t:dir getattr;
allow mysqld_t public_content_rw_t:dir { read search };
allow ntpd_t public_content_rw_t:dir search;
allow rhgb_t public_content_rw_t:dir search;
allow xfs_t public_content_rw_t:dir search;

Did you relabel /tmp or something public_content_rw_t?

This could be causing problems.

ntpd should be allowed to read samba files in latest release, which I have never
seen before

nscd trying to read samba files is not something I have seen before.

Comment 15 David Hislop 2007-09-05 04:04:05 UTC
How do I relabel /tmp?

It's certainly labelled public_content_rw_t on the machine that has the 
problem, and tmp_t on the machine that's OK. But I don't really know how that 
happened.

I've just tried
/sbin/restorecon -nv /tmp
and it produced no output, also
/sbin/fixfiles check /tmp
and it also produced no output.

I've also ferreted around through the selinux and associated man pages and 
drawn a blank on changing /tmp to tmp_t.

If you can let me know, I'd appreciate it.

Note: I have completely relabelled the file system a couple of times, so I 
would have expected that would have fixed /tmp. Apparently not?

Note also that both machines seem to have identical SELinux configurations 
from paging through the GUI tool at menu System>Administration>Security Level 
and Firewall, SELinux, Modify SELinux Policy.

regards - David

Comment 16 Daniel Walsh 2007-09-10 14:42:17 UTC
matchpathcon /tmp

/tmp    system_u:object_r:tmp_t:s0
restorecon /tmp

Should fix it.

/tmp is a directory?

chcon -t tmp_t /tmp 

Will also fix the context.

Comment 17 David Hislop 2007-09-13 07:24:44 UTC
restorecon doesn't seem to work. Tried as user, also tried su.

[david@narbalek ~]$ restorecon -vv /tmp
restorecon: /tmp not reset customized by admin to
system_u:object_r:public_content_rw_t:s0
[david@narbalek ~]$ su -c 'restorecon -vv /tmp'
Password: 
restorecon: /tmp not reset customized by admin to
system_u:object_r:public_content_rw_t:s0

chcon did work.

[david@narbalek ~]$ su -c 'chcon -t tmp_t /tmp'
Password: 
[david@narbalek ~]$ matchpathcon -V /tmp
/tmp verified.

Also, it looks like I had to do it recursively for /tmp, so I used
su -c 'chcon -t tmp_t -R -v /tmp'

Now I'll try changing back to Enforcing, restart, and confirm it fixes the
original issue with /etc/resolv.conf.

Comment 18 David Hislop 2007-09-13 22:00:19 UTC
It's all fixed.

So it seems that I've unknowingly run chcon in the past, or knowingly and
forgotten about it. I don't think it's the former, and the most likely time I
would have done it was when I was getting file sharing to /tmp going. That was
many months before this resolv.conf issue arose. I wonder what triggered it?
(rhetorical)

Thanks Dan for all your assistance. I've now found
http://fedoraproject.org/wiki/SELinux, so I'll read up.



Comment 19 Daniel Walsh 2007-09-14 17:45:15 UTC
restorecon -F should work.

You should read danwalsh.livejournal.com

From the beginning.  I write a blog called SELinux for dummies.

I think you will get useful info there.

setroubleshoot might have told you to do that.  Older versions of setroubleshoot
sometimes were incorrect in their fix description.


Note You need to log in before you can comment on or make changes to this bug.