SELinux is preventing /usr/sbin/NetworkManager from 'unlink' accesses on the file /etc/resolv.conf. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that NetworkManager should be allowed unlink access on the resolv.conf file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep NetworkManager /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:getty_etc_t:s0 Target Objects /etc/resolv.conf [ file ] Source NetworkManager Source Path /usr/sbin/NetworkManager Port <Unknown> Host (removed) Source RPM Packages NetworkManager-0.9.7.0-6.git20121004.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-36.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8 17:19:09 UTC 2012 x86_64 x86_64 Alert Count 7 First Seen 2012-10-15 11:25:04 EDT Last Seen 2012-10-17 09:39:13 EDT Local ID 2838686d-d29e-4404-a740-9112d3df2fa2 Raw Audit Messages type=AVC msg=audit(1350481153.617:457): avc: denied { unlink } for pid=517 comm="NetworkManager" name="resolv.conf" dev="vda3" ino=260115 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:getty_etc_t:s0 tclass=file type=SYSCALL msg=audit(1350481153.617:457): arch=x86_64 syscall=rename success=no exit=EACCES a0=2213890 a1=21ac4d0 a2=3864db1798 a3=15 items=0 ppid=1 pid=517 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=NetworkManager exe=/usr/sbin/NetworkManager subj=system_u:system_r:NetworkManager_t:s0 key=(null) Hash: NetworkManager,NetworkManager_t,getty_etc_t,file,unlink audit2allow #============= NetworkManager_t ============== allow NetworkManager_t getty_etc_t:file unlink; audit2allow -R #============= NetworkManager_t ============== allow NetworkManager_t getty_etc_t:file unlink;
(crappy sealert browser is preventing me to file it automatically and is eating my comments) Anyway, this is a clean and fully updated F18 install. What I was trying to do was to specify custom DNS for a network connection, ignoring assignment from DHCP. However, /etc/resolv.conf still contained the old information. Manually removing that file make NM successfully writing new configuration. The original file may have been written by instalator and had wrong file contexts. Since NM task is to repair network settings, suggesting to allow unlinking /etc/resolv.conf by NM having any file context.
Even though this bugreport is primarily about SELinux policy, there's one thing NM could do: when unlink(2) fails, inform user that the file cannot be deleted and an old configuration will stay active. Not sure where in the stack the call is burried but we need to inform user to expect troubles. I found the /etc/resolv.conf issues by accident, NetwokManager silently succeeded.
Ok, /etc/resolv.conf has definitely bad labeling. If you execute # restorecon -R -v /etc/resolv.con does it happen again? We need to find a reason why is mislabeled.
The file context is now system_u:object_r:net_conf_t:s0 and been this since I forcefully removed the file and let dhclient recreate it. No idea who has set the wrong initial label, probably a post-installation issue. Too late to find that out now. My bugreport was about allowing unlinking /etc/resolv.conf having any file context from NetworkManager side (or related tools like dhclient or dhcpcd) if possible.
Not sure where this bug should belong, but this is a labeling issue. If the file was originally created by Anaconda or any other process during installation, there should be a way how to set the right context - i.e. relabeling. But it seems it hasn't been done post-installation. Alternatively, adding restorecond watch may fix the issue as well. Reassigning to Anaconda for consideration.
We run restorecon on this in a post script, it has: system_u:object_r:net_conf_t:s0 on it after a minimal install.