Description of problem: SELinux is preventing systemd-coredum from 'sys_admin' accesses on the cap_userns labeled systemd_coredump_t. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-coredum should be allowed sys_admin access on cap_userns labeled systemd_coredump_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-coredum' --raw | audit2allow -M my-systemdcoredum # semodule -X 300 -i my-systemdcoredum.pp Additional Information: Source Context system_u:system_r:systemd_coredump_t:s0 Target Context system_u:system_r:systemd_coredump_t:s0 Target Objects Unknown [ cap_userns ] Source systemd-coredum Source Path systemd-coredum Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-35.6-1.fc36.noarch Local Policy RPM selinux-policy-targeted-35.6-1.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.16.0- 0.rc4.20211207gitcd8c917a56f2.30.fc36.x86_64 #1 SMP PREEMPT Tue Dec 7 18:35:28 UTC 2021 x86_64 x86_64 Alert Count 4 First Seen 2021-12-11 12:31:29 +05 Last Seen 2021-12-11 14:44:43 +05 Local ID 79891449-d02a-4cad-8457-959a90646c13 Raw Audit Messages type=AVC msg=audit(1639215883.828:346): avc: denied { sys_admin } for pid=35611 comm="systemd-coredum" capability=21 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=cap_userns permissive=0 Hash: systemd-coredum,systemd_coredump_t,systemd_coredump_t,cap_userns,sys_admin Version-Release number of selected component: selinux-policy-targeted-35.6-1.fc36.noarch Additional info: component: selinux-policy reporter: libreport-2.15.2 hashmarkername: setroubleshoot kernel: 5.16.0-0.rc4.20211207gitcd8c917a56f2.30.fc36.x86_64 type: libreport
More denials as reported using a different channel: SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 selinux-policy-35.6-1.fc36.noarch ---- time->Sat Dec 11 07:40:54 2021 type=AVC msg=audit(1639204854.117:978): avc: denied { sys_admin } for pid=322547 comm="systemd-coredum" capability=21 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=cap_userns permissive=1 ---- time->Sat Dec 11 07:40:54 2021 type=AVC msg=audit(1639204854.127:979): avc: denied { mounton } for pid=322548 comm="(sd-parse-elf)" path="/" dev="vda3" ino=256 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=1 ---- time->Sat Dec 11 07:40:54 2021 type=AVC msg=audit(1639204854.127:980): avc: denied { dac_read_search } for pid=322548 comm="(sd-parse-elf)" capability=2 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=cap_userns permissive=1 ---- time->Sat Dec 11 07:40:54 2021 type=AVC msg=audit(1639204854.127:981): avc: denied { dac_override } for pid=322548 comm="(sd-parse-elf)" capability=1 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=cap_userns permissive=1
systemd-coredump forks a child process to perform core file analysis (comm=(sd-parse-elf)), and before doing the actual analysis, it sets up some sandbox, using mount and user namespaces. So all this is expected and should be allowed. See https://github.com/systemd/systemd/commit/61aea456c1 for the upstream change.
Similar problem has been detected: Happens every time when crashed /usr/libexec/tracker-extract-3 process. hashmarkername: setroubleshoot kernel: 5.16.0-0.rc5.20211217git6441998e2e37.38.fc36.x86_64 package: selinux-policy-targeted-35.7-1.fc36.noarch reason: SELinux is preventing systemd-coredum from 'sys_admin' accesses on the cap_userns labeled systemd_coredump_t. type: libreport
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/999
*** Bug 2039983 has been marked as a duplicate of this bug. ***
*** Bug 2039985 has been marked as a duplicate of this bug. ***
*** Bug 2039986 has been marked as a duplicate of this bug. ***
FEDORA-2022-41fa7610dd has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-41fa7610dd
FEDORA-2022-41fa7610dd has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2043739 has been marked as a duplicate of this bug. ***