dracutdevs
Dracut generated initramfs fails to boot with recent kernels due to SELinux Permission Denied errors
Describe the bug Dracut generated initramfs fails to boot with recent kernels due to SELinux Permission Denied errors
Dracut version Dracut 044
Init system sysvinit
To Reproduce Update the kernel to 6.9.1. Generate a new initramfs using dract. Reboot the system.
Expected behavior The boot process should complete instead of getting stuck (with kernel panic) due to SELinux permission denied errors
Additional context A new pull request https://github.com/dracutdevs/dracut/pull/2652 has been created to fix the issue, however it has not been tested with systemd or other init daemons other than sysvinit
The problem is caused by a SELinux kernel change which was introduced in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae254858ce0745aba25d107159b580ab5fdada5b and it can be fixed in three ways (with different security impact):
- by fixing kernel commit ae254858ce0745aba25d107159b580ab5fdada5b which led to the need for the additional kernel domain "root_t:file entrypoint" SELinux permission upon booting (mounting) the system - this has no security impact at all, see the patch proposed in https://github.com/dracutdevs/dracut/issues/2653#issuecomment-2906824832;
- fixing dracut by loading the SELinux policy after switch_root and removing the dracut selinux module (this has a small security impact in the first part of the boot process until switch_root and it was apparently already scheduled by a FIXME comment in the dracut selinux module) - see https://github.com/dracutdevs/dracut/pull/2652 and https://github.com/dracut-ng/dracut-ng/pull/376;
- changing the SELinux policy in order to grant the kernel domain additional permission root_t:file entrypoint (this has the highest security impact in that such permission is always granted and not only during the initial boot phase) - see https://github.com/SELinuxProject/refpolicy/pull/911.
As explained in https://github.com/dracutdevs/dracut/issues/2653#issuecomment-2906768352 a kernel patch would be the preferred way of dealing with the issue in order to avoid a security impact.
A kernel patch is proposed for testing: https://lore.kernel.org/selinux/[email protected]/