Description of problem: SELinux is preventing /usr/lib/systemd/systemd-journald from 'kill' accesses on the cap_userns labeled syslogd_t. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-journald should be allowed kill access on cap_userns labeled syslogd_t 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: # 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 systemd-241-8.git9ef65cb.fc30.x86_64 Target RPM Packages Policy RPM selinux-policy-3.14.3-35.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.0.16-300.fc30.x86_64 #1 SMP Tue May 14 19:33:09 UTC 2019 x86_64 x86_64 Alert Count 5325 First Seen 2019-04-24 20:55:14 EDT Last Seen 2019-05-16 22:05:21 EDT Local ID ad5f9279-048b-489e-a46f-af580090907b Raw Audit Messages type=AVC msg=audit(1558058721.42:530): avc: denied { kill } for pid=991 comm="systemd-journal" capability=5 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=cap_userns permissive=0 type=SYSCALL msg=audit(1558058721.42:530): arch=x86_64 syscall=kill success=no exit=EPERM a0=10bc a1=0 a2=ffffffff a3=12c3a2 items=0 ppid=1 pid=991 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) Hash: systemd-journal,syslogd_t,syslogd_t,cap_userns,kill Version-Release number of selected component: selinux-policy-3.14.3-35.fc30.noarch Additional info: component: selinux-policy reporter: libreport-2.10.0 hashmarkername: setroubleshoot kernel: 5.0.16-300.fc30.x86_64 type: libreport
This seems to be caused by firejail, and occurs on every sandbox start. I've reported it there: https://github.com/netblue30/firejail/issues/2702 But I'm not sure *why* it happens, I know it didn't happen with F29. It doesn't seem to be a regression on firejail's side either.
Tad, You only see this SELinux denial or some functionality is broken with syslogd? Thanks, Lukas.
I have not seen any broken functionality. There are no relevant errors in the logs. I haven't changed any defaults for journald or syslogd. I thought I narrowed it down to firejail (built from master), but it seems to also happen when Evolution or Liferea use/start webkit2gtk3. To be clear running Liferea loading an RSS feed that 404's without using firejail will cause the denial. From what I can tell this happens anytime something uses namespaces. So firejail, webkit2gtk, qtwebengine, etc. It must be a regression in either systemd from 239 to 241 or a change in Fedora's selinux-policy. I can reproduce it on multiple systems. 5000+ denials on one machine, 3000+ on another, and 300+ on some others. It happens every few seconds to every few minutes.
THanks, it looks like good candidate to dontaudit. commit d429ac797ecae49117cd8be4564dd73793d2baf3 (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Fri May 17 23:41:17 2019 +0200 Dontaudit syslogd_t using kill in unamespaces BZ(1711122)
selinux-policy-3.14.3-37.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-40c077f70d
selinux-policy-3.14.3-37.fc30 has been pushed to the Fedora 30 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-2019-40c077f70d
selinux-policy-3.14.3-37.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
We are seeing this show up again in a system running RHEL 8.10. Perhaps there was a regression?