Hi, the following selinux denial is shown in rawhide (in several occasions - in CI test during testing, or in the VM during upgrade): Oct 12 16:13:53 fedora systemd[1]: Starting man-db-cache-update.service... Oct 12 16:13:54 fedora systemd[1]: Reloading. Oct 12 16:13:54 fedora audit[17072]: AVC avc: denied { write } for pid=17072 comm="systemd-gpt-aut" name="vda" dev="devtmpfs" ino=281 scontext=system_u:system_r:systemd_gpt_generator_t:s0 tcontext=system_u:object_r:fixed_disk_device_t> Oct 12 16:13:54 fedora systemd[17057]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1. I'm not sure whether the binary is supposed to write to the device, I'll CC systemd maintainers. Versions: systemd-252~rc1-608.fc38.x86_64 selinux-policy-37.13-1.fc38.noarch
Honza, would you or someone else from systemd team reviewing the denial whether it is an expected behavior?
*** Bug 2134272 has been marked as a duplicate of this bug. ***
This AVC denial is caused by recent changes in systemd-gpt-auto-generator, https://github.com/systemd/systemd/commit/55a065cd30f303578ce5f8a36bd859763c99ba51 and https://github.com/systemd/systemd/commit/de3b7f168e13cffe6067d5a7b6df4f301c9b05b9 . Here is offending stack trace, systemd-gpt-aut 4739 [000] 13319.264233: avc:selinux_audited: [UNKNOWN EVENT] ffffffffa36cdf97 avc_audit_post_callback+0x207 ([kernel.kallsyms]) ffffffffa36cdf97 avc_audit_post_callback+0x207 ([kernel.kallsyms]) ffffffffa36f6cda common_lsm_audit+0x15a ([kernel.kallsyms]) ffffffffa36cedde slow_avc_audit+0x9e ([kernel.kallsyms]) ffffffffa36d1f65 audit_inode_permission+0x85 ([kernel.kallsyms]) ffffffffa36d694b selinux_inode_permission+0x18b ([kernel.kallsyms]) ffffffffa36ca0f7 security_inode_permission+0x37 ([kernel.kallsyms]) ffffffffa34583cf may_open+0x6f ([kernel.kallsyms]) ffffffffa345cfb0 path_openat+0x6a0 ([kernel.kallsyms]) ffffffffa345e53e do_filp_open+0x9e ([kernel.kallsyms]) ffffffffa3445896 do_sys_openat2+0x96 ([kernel.kallsyms]) ffffffffa3445c6c __x64_sys_openat+0x5c ([kernel.kallsyms]) ffffffffa3f65168 do_syscall_64+0x58 ([kernel.kallsyms]) ffffffffa400009b entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms]) f9215 __libc_open64+0x55 (inlined) 196b98 fd_reopen+0xa8 (/usr/lib64/systemd/libsystemd-shared-252-rc1-610.fc38.so) 12b589 [unknown] (/usr/lib64/systemd/libsystemd-shared-252-rc1-610.fc38.so) 12bb3c loop_device_open+0xcc (/usr/lib64/systemd/libsystemd-shared-252-rc1-610.fc38.so) 12d6a3 loop_device_open_from_path+0x53 (/usr/lib64/systemd/libsystemd-shared-252-rc1-610.fc38.so) 30dd [unknown] (/usr/lib/systemd/system-generators/systemd-gpt-auto-generator) 23a0f __libc_start_call_main+0x7f (/usr/lib64/libc.so.6) 23ac8 __libc_start_main_alias_2+0x88 (inlined) 3d24 [unknown] (/usr/lib/systemd/system-generators/systemd-gpt-auto-generator) The problem is that previously we just took the lock on the device node fd, but now we call loop_device_open_from_path() which in turn tries reopen the device node fd (using /proc/self/fd/FD path) in read-write mode in order to use it for flock() and this is be triggering the AVC denial. These changes on systemd side were intentional hence I think it should be OK to allow this in the policy.
FEDORA-2022-f7fdf02056 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7fdf02056
FEDORA-2022-f7fdf02056 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-f7fdf02056` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f7fdf02056 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-f7fdf02056 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.