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 description: :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. :Do :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 : :audit2allow : :#============= plymouthd_t ============== :allow plymouthd_t self:capability2 block_suspend; : :audit2allow -R : :#============= plymouthd_t ============== :allow plymouthd_t self:capability2 block_suspend; :
Created attachment 624388 [details] File: type
Created attachment 624389 [details] File: hashmarkername
We have more and more domains which want this access.
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.
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?
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.
Fixed in selinux-policy-3.11.1-37.fc18.noarch
selinux-policy-3.11.1-43.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-43.fc18
selinux-policy-3.11.1-46.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-46.fc18
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: https://admin.fedoraproject.org/updates/FEDORA-2012-16862/selinux-policy-3.11.1-46.fc18 then log in and leave karma (feedback).
This appears not to be occuring in the latest Fedora-Beta-TC8 install.