Description of problem: Happens every now and then when I run fedora-review. I am not sure if there is something about the packages being reviewed that triggers this. SELinux is preventing systemd-coredum from 'getattr' accesses on the file file. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-coredum should be allowed getattr access on the file file 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:object_r:nsfs_t:s0 Target Objects file [ file ] Source systemd-coredum Source Path systemd-coredum Port <Tuntematon> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-34.3-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.3-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.11.13-300.fc34.x86_64 #1 SMP Sun Apr 11 15:07:42 UTC 2021 x86_64 x86_64 Alert Count 1 First Seen 2021-04-21 19:00:08 EEST Last Seen 2021-04-21 19:00:08 EEST Local ID 56f7a3d0-e814-473f-a794-bd5664b4dea0 Raw Audit Messages type=AVC msg=audit(1619020808.530:2776): avc: denied { getattr } for pid=28586 comm="systemd-coredum" path="mnt:[4026533545]" dev="nsfs" ino=4026533545 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:nsfs_t:s0 tclass=file permissive=0 Hash: systemd-coredum,systemd_coredump_t,nsfs_t,file,getattr Version-Release number of selected component: selinux-policy-targeted-34.3-1.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.11.13-300.fc34.x86_64 type: libreport
Otto, Are there any additional entries in the system journal? Also, can you put the system into SELinux permissive mode to gather all denials? # setenforce 0 <reproduce> # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent
Created attachment 1774592 [details] libuev.spec
Created attachment 1774593 [details] libuev-2.3.2-1.fc34.src.rpm
Created attachment 1774594 [details] journalctl output
I found a reliable way to reproduce this: 1. Copy the attached files libuev.spec and libuev-2.3.2-1.fc34.src.rpm to an empty directory 2. In that directory, run 'fedora-review -n libuev' 3. After some time, the SELinux denial happens Result from ausearch as requested contains only the original audit message: type=AVC msg=audit(22.04.2021 20:59:24.533:3003) : avc: denied { getattr } for pid=34583 comm=systemd-coredum path=mnt:[4026533053] dev="nsfs" ino=4026533053 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:nsfs_t:s0 tclass=file permissive=1 Attaching output of journalctl starting at launch of fedora-review. These lines seem relevant and appear exactly at the moment of the denial (some unimportant seeming lines removed): huhti 22 20:59:24 ottovain audit[34582]: ANOM_ABEND auid=4294967295 uid=1000 gid=135 ses=4294967295 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=34582 comm="lt-signal" exe="/builddir/build/BUILD/libuev-2.3.2/tests/.libs/lt-signal" sig=11 res=1 huhti 22 20:59:24 ottovain kernel: lt-signal[34582]: segfault at 8 ip 0000558a1da95566 sp 00007ffe7d205e80 error 6 in lt-signal[558a1da95000+1000] huhti 22 20:59:24 ottovain kernel: Code: c0 48 c7 44 24 10 00 00 00 00 e8 55 fc ff ff 48 8b 54 24 10 48 8d 44 24 10 c7 03 a3 1c 00 00 48 89 43 08 48 8d 3d cf 0a 00 00 <48> 89 42 08 e8 d1 fb ff ff bf 2a 00 00 00 c7 44 24 0c 2a 00 00 00 huhti 22 20:59:24 ottovain audit[34583]: AVC avc: denied { getattr } for pid=34583 comm="systemd-coredum" path="mnt:[4026533053]" dev="nsfs" ino=4026533053 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:nsfs_t:s0 tclass=file permissive=1 huhti 22 20:59:24 ottovain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-34583-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' huhti 22 20:59:24 ottovain systemd[1]: Started Process Core Dump (PID 34583/UID 0). huhti 22 20:59:24 ottovain systemd-coredump[34584]: Resource limits disable core dumping for process 34582 (lt-signal). huhti 22 20:59:24 ottovain systemd-coredump[34584]: Process 34582 (lt-signal) of user 1000 dumped core. huhti 22 20:59:24 ottovain systemd[1]: systemd-coredump: Deactivated successfully. huhti 22 20:59:24 ottovain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-34583-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' huhti 22 20:59:24 ottovain abrt-dump-journal-core[865]: Failed to obtain all required information from journald huhti 22 20:59:24 ottovain abrt-dump-journal-core[865]: Failed to save detect problem data in abrt database huhti 22 20:59:27 ottovain systemd[1]: machine-083e52e414a5441d80b7d1562f27cdf5.scope: Deactivated successfully. The 'lt-signal' that crashes is part of the libuev testsuite and it seems that it is intended to crash as part of the test: https://github.com/troglobit/libuev/blob/bfd8454a922c11142c4fce9764f0bdba714a7a81/tests/signal.c#L59 I also tried compiling and running libuev tests locally, without going through specfile, srpm or fedora-review. signal-lt crashes, yes, but there is no SELinux denial. So it seems it is important that fedora-review is used. It calls mock, which uses chroot I believe.
Otto, Thank you for the reproducer. I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/700
FEDORA-2021-8d26207af7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d26207af7
FEDORA-2021-8d26207af7 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8d26207af7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8d26207af7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 1954966 has been marked as a duplicate of this bug. ***
FEDORA-2021-8d26207af7 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.