Bug 867432 - SELinux prevents NM for unlinking /etc/resolv.conf
SELinux prevents NM for unlinking /etc/resolv.conf
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 09:51 EDT by Tomáš Bžatek
Modified: 2015-03-03 18:05 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-07 20:20:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomáš Bžatek 2012-10-17 09:51:25 EDT
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 09:56:11 EDT
(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 08:54:29 EDT
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 05:21:48 EDT
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 05:33:07 EDT
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 10:10:37 EDT
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-07 20:20:00 EDT
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.

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