Description of problem: Booting current rawhide leaves a system with non-functioning selinux. Selinux is not disabled in either /etc/grub.conf or /etc/selinux/config. Version-Release number of selected component (if applicable): dracut-001-9 How reproducible: every boot, every rawhide update Additional info: If selinux is not disabled specifically and cannot be loaded, the system must terminate.
please, retry with dracut-002
The scripts should execute load_policy and if for ANY reason load_policy fails and the machine is in enforcing mode the machine needs to crash. (It should also log the error). If the kernel has SELinux and it is not in permissive mode, it should execute load_policy Load_policy will exit with 0 on success or 2 on failure and SELinux in permissive mode. man load_policy ... EXIT STATUS 0 Success 1 Invalid option 2 Policy load failed 3 Initial policy load failed and enforcing mode requested Any other error code or load_policy being missing should cause the machine to crash.
With dracut 002, I now have something in dmesg: dracut: Loading SELinux policy dracut: SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.24: Invalid argument dracut: /sbin/load_policy: Can't load policy: Invalid argument So, this is helpful since there is now something better indicating the problem.
Rebooted again and saw this, which is not being recorded in dmesg: SELinux: permission module_request in class system not found in policy, bad policy
Have a look at this: http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=blob;f=modules.d/99base/selinux-loadpolicy.sh;hb=HEAD
Created attachment 361751 [details] This is closer, although I don't think it will work because /proc is not mounted Is there another way to know the contents of the kernel command line?
Dan fixed the policy bug. Selinux is now working again. The 002 changes to dracut now let us see what is happening in dracut. So, the original problem is solved. There could probably be a little fixing up to make things better, but this can be closed since the basic problem is now fixed. I found that auditing of policy_load is messed up too and will submit a patch separately. Thanks everyone.
(In reply to comment #6) > Created an attachment (id=361751) [details] > This is closer, although I don't think it will work because /proc is not > mounted > > Is there another way to know the contents of the kernel command line? As far as I read the code of load_policy, it mounts /proc and /selinux just fine. IIRC, you mentioned we should not rely on the presence of the /etc/sysconfig/selinux file and leave it all to load_policy..
Created attachment 361891 [details] suggested selinux-loadpolicy.sh load_policy does mount /proc and /selinux, so I would suggest this selinux-loadpolicy.sh version.. To test it, copy it to /usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh and recreate the image: # dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
Created attachment 361893 [details] small correction
You will exit 0 if load_policy does not exist, and the machine is in enforcing mode which is also wrong. You need to end with something to check exit !$permissive at the end.
warn "Machine in enforcing mode." warn "Not continuing" sleep 100d exit 1 exit 1 will exit the while init completly and lets the kernel panic after it slept 100 days
Created attachment 361937 [details] revised version exit if load_policy not available and enforcing mode
is the 100 days for real? Looks good to me. But that admin is going to wonder why the machine suddenly reboots after 101 days. :^)
The panic should come faster than that so that the machine is unusable.
Dan, are you happy with the current status? If so, I think we can close this bug report.
Yes, The only thing I would like to suggest is we bring the relabeling into this script. That way it could happen before /bin/init is run and we could guarantee everything to come up pristine.