Bug 1952163

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.