Bug 867432

Summary: SELinux prevents NM for unlinking /etc/resolv.conf
Product: [Fedora] Fedora Reporter: Tomáš Bžatek <tbzatek>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, danw, dcbw, g.kaviyarasu, jonathan, mgrepl, mkolman, sbueno, tbzatek, tsmetana, vanmeeuwen+fedora
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-08 00:20:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomáš Bžatek 2012-10-17 13:51:25 UTC
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;

Comment 1 Tomáš Bžatek 2012-10-17 13:56:11 UTC
(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.

Comment 2 Tomáš Bžatek 2012-10-18 12:54:29 UTC
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.

Comment 3 Miroslav Grepl 2012-10-19 09:21:48 UTC
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.

Comment 4 Tomáš Bžatek 2012-10-19 09:33:07 UTC
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.

Comment 5 Tomáš Bžatek 2013-05-07 14:10:37 UTC
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.

Comment 6 Brian Lane 2013-05-08 00:20:00 UTC
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.