Bug 1373882

Summary: SELinux prevents NetworkManager from removing resolv.conf
Product: Red Hat Enterprise Linux 7 Reporter: Stef Walter <stefw>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: lvrabec, mgrepl, mmalik, plautrba, pvrabec, ssekidde, stefw, yuma
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-23 20:54:52 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:

Description Stef Walter 2016-09-07 11:16:15 UTC
Description of problem:

Error: type=1400 audit(1473246547.731:4): avc:  denied  { unlink } for  pid=463 comm="NetworkManager" name="resolv.conf" dev="vda3" ino=11215288 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

Version-Release number of selected component (if applicable):

NetworkManager-1.4.0-0.5.beta1.el7.x86_64
selinux-policy-targeted-3.13.1-93.el7.noarch
selinux-policy-3.13.1-93.el7.noarch

How reproducible:

This bug was found by the Cockpit integration tests. Happens regularly with RHEL 7.3 beta.

https://fedorapeople.org/groups/cockpit/logs/pull-4975-3cb86143-verify-rhel-7/log.html#87

Comment 2 Milos Malik 2016-09-07 13:43:37 UTC
Where is the resolv.conf file located? If it is the /etc directory then the file is mislabeled, because correct label is:

# matchpathcon /etc/resolv.conf 
/etc/resolv.conf	 system_u:object_r:net_conf_t:s0
#

Comment 4 Ma Yuying 2016-09-28 03:08:21 UTC
I hit the similar info when ran the team related job, as follows:
And I'm not sure it's the same issue as comment #1 saied. If not,please let me know, I will open a new bug.

Info: Searching AVC errors produced since 1474910072.73 (Mon Sep 26 13:14:32 2016)
Searching logs...
Running '/usr/bin/env LC_ALL=en_US.UTF-8 /sbin/ausearch -m AVC -m USER_AVC -m SELINUX_ERR -ts 09/26/2016 13:14:32 < /dev/null >/mnt/testarea/tmp.rhts-db-submit-result.N1izAV 2>&1'
----
time->Mon Sep 26 13:14:33 2016
type=SYSCALL msg=audit(1474910073.167:267): arch=c000003e syscall=62 success=yes exit=0 a0=6820 a1=f a2=0 a3=6820 items=0 ppid=11483 pid=29358 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="teamd" exe="/usr/bin/teamd" subj=system_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(1474910073.167:267): avc:  denied  { signal } for  pid=29358 comm="teamd" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:unconfined_r:unconfined_t:s0 tclass=process
Fail: AVC messages found.
Checking for errors...
Using stronger AVC checks.
	Define empty RHTS_OPTION_STRONGER_AVC parameter if this causes any problems.
Running 'cat /mnt/testarea/tmp.rhts-db-submit-result.N1izAV | /sbin/ausearch -m AVC -m SELINUX_ERR'
Fail: AVC messages found.
Running 'cat %s | /sbin/ausearch -m USER_AVC >/mnt/testarea/tmp.rhts-db-submit-result.kknRxs 2>&1'
Info: No AVC messages found.
/bin/grep 'avc: ' /mnt/testarea/dmesg.log | /bin/grep --invert-match TESTOUT.log
No AVC messages found in dmesg
Running '/usr/sbin/sestatus'
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
Running 'rpm -q selinux-policy || true'
selinux-policy-3.13.1-100.el7.noarch

Comment 6 Milos Malik 2017-08-17 08:36:41 UTC
Is it still relevant? Do you still see SELinux denials mentioned in comment#0?

Comment 7 Stef Walter 2017-08-21 06:54:18 UTC
As far as I can tell, this is no longer an issue.

Comment 8 Lukas Vrabec 2017-08-23 20:54:52 UTC
Thanks Stef for info.