After updating udev to udev-197 my system refuses to boot successfully in enforcing mode. The udev service fails according to the console output (the error implies that it fails to create a netlink socket). Because of the failure of udev several other services refuse to start (including syslog-ng - that causes the fact that I can't provide any logs about the failure in enforcing mode). Booting in permissive mode works and I'll attach a file with the denials that seem to cause the error. Additional fact: dmcrypt fails to start even in permissive mode with udev-197 - I'm not sure if that is caused by SELinux though. Reproducible: Always Steps to Reproduce: 1. Install udev-197 2. Reboot in enforcing mode 3. Look at console errors ;) Actual Results: System doesn't get to a login-prompt - neither console nor xdm. Several udev-dependent services fail... Expected Results: System boots to login prompt. I'm using the live policy (-9999 ebuilds)
Created attachment 335028 [details] Output of "grep udev <avc-related logs>
(In reply to comment #0) > Additional fact: dmcrypt fails to start even in permissive mode with > udev-197 - I'm not sure if that is caused by SELinux though. Please try solution provided in bug 451266
Seems like some file were moved again... # ls -lZ /lib/systemd/systemd-udevd -rwxr-xr-x. 1 root root staff_u:object_r:bin_t 203096 Jan 10 23:51 /lib/systemd/systemd-udevd in policy there is /usr/lib/systemd/systemd-udevd -- gen_context(system_u:object_r:udev_exec_t,s0) after # chcon -t udev_exec_t /lib/systemd/systemd-udevd it boots fine
You're right, Amade - that fixes it for me too. So it should suffice to adjust the file contexts in the policy.
selinux@ What do you want to do with this? Do you want me to temporarily mask 197 in the selinux profile? Do you have an diff for 197-r2, -r3 and 9999 we can apply to keep things working? Need to know pretty fast. Thanks!
Can we just add `use selinux && chcon -t udev_exec_t "${D}"/lib/systemd/systemd-udevd` to src_install?
it's in hardened-refpolicy, working with swift for stabilization of this specific fix. http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=commit;h=9b69c1fc94686ed3cc28e4bb1d1b7a0aa9045025
I can confirm that it's fixed in hardened-refpolicy now.
@Samuli: you can't do that in "${D}"/... as the file labels are applied after merging the files from the image/ onto the real file system (so it's more a postinst part).
Ok fix is in portage tree, ~arch for now (need to do a quick merge check). Only contains this one fix (well and a small typo elsewhere) so I can stabilize more quickly
Fix is now stabilized (selinux-base and selinux-base-policy packages are bumped to rev10 and stable in tree), successfully applied and booted (in enforcing mode) a stable system
