Bug 1254698 - polkitd cannot access /etc in MLS policy
polkitd cannot access /etc in MLS policy
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.1
All Linux
medium Severity medium
: rc
: ---
Assigned To: Lukas Vrabec
BaseOS QE Security Team
:
Depends On:
Blocks: 1218420
  Show dependency treegraph
 
Reported: 2015-08-18 12:52 EDT by Jiri Jaburek
Modified: 2015-08-19 10:58 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-19 10:58:11 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 Jiri Jaburek 2015-08-18 12:52:44 EDT
Description of problem:

----
type=SYSCALL msg=audit(08/18/2015 18:49:16.231:830) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7ff82ec6c363 a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=0 ppid=1 pid=725 auid=unset uid=polkitd gid=polkitd euid=polkitd suid=polkitd fsuid=polkitd egid=polkitd sgid=polkitd fsgid=polkitd tty=(none) ses=unset comm=polkitd exe=/usr/lib/polkit-1/polkitd subj=system_u:system_r:policykit_t:s0-s15:c0.c1023 key=(null) 
type=AVC msg=audit(08/18/2015 18:49:16.231:830) : avc:  denied  { search } for  pid=725 comm=polkitd name=etc dev="dm-0" ino=133 scontext=system_u:system_r:policykit_t:s0-s15:c0.c1023 tcontext=system_u:object_r:etc_t:s15:c0.c1023 tclass=dir 
----
type=SYSCALL msg=audit(08/18/2015 18:49:16.239:831) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7ff82ec6c363 a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=0 ppid=1 pid=725 auid=unset uid=polkitd gid=polkitd euid=polkitd suid=polkitd fsuid=polkitd egid=polkitd sgid=polkitd fsgid=polkitd tty=(none) ses=unset comm=polkitd exe=/usr/lib/polkit-1/polkitd subj=system_u:system_r:policykit_t:s0-s15:c0.c1023 key=(null) 
type=AVC msg=audit(08/18/2015 18:49:16.239:831) : avc:  denied  { search } for  pid=725 comm=polkitd name=etc dev="dm-0" ino=133 scontext=system_u:system_r:policykit_t:s0-s15:c0.c1023 tcontext=system_u:object_r:etc_t:s15:c0.c1023 tclass=dir 


Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-42.el7

How reproducible:
always

Steps to Reproduce:
1. ts=$(date +%T)
2. service nonexistent restart
Redirecting to /bin/systemctl restart  nonexistent.service
Failed to restart nonexistent.service: Access denied
3. ausearch -i -ts $ts -m avc
Comment 1 Miroslav Grepl 2015-08-19 01:26:17 EDT
Ok if you switch to permissive, does it work? And what AVCs are you getting in permissive?
Comment 2 Jiri Jaburek 2015-08-19 07:26:03 EDT
(In reply to Miroslav Grepl from comment #1)
> Ok if you switch to permissive, does it work? And what AVCs are you getting
> in permissive?

Yes, in permissive, systemd/systemctl correctly detects the service as nonexistent:

# ts=$(date +%T); service nonexistent restart; ausearch -i -ts $ts -m avc
Redirecting to /bin/systemctl restart  nonexistent.service
Failed to restart nonexistent.service: Unit nonexistent.service failed to load: No such file or directory.
----
type=SYSCALL msg=audit(08/19/2015 13:24:27.792:6814) : arch=x86_64 syscall=write success=yes exit=0 a0=0x4 a1=0x0 a2=0x0 a3=0x7fff5d9cf340 items=0 ppid=4648 pid=4659 auid=eal uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4 comm=systemd-tty-ask exe=/usr/bin/systemd-tty-ask-password-agent subj=staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 key=(null) 
type=AVC msg=audit(08/19/2015 13:24:27.792:6814) : avc:  granted  { setfscreate } for  pid=4659 comm=systemd-tty-ask scontext=staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 tcontext=staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 tclass=process 

though as you can see, even with disabled dontaudit, there are no denied AVCs.
Comment 3 Jiri Jaburek 2015-08-19 10:58:11 EDT
The issue was incorrect /etc context,

restorecon reset /etc context system_u:object_r:etc_t:s15:c0.c1023->system_u:object_r:etc_t:s0

and while it's still unclear what gave it c0.c1023 (SystemHigh) instead of s0 (SystemLow), the issues reported in comment #0 are a result/symptom of this change, not its cause.

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