Description of problem: * the fapolicyd service seems to work OK, but 1 SELinux denial appears during each reboot * not sure why should the fapolicyd process write to /var/lib/rpm Version-Release number of selected component (if applicable): fapolicyd-1.0-4.fc33.x86_64 fapolicyd-selinux-1.0-4.fc33.noarch selinux-policy-3.14.6-25.fc33.noarch selinux-policy-devel-3.14.6-25.fc33.noarch selinux-policy-targeted-3.14.6-25.fc33.noarch How reproducible: * always during reboot Steps to Reproduce: 1. get a Fedora 33 machine (targeted policy is active) 2. start the fapolicyd service and enable it via systemctl 3. reboot 4. search for SELinux denials after the machine boots up Actual results: ---- type=AVC msg=audit(09/07/2020 12:26:45.839:107) : avc: denied { write } for pid=575 comm=fapolicyd name=rpm dev="vda2" ino=262154 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=0 ---- # find /var/ -inum 262154 /var/lib/rpm # Expected results: * no SELinux denials
Candidate for dontaudit-ing?
The same issue is reproducible on Fedora 32: ---- type=PROCTITLE msg=audit(09/17/2020 15:55:16.496:99) : proctitle=/usr/sbin/fapolicyd type=PATH msg=audit(09/17/2020 15:55:16.496:99) : item=0 name=/var/lib/rpm/.dbenv.lock inode=16797795 dev=fc:02 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=SYSCALL msg=audit(09/17/2020 15:55:16.496:99) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x5603cea83530 a2=O_RDWR|O_CREAT a3=0x1a4 items=1 ppid=1 pid=667 auid=unset uid=fapolicyd gid=fapolicyd euid=fapolicyd suid=fapolicyd fsuid=fapolicyd egid=fapolicyd sgid=fapolicyd fsgid=fapolicyd tty=(none) ses=unset comm=fapolicyd exe=/usr/sbin/fapolicyd subj=system_u:system_r:fapolicyd_t:s0 key=(null) type=AVC msg=audit(09/17/2020 15:55:16.496:99) : avc: denied { write } for pid=667 comm=fapolicyd name=rpm dev="vda2" ino=16797794 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=0 ----
Following SELinux denials appeared after switching the fapolicyd_t domain to permissive mode and rebooting the machine: ---- type=PROCTITLE msg=audit(09/17/2020 16:14:55.626:103) : proctitle=/usr/sbin/fapolicyd type=PATH msg=audit(09/17/2020 16:14:55.626:103) : item=0 name=/var/lib/rpm/.dbenv.lock inode=16797795 dev=fc:02 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:rpm_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=SYSCALL msg=audit(09/17/2020 16:14:55.626:103) : arch=x86_64 syscall=openat success=yes exit=9 a0=0xffffff9c a1=0x556722afd530 a2=O_RDWR|O_CREAT a3=0x1a4 items=1 ppid=1 pid=669 auid=unset uid=fapolicyd gid=fapolicyd euid=fapolicyd suid=fapolicyd fsuid=fapolicyd egid=fapolicyd sgid=fapolicyd fsgid=fapolicyd tty=(none) ses=unset comm=fapolicyd exe=/usr/sbin/fapolicyd subj=system_u:system_r:fapolicyd_t:s0 key=(null) type=AVC msg=audit(09/17/2020 16:14:55.626:103) : avc: denied { create } for pid=669 comm=fapolicyd name=.dbenv.lock scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file permissive=1 type=AVC msg=audit(09/17/2020 16:14:55.626:103) : avc: denied { add_name } for pid=669 comm=fapolicyd name=.dbenv.lock scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=1 type=AVC msg=audit(09/17/2020 16:14:55.626:103) : avc: denied { write } for pid=669 comm=fapolicyd name=rpm dev="vda2" ino=16797794 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir permissive=1 ----
Test coverage for this bug exists in a form of PR: * https://src.fedoraproject.org/tests/selinux/pull-request/122 This PR waits for review.
FEDORA-2020-580dc8d3ba has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-e2dc088972 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e2dc088972
FEDORA-2020-165e765d4e has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-daefd8b8f6 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-daefd8b8f6
FEDORA-2020-6323ce5fcf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6323ce5fcf
FEDORA-2020-e2dc088972 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e2dc088972` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e2dc088972 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-daefd8b8f6 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-daefd8b8f6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-daefd8b8f6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6323ce5fcf has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6323ce5fcf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6323ce5fcf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-daefd8b8f6 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-e2dc088972 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.