Bug 1264423 - SELinux is preventing colord from 'getattr' accesses on the file /proc/<pid>/cgroup.
SELinux is preventing colord from 'getattr' accesses on the file /proc/<pid>/...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
low Severity low
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-09-18 08:35 EDT by Brendan Shephard
Modified: 2015-10-13 07:02 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-13 07:02:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brendan Shephard 2015-09-18 08:35:53 EDT
Description of problem:
I was unable to start vncserver using $ systemctl start vncserver@:1  error message being received: " Failed to get properties: Access Denied. 

Same result for systemctl status vncserver@:1 (being run as root.)

Noticed Audit denials from SELINUX in journalctl:

Sep 18 22:20:38 BNE audit: <audit-1107> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  received setenforce notice (enforcing=1)#012 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Sep 18 22:20:38 BNE audit: <audit-1107> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=1000 uid=0 gid=0 path="/usr/lib/systemd/system/vncserver@:1.service" cmdline="systemctl status vncserver@:1" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:systemd_unit_file_t:s0 tclass=service#012 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Set selinux to permissive and was able to start vncserver. Setting selinux back to enforcing leaves vncserver running without further issue so far.
SELinux is preventing colord from 'getattr' accesses on the file /proc/<pid>/cgroup.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that colord should be allowed getattr access on the cgroup file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep colord /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:colord_t:s0
Target Context                system_u:system_r:unconfined_service_t:s0
Target Objects                /proc/<pid>/cgroup [ file ]
Source                        colord
Source Path                   colord
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.13.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 4.1.6-201.fc22.x86_64 #1 SMP Fri
                              Sep 4 17:49:24 UTC 2015 x86_64 x86_64
Alert Count                   1
First Seen                    2015-09-18 22:17:16 AEST
Last Seen                     2015-09-18 22:17:16 AEST
Local ID                      fcdb83a0-ca05-43de-b50c-d57792123ac0

Raw Audit Messages
type=AVC msg=audit(1442578636.540:1202): avc:  denied  { getattr } for  pid=1373 comm="colord" path="/proc/1968/cgroup" dev="proc" ino=26501 scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1

Hash: colord,colord_t,unconfined_service_t,file,getattr

Version-Release number of selected component:

Additional info:
reporter:       libreport-2.6.2
hashmarkername: setroubleshoot
kernel:         4.1.6-201.fc22.x86_64
type:           libreport

Potential duplicate: bug 1205019
Comment 1 Miroslav Grepl 2015-10-09 04:23:18 EDT
What does on your system

$ ps -efZ |grep unconfined_service
Comment 2 Brendan Shephard 2015-10-09 08:19:06 EDT
I believe this issue was an issue with the last SELinux and Systemd update (in the same dnf update run). 

It was something to do with the order that the updates got installed. Trying to reboot the system from the GUI wouldn't do anything. When I tried via $ reboot. I got the error, : Failed to get reboot.service: Permission denied   

Any process that I tried to start, stop or restart would give me the same error. To resolve the issue, I had to use $ setenforce 0 && reboot

After a successful reboot it seemed to be fine with selinux enforcing. 

I'll mark it as resolved. However, it should be noted that I've experienced the same issue with CentOS after an update that contained SELinux and Systemd in the same run. Maybe we could package those updates separately in the future to avoid disruptions to production machines?
Comment 3 Miroslav Grepl 2015-10-13 07:02:11 EDT
Yes, it relates with changes in the policy and daemon reexec was needed. We have fixes for this in libselinux to avoid it in the future. Thank you.

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