After updating sys-kernel/gentoo-kernel-bin from 6.6.79 to 6.12.16 boot with dracut fails on this AVC: audit: type=1400 audit(1741018360.768:3): avc: denied { entrypoint } for pid=1088 comm="dracut-pre-pivo" path="/usr/bin/umount" dev="rootfs" ino=3444 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 adding this to the policy: allow kernel_t root_t:file entrypoint; booting in enforcing mode works again
It may be related to https://github.com/dracutdevs/dracut/pull/2652 But at least dracut 106 still has ~ # lsinitrd |grep policy -rwxr-xr-x 1 root root 2287 Feb 1 02:20 var/lib/dracut/hooks/pre-pivot/50-selinux-loadpolicy.sh ~ # and does not work as well
It is probably worth noting that both systemd and openrc support loading SELinux fine - I see little reason to use the loadpolicy module with dracut at all - SELinux is not particularly useful in an initramfs as it cannot store xattrs. I think we are better offer pivoting away from the loadpolicy module for systems compatible with loading the policy without the initramfs, because little annoyances like this pop up, and the initial SID context has to become more and more privileged, which while not a huge deal, is not ideal either.
Also worth noting Gentoo's new dracut upstream is dracut-ng, relevant pr is here: https://github.com/dracut-ng/dracut-ng/pull/376
Thanks for the input. Indeed I can make the system boot by disabling the selinux dracut module. So *maybe* this bug is bogus. Not sure yet because when using sshd in dracut for example SELinux might be useful to protect network stuff. But maybe the policy is not at all required for some things.
> Thanks for the input. Anytime :) > So *maybe* this bug is bogus. I would say this bug is not bogus, i.e. there are issues with PID1's that are not capable of loading the SELinux policy and getting themselves into the right context. However, the relevant init systems to gentoo (and also the only ones supported by upstream refpolicy) systemd and openrc both have the ability to, and as those are the only PID1s officially supported for SELinux on Gentoo, I think the correct resolution to this bug would be disable that module by default in gentoo packaging. Non-default paths aren't really a concern for not being bootable by default as writing a policy for an init system is a lot more work than one or two denials in an initrd ;). Let me know your thoughts, I'll send a patch over to ::gentoo next week.
Adding to this, openrc-init's selinux support was added in https://github.com/OpenRC/openrc/commit/ee3c4afdb75b98cd472b7ffbb46adc9d8a1e1b15, sysvinit's selinux support was added around 15 years ago https://github.com/slicer69/sysvinit/blob/main/src/init.c#L3218-L3234 and systemd's was added 15 years ago here https://github.com/systemd/systemd/commit/c4dcdb9f4785937f2b73700e66b8cafa452f60a7, so all supported init systems are definitely ready to load SELinux for all supported versions in tree.
The dracut selinux module is disabled by default. I had it explicitly enabled and after commenting that line in dracut confiug I was able to boot again.
(In reply to Marc Schiffbauer from comment #7) > The dracut selinux module is disabled by default. I had it explicitly > enabled and after commenting that line in dracut config I was able to boot > again. Ah okay. In that case, IMO this is a documentation bug. I'll amend the documentation to explicitly mention why the dracut selinux module shouldn't be used as well.
