When booting a system with a new systemd an SELinux denial is logged audit: type=1400 audit(1686228244.891:4): avc: denied { audit_control } for pid=1 comm="systemd" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tcl ass=capability permissive=0 Reproducible: Always Steps to Reproduce: 1. Boot a machine with fedora-testing enabled This issue was caught as a new regression by Cockpit CI. Notable package updates where: systemd (253.4-1.fc38 -> 253.5-1.fc38) systemd-container (253.4-1.fc38 -> 253.5-1.fc38) systemd-libs (253.4-1.fc38 -> 253.5-1.fc38) systemd-networkd (253.4-1.fc38 -> 253.5-1.fc38) systemd-oomd-defaults (253.4-1.fc38 -> 253.5-1.fc38) systemd-pam (253.4-1.fc38 -> 253.5-1.fc38) systemd-resolved (253.4-1.fc38 -> 253.5-1.fc38) systemd-rpm-macros (253.4-1.fc38 -> 253.5-1.fc38) systemd-udev (253.4-1.fc38 -> 253.5-1.fc38) container-selinux (2:2.216.0-1.fc38 -> 2:2.218.0-1.fc38)
Found in the systemd journal: Jun 08 14:12:54 fedora kernel: audit: type=1400 audit(1686247974.521:4): avc: denied { audit_control } for pid=1 comm="systemd" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 Jun 08 14:04:59 fedora kernel: audit: type=1400 audit(1686247499.666:4): avc: denied { audit_control } for pid=1 comm="systemd" capability=30 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=capability permissive=0 Not present in the audit.log.
# rpm -qa systemd\* selinux-policy\* | sort selinux-policy-38.15-1.fc38.noarch selinux-policy-targeted-38.15-1.fc38.noarch systemd-253.5-1.fc38.x86_64 systemd-container-253.5-1.fc38.x86_64 systemd-libs-253.5-1.fc38.x86_64 systemd-networkd-253.5-1.fc38.x86_64 systemd-oomd-defaults-253.5-1.fc38.noarch systemd-pam-253.5-1.fc38.x86_64 systemd-resolved-253.5-1.fc38.x86_64 systemd-rpm-macros-253.5-1.fc38.noarch systemd-udev-253.5-1.fc38.x86_64 # The SELinux denial should not appear anymore after enabling the init_audit_control boolean: # sesearch -s init_t -c capability -p audit_control -A allow init_t init_t:capability audit_control; [ init_audit_control ]:True # getsebool -a | grep init_audit_control init_audit_control --> off #
I can confirm that new SELinux denials do not appear during reboot if the init_audit_control boolean is enabled: # setsebool -P init_audit_control on
Ondrej, Systemd probably wants nothing but find out if it is in the initial namespace: https://github.com/systemd/systemd-stable/commit/4be604e75a38cb0ddbde3f2ade6ae65664fe77be#diff-e026a4ebb58e7e8ce98d24f4046f809063ff019827d92d2f9a0a3dab97ee397eR130 https://github.com/torvalds/linux/blob/master/kernel/audit.c#L1035 Do you think there is more clever way to get that information?
Well, they could try to send AUDIT_LIST (or any deprecated/invalid message ID) instead of AUDIT_GET_FEATURE and it should work (they get either EOPNOTSUPP/EINVAL or ECONNREFUSED), though it may not be fully future-proof. I don't know if there is a better way to check specifically if the current process runs in the init userns.
Michale, This is probably just FYI, I am going to allow the permission in the policy.
FEDORA-2023-ba070ee6ba has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ba070ee6ba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.