Description of problem: Occasionally, there is a bootup or shutdown error which appears concerning not being able to create or delete /etc/resolv.conf.predhclient.eth0 (for the exact messages, google this filename). The following are audit messages in /var/log/messages appearing at the same time. The ethernet interface came up normally despite the error message. I was able to fix this once before by deleting this file manually but that shouldn't be necessary. Jun 15 15:31:37 localhost kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex Jun 15 15:31:37 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Jun 15 15:31:37 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Jun 15 15:31:37 localhost kernel: type=1400 audit(1213558295.809:4): avc: denied { write } for pid=1790 comm="cp" name="resolv.conf.predhclient.eth0" dev=dm-0 ino=3687891 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file Jun 15 15:31:37 localhost kernel: type=1400 audit(1213558295.809:5): avc: denied { unlink } for pid=1790 comm="cp" name="resolv.conf.predhclient.eth0" dev=dm-0 ino=3687891 scontext=system_u:system_r:dhcpc_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file Jun 15 15:31:38 localhost rpc.statd[1914]: Version 1.1.2 Starting Version-Release number of selected component (if applicable): audit-1.7.4-1.fc9.i386 How reproducible: don't know Steps to Reproduce: don't know how
You may have some mislabled files. You can try fixing them by: restorecon -R /etc The above message doesn't look like an audit problem. Its just the bearer of bad news much like syslog is.
I deleted the offending file manually a while ago to get rid of the error message, and it hasn't reappeared yet. The question is, if what you are saying is true, is how did the files get mislabeled in the first place? I never run any SELinux-related commands manually. If you can make an educated guess I'll reassign this bug to another component. By the way, when the error message was appearing, it didn't seem to be interfering with the normal operation of the network on bootup or shutdown, it was simply annoying.
One other possibly important detail is that I'm using network, not NetworkManager.
Do you have restorecond installed and running? Its job is to fix the contexts of files that are not created in a SE Linux safe way. I don't have much else to offer since I work on audit and not SE Linux policy/utilities. Your bug is not with audit, but likely a SE Linux component or policy. Audit is a logging system much like syslog and not the origin of the problem regardless of what the message says. :)
I do have a restorecond process running (I basically just left everything SELinux-related at its defaults since I don't understand it). I'll switch the component to selinux-policy.
Some process created the file with the wrong context. Potentially system-config-network. If a file is created in the /etc by a user or a process that is run by a user without a transition, the file would be created as etc_t. This tool has a bug and should have created the file with the same context as /etc/resolv.conf which is net_conf_t. If you know of a tool that might have created the file, then we need to fix that tool.
[andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.predhclient.eth0 Then I used system-config-network to deactivate the ethernet interface. [andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf Finally, I used system-config-network to activate the ethernet interface again. [andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf -rw-r--r-- root root unconfined_u:object_r:etc_t:s0 resolv.conf.predhclient.eth0 Looks like your suspicion is correct. Presumably I will get the same error upon shutdown again.
Created attachment 310613 [details] Patch to maintain proper SELinux context When dhcp-client is creating files it is creating them with the wrong context.
I mean /sbin/dhclient-script
When rebooting, I did indeed get the same error. I then deleted the file manually.
dhcp-4.0.0-18.fc9 has been submitted as an update for Fedora 9
dhcp-4.0.0-18.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7234
dhcp-4.0.0-18.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
I received update emails for both dhcp-4.0.0-17.fc9 and dhcp-4.0.0-18.fc9, however only the first has been pushed. The current version in the updates-newkey repo is still 17.
Should also mention that release 18 doesn't even exist in the testing repo anymore, so there's no easy way to get it. Someone please get 18 released, to match the update email that went out almost 2 weeks ago and finally fix this bug.
-18 has been pushed to the stable updates repository.
I applied the libdhcp4client-4.0.0-18.fc9.i386 and dhclient-4.0.0-18.fc9.i386 updates and then tried bringing eth0 down and up again using system-config-network. Below is what happens to resolv.conf* : before bringing eth0 down: [andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.bak -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.predhclient.eth0 after bringing eth0 down: [andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.bak after bringing eth0 back up: [andre@localhost etc]$ ls -lZ resolv.conf* -rw-r--r-- root root unconfined_u:object_r:net_conf_t:s0 resolv.conf -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.bak -rw-r--r-- root root system_u:object_r:net_conf_t:s0 resolv.conf.predhclient.eth0 The problem with resolv.conf.predhclient.eth0 is fixed, but the permissions on resolv.conf have changed. Is this a problem?
dhcp-4.0.0-20.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/dhcp-4.0.0-20.fc9
Ahh, good catch. I've think I have it fixed in dhcp-4.0.0-20.fc9. I'm submitted that and pushed it to updates-testing. Please try it when it shows up. Thanks.
dhcp-4.0.0-20.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8594
Broken worse than before. The permissions on resolv.conf.predhclient.eth0 are wrong immediately after booting, but are corrected if one stops and restarts eth0 with s-c-network. On the other hand, the permissions on resolv.conf start out correct, but are wrong after stopping/restarting eth0. To make sure this works properly, please make sure that the permissions on ALL /etc/resolv.conf* files are correct both immediately after booting, AND again after stopping/restarting eth0. I tried leaving negative feedback at the given URL, but there is a server error preventing it.
Ignore what I said about the permissions on resolv.conf.predhclient.eth0 being wrong after booting - I just checked, and all resolv.conf* files had the correct permissions before stopping and restarting eth0 with s-c-n (but not after). There must have been bad permissions left over from before. The only remaining problem I see is that after stopping and restarting eth0 with s-c-network, the permissions on /etc/resolv.conf are wrong: -rw-r--r-- root root unconfined_u:object_r:net_conf_t:s0 /etc/resolv.conf So it's broken about as bad as before, just in a different way. I was able to leave feedback earlier, but forgot to log in, so it's as "Anonymous Tester".
Sounds like a new problem now, but with s-c-network. File a new bug against that component rather than changing the ownership of this component. Thanks.
Filed new bug #469121.
Have been told over there that this is, in fact, still a dhcp bug, since s-c-n does not change resolv.conf on stop/restart. Reopening.
My knowledge going in to this: /sbin/dhclient-script calls restorecon to make sure selinux context is set correctly on /etc/resolv.conf.predhclient.* files as well as the /etc/ntp.conf backup files. dhclient-script calls change_resolv_conf() from /etc/sysconfig/network-scripts/network-functions to actually write out a new /etc/resolv.conf file. change_resolv_conf() calls restorecon to set the selinux linux context on the new /etc/resolv.conf. Investigating has revealed the following: 1) restorecond monitors /etc/resolv.conf and resets the selinux context. Both system_u:object_r:etc_t:s0 and unconfined_u:object_r:etc_t:s0 appear to please restorecond. 2) If I down the interface in s-c-network, remove all existing /etc/resolv.conf* files, and create a new /etc/resolv.conf file using vim, the context is system_u:object_r:etc_t:s0. 3) Bringing the interface up in s-c-network, the new /etc/resolv.conf file is now unconfined_u:object_r:etc_t:s0 and the /etc/resolv.conf.predhclient.* file is system_u:object_r:etc_t:s0. 4) Running restorecon /etc/resolv.conf does not change unconfined_u to system_u, so I don't know what's causing that. Running it with -vv shows that it tries to reset it to system_u:object_r:etc_t:s0, but doesn't: # restorecon -vv /etc/resolv.conf restorecon reset /etc/resolv.conf context unconfined_u:object_r:net_conf_t:s0->system_u:object_r:net_conf_t:s0 # ls -lZ /etc/resolv.conf -rw-r--r-- root root unconfined_u:object_r:net_conf_t:s0 /etc/resolv.conf restorecon seems to be failing here, or it's failing because a policy change needs to take place. I'm not quite sure. Reassigning to policycoreutils.
unconfined_u:object_r:net_conf_t:s0 is the right context for /etc/resolv.conf if a user (unconfined_u) through the use of s-c-n has manipulated the file. system_u means that a system service manipulated the file. SELinux confined applications will not care about it, they are only concerned about the net_conf_t (The type). So the system seems to be working correctly. If you want to change the context to system_u, you can force it with a restorecon -F /etc/resolv.conf. But the user component of the SELinux policy is not important when making these security decisions with SELinux targeted policy.