Description of problem: SELinux is preventing /usr/sbin/killall5 from using the 'sys_ptrace' capabilities. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that killall5 should have the sys_ptrace capability 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 pidof /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Objects [ capability ] Source pidof Source Path /usr/sbin/killall5 Port <Unknown> Host (removed) Source RPM Packages sysvinit-tools-2.88-10.dsf.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-47.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.4-300.fc19.x86_64 #1 SMP Fri May 24 22:17:06 UTC 2013 x86_64 x86_64 Alert Count 11 First Seen 2013-05-29 21:15:27 EDT Last Seen 2013-05-29 21:15:27 EDT Local ID 815159ea-ed01-43e1-aeb9-a7f959e4a73c Raw Audit Messages type=AVC msg=audit(1369876527.611:83): avc: denied { sys_ptrace } for pid=353 comm="pidof" capability=19 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1369876527.611:83): arch=x86_64 syscall=stat success=no exit=EACCES a0=7fff5fc96140 a1=7fff5fc960b0 a2=7fff5fc960b0 a3=3 items=0 ppid=341 pid=353 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=pidof exe=/usr/sbin/killall5 subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) Hash: pidof,abrt_t,abrt_t,capability,sys_ptrace Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: Immediately after desktop starts Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.8.13-201.rt8.1.fc19.x86_64.rt type: libreport
Description of problem: Occurs immediately after desktop starts... Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.8.13-201.rt8.1.fc19.x86_64.rt type: libreport
Description of problem: This alert showed but just after a reboot. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: When desktop starts Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: Just logged in after system update and reboot. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: This happens at boot. It is reproducible in every single boot. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: Booted up Fedora 19 after updating to the latest packages. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.i686 type: libreport
Description of problem: First boot of Fedora 19 today. Installed updates yesterday. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Description of problem: Also from trying to do a cp -a /sys /run/media/klaus/Bigdisk2/Backup_Fedora19/ Selinux moaning about the usr/bin/killall5 trying to access capability with help of sys_ptrace I found out that there is a loophole when following /sys/devices: /sys/devices/tracepoint/subsystem/devices/tracepoint/subsystem/devices/tracepoint ... and so on Definitely supporting developers should be aware and care about those loophole traps in the sys/subsystem before the Fedora 19 can be released in stable condition. Though I do see an error in the Selinux program making an issue out of complaining about capability infiltration by killall5 with help of systrace. In my general insight the fault seems with Selinux again. No way that accessing capability does any harm if sys_ptrace is used for that purpose. This has been tested long and short. Compared to that the loophole complex in the /sys subsystem effects workability and backup capabilities far worse. It wastes all fair gains I've made so far. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.i686.PAE type: libreport
Added to selinux-policy-3.12.1-48.fc19
Description of problem: Booted a live image I just built - F19 desktop live with latest spin-kickstarts and packages from 'stable' f19 repo plus a few side repo pulls (it's a pre-Final TC1 test image). AVC was present on boot. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
Final blocker, criterion "In most cases, there must be no SELinux 'AVC: denied' messages or abrt crash notifications on initial boot and subsequent login (see Blocker_Bug_FAQ)".
-48 fix tested, a live image with -48 included doesn't show the AVC.
Description of problem: right after booting and logging in to gnome Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.i686.PAE type: libreport
Description of problem: right after boot up.. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-301.fc19.x86_64 type: libreport
Discussed at 2013-06-05 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt . Accepted as a blocker per Final criterion "There must be no SELinux denial notifications or crash notifications after boot of a release-blocking live image or at first login after a default install of a release-blocking desktop."
Description of problem: Got this error as son as I logged-in from a cold boot. Not entirely sure why this happened. Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-300.fc19.x86_64 type: libreport
selinux-policy-3.12.1-48.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-48.fc19
Package selinux-policy-3.12.1-48.fc19: * should fix your issue, * was pushed to the Fedora 19 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.12.1-48.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10204/selinux-policy-3.12.1-48.fc19 then log in and leave karma (feedback).
Description of problem: right after boot up Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.4-301.fc19.x86_64 type: libreport
selinux-policy-3.12.1-48.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.