Description of problem: We have seen, sometimes, during CKI xfstests [1] that we hit this avc denial. 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-34.13-1.fc34.noarch ---- time->Thu Jul 15 03:11:12 2021 type=AVC msg=audit(1626333072.035:851): avc: denied { write } for pid=570867 comm="systemd-coredum" name="core_pattern" dev="proc" ino=527591 scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:object_r:usermodehelper_t:s0 tclass=file permissive=1 Version-Release number of selected component (if applicable): selinux-policy-34.13-1.fc34 How reproducible: Not frequent Steps to Reproduce: 1. Run test [1] Additional info: [1] https://gitlab.com/cki-project/kernel-tests/-/tree/main/filesystems/xfs/xfstests
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/804
Switching the component. As discussed with David, this may turn out to be an unimportant bug in systemd code or a leaked file descriptor, systemd-coredump is only expected to read core_pattern.
I recall seeing an AVC like this in the past and I suspect this might actually be a kernel bug... AFAICT, it is the kernel itself that reads this file, but it does so (perhaps mistakenly?) with permission checking against the calling process. Unfortunately, I've never had time to look at this in more detail :/
systemd-coredump will write "|/bin/false" as core_pattern to disable coredumps when the crashing process is PID 1. It would be interesting to see if this was the condition here.
Bruno, I was unable to reproduce the problem in current F35 even after multiple tests runs. Could you do it again, possibly with full auditing enabled, and also try to pair the audit records with journal? How to enable full auditing in the audit daemon: 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
I've retried to run the same tests on Fedora-35, but so far no luck to reproduce the issue.
I've submitted a new Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/999
FEDORA-2022-f060667f1e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f060667f1e
FEDORA-2022-f060667f1e 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-2022-f060667f1e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f060667f1e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-35e911cda6 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-2022-35e911cda6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-35e911cda6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-35e911cda6 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.