Description of problem: SELinux is preventing /usr/lib/systemd/systemd-journald from 'sys_ptrace' accesses on the cap_userns Unknown. ***** Plugin catchall (100. confidence) suggests ************************** If vous pensez que systemd-journald devrait être autorisé à accéder sys_ptrace sur Unknown cap_userns par défaut. Then vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Do allow this access for now by executing: # ausearch -c 'systemd-journal' --raw | audit2allow -M my-systemdjournal # semodule -X 300 -i my-systemdjournal.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context system_u:system_r:syslogd_t:s0 Target Objects Unknown [ cap_userns ] Source systemd-journal Source Path /usr/lib/systemd/systemd-journald Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-191.14.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.7.2-201.fc24.x86_64 #1 SMP Fri Aug 26 15:58:40 UTC 2016 x86_64 x86_64 Alert Count 107 First Seen 2016-09-05 14:23:57 CEST Last Seen 2016-09-08 10:27:08 CEST Local ID c6f099ef-bbdd-49ae-91b3-a8b1af7044f7 Raw Audit Messages type=AVC msg=audit(1473323228.146:269): avc: denied { sys_ptrace } for pid=754 comm="systemd-journal" capability=19 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=cap_userns permissive=0 Hash: systemd-journal,syslogd_t,syslogd_t,cap_userns,sys_ptrace Version-Release number of selected component: selinux-policy-3.13.1-191.14.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.2-201.fc24.x86_64 type: libreport
Description of problem: boot & start firefox Version-Release number of selected component: selinux-policy-3.13.1-191.14.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.3-200.fc24.x86_64 type: libreport
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Description of problem: May be started gedit following installing it from a flatpak? Version-Release number of selected component: selinux-policy-3.13.1-191.16.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.7.4-200.fc24.x86_64 type: libreport
*** Bug 1385577 has been marked as a duplicate of this bug. ***
Description of problem: Launch Pitivi from official flatpak when executing by double-click on pitivi-flatpak file and pressing "Execute". See http://wiki.pitivi.org/wiki/Install_with_flatpak on how to get that file and how to install Pitivi by flatpak. Version-Release number of selected component: selinux-policy-3.13.1-191.19.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.8.4-200.fc24.x86_64 type: libreport
Did anything actually break. I have a feeling this can be dontaudited.
No, it worked fine.
Lukas lets add a dontaudit. Almost no one ever needs SYS_PTRACE.
I just hit this on F24 but not sure what I was doing at the time that might have triggered it :( 4.8.8-200.fc24.x86_64 Let's know if you need more info. If I hit it again or I discover useful info I'll update here. thanks
(In reply to Daniel Walsh from comment #6) > Did anything actually break. I have a feeling this can be dontaudited. Not that I have noticed. The AVC denial seems to happen just once on boot. Source RPM Packages systemd-231-10.fc25.x86_64 Policy RPM selinux-policy-3.13.1-224.fc25.noarch According to /usr/lib/systemd/system/systemd-journald.service CapabilityBoundingSet includes CAP_SYS_PTRACE, looks like it's been that way since 2012 https://github.com/systemd/systemd/commi/ccd07a083e8040a5bb091c5036ab1b4493ff8363 Maybe I just don't know how to search but I don't see a call to ptrace() in the source code, I don't know what exactly CAP_SYS_PTRACE protects. Is it choking on allowing the capability to be granted at all, when the process starts, and not on any specific invocation of the ptrace() system call?
I think it allows a process to look at other processes owned by a different UID memory. There are fields in /proc, that tell where a processes memory address (Stack) starts, and you need SYS_PTRACE to look at these fields. Problem is commands like ps can easily trigger this capability, even though the program executing the ps command has no interest in looking at these fields.
selinux-policy-3.13.1-191.23.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-90bd4d7d33
selinux-policy-3.13.1-191.23.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-90bd4d7d33
selinux-policy-3.13.1-191.23.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.