Bug 864723 - SELinux is preventing /usr/sbin/plymouthd from 'block_suspend' accesses on the capability2 .
SELinux is preventing /usr/sbin/plymouthd from 'block_suspend' accesses on th...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-09 20:50 EDT by Neil
Modified: 2012-11-21 02:28 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-21 02:28:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File: type (9 bytes, text/plain)
2012-10-09 20:50 EDT, Neil
no flags Details
File: hashmarkername (14 bytes, text/plain)
2012-10-09 20:50 EDT, Neil
no flags Details

  None (edit)
Description Neil 2012-10-09 20:50:16 EDT
Description of problem:
This occurs on each boot.

Additional info:
libreport version: 2.0.15
kernel:         3.6.0-0.rc6.git0.2.fc18.x86_64

:SELinux is preventing /usr/sbin/plymouthd from 'block_suspend' accesses on the capability2 .
:*****  Plugin catchall (100. confidence) suggests  ***************************
:If you believe that plymouthd should be allowed block_suspend access on the  capability2 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 plymouthd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:Additional Information:
:Source Context                system_u:system_r:plymouthd_t:s0
:Target Context                system_u:system_r:plymouthd_t:s0
:Target Objects                 [ capability2 ]
:Source                        plymouthd
:Source Path                   /usr/sbin/plymouthd
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           plymouth-0.8.7-1.fc18.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.11.1-32.fc18.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.6.0-0.rc6.git0.2.fc18.x86_64 #1
:                              SMP Mon Sep 17 17:29:08 UTC 2012 x86_64 x86_64
:Alert Count                   14
:First Seen                    2012-09-11 23:35:38 PDT
:Last Seen                     2012-10-09 12:40:40 PDT
:Local ID                      863f64c3-6b9d-4e3c-a058-037aa5e00bc6
:Raw Audit Messages
:type=AVC msg=audit(1349811640.134:129): avc:  denied  { block_suspend } for  pid=3410 comm="plymouthd" capability=36  scontext=system_u:system_r:plymouthd_t:s0 tcontext=system_u:system_r:plymouthd_t:s0 tclass=capability2
:type=SYSCALL msg=audit(1349811640.134:129): arch=x86_64 syscall=epoll_ctl success=yes exit=0 a0=3 a1=2 a2=b a3=0 items=0 ppid=1 pid=3410 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=plymouthd exe=/usr/sbin/plymouthd subj=system_u:system_r:plymouthd_t:s0 key=(null)
:Hash: plymouthd,plymouthd_t,plymouthd_t,capability2,block_suspend
:#============= plymouthd_t ==============
:allow plymouthd_t self:capability2 block_suspend;
:audit2allow -R
:#============= plymouthd_t ==============
:allow plymouthd_t self:capability2 block_suspend;
Comment 1 Neil 2012-10-09 20:50:18 EDT
Created attachment 624388 [details]
File: type
Comment 2 Neil 2012-10-09 20:50:20 EDT
Created attachment 624389 [details]
File: hashmarkername
Comment 3 Miroslav Grepl 2012-10-10 04:07:30 EDT
We have more and more domains which want this access.
Comment 4 Daniel Walsh 2012-10-10 07:49:36 EDT
The problem is that it is returning success=yes, so we don't really know if they need it or we can dontaudit it or if it is a bug in the kernel.
Comment 5 Daniel Walsh 2012-10-10 07:50:43 EDT
epoll_ctl is triggering block_suspend, does this indicate that domains actually want to block_suspend?  Or is it a bug?  Or do we not care what domains can block_suspend?
Comment 6 Stephen Smalley 2012-10-10 08:26:23 EDT
I think the relevant code is (from fs/eventpoll.c):
        /* Check if EPOLLWAKEUP is allowed */
        if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
                epds.events &= ~EPOLLWAKEUP;

So lack of the capability is not an error but merely clears the EPOLLWAKEUP flag.  So dontaudit is definitely an option, but requires examination of the caller to see if they truly want EPOLLWAKEUP semantics (prevent suspend while epoll events are ready).  Personally I think this behavior is unfortunate; a syscall should not silently change its behavior based on a permission/capability check without any indication to userspace.
Comment 7 Daniel Walsh 2012-10-11 14:14:25 EDT
Fixed in selinux-policy-3.11.1-37.fc18.noarch
Comment 8 Fedora Update System 2012-10-23 16:33:55 EDT
selinux-policy-3.11.1-43.fc18 has been submitted as an update for Fedora 18.
Comment 9 Fedora Update System 2012-10-26 11:36:50 EDT
selinux-policy-3.11.1-46.fc18 has been submitted as an update for Fedora 18.
Comment 10 Fedora Update System 2012-10-26 15:26:04 EDT
Package selinux-policy-3.11.1-46.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-46.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 11 Neil 2012-11-21 02:26:07 EST
This appears not to be occuring in the latest Fedora-Beta-TC8 install.

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