This is a kernel issue.

Reopening... the fact that kdump runs with selinux disabled is what prompts the reboot. The referenced bug is a bug in relabel code that is then run.

So I don't see anything explicit in the kdump initrd contents that would be disabling selinux. However, when comparing the normal kernel's initrd vs. the kdump initrd, it appears that in the dracut world, the selinux policy actually gets loaded in the initrd, via pre-pivot/50selinux-loadpolicy.sh (which actually contains comments about how it really ought to be done after switchroot)... Given that the policy is being loaded by the dracut initrd, my supposition is that the kdump kernel must also do similar now, or we wind up w/o any selinux policy loaded, and are effectively running with it disabled when booting the kdump kernel and dumping it to the local file system. As a result, when we boot back into the normal kernel and reload our selinux policy, we get the relabel.

Dan, does this sound correct to you? If so, I guess this is a kexec-tools bug, in that mkdumprd now needs to grow support for loading our selinux policy for us.

Does k

OOPs,

Are you saying the kdump kernel executes the dracut call but SELinux is still disabled?  

SELinux gets enabled if the selinuxfs file system is present in the /proc/filesystems file and policy gets loaded by dracut.

Are you sure selinux is built in the kdump kernel?

You are correct, policy is loaded by dracut magic in the normal case.  We must either duplicate that in the kdump kernel/initrd or live with the relabel.  If the kdump kernel/initrd does not loading policy then the relabel is appropriate as files created during that boot will not have any labels!

(In reply to comment #8)
> OOPs,
> 
> Are you saying the kdump kernel executes the dracut call but SELinux is still
> disabled?  

No, the kdump kernel's initrd does NOT make the call to load the selinux policy like the normal kernel's initrd does.

> SELinux gets enabled if the selinuxfs file system is present in the
> /proc/filesystems file and policy gets loaded by dracut.
> 
> Are you sure selinux is built in the kdump kernel?    

It is, but the core problem appears to be the kdump kernel's initrd never loading any selinux policy. So, what Eric said. We need to either add the wiring to the kdump initrd to load our selinux policy, or live with the relabel.

Loading policy should not take up much memory.

Yeah, I don't think that it would be a problem, this is just an artifact of the kdump kernel having its own initrd generation tool that didn't evolve in lock-step with the switch from mkinitrd to dracut, specifically, the part where selinux policy loading moved into the initrd. At least, I presume selinux policy loading was done after we were done w/the initrd in the old mkinitrd world.

Now we just need someone to do the work necessary for mkdumprd to add policy loading. I was on the hook for triage, not sure if I'll also be doing implementation work.

Ew. Sounds like this was actually discussed a bit today, and those more in the know than I am about how to actually implement this have indicated its not particularly straight-forward to do what we need to do...

I am not familiar with selinux at all, does adding 'semodule -B' into kdump initrd help?

No,

load_policy is the command, but you need to look at what 

/usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh

Does.

Created attachment 426328 [details]
patch to load selinux policy

ok, heres a patch to handle this.  We were lucky, as it happens we can safely load policy from the rootfs without requiring a relabel (confirmed this with eparis).  This patch works for me, but if you could try it chris and confirm for me, that would be great.  Thanks!

OK, I tested this patch out.  First, it applied with a bit of fuzz:

[root@dhcp-100-18-122 ~]# cd /sbin
[root@dhcp-100-18-122 sbin]# patch -p0 < /root/mkdumprd.patch 
patching file mkdumprd
Hunk #1 succeeded at 1368 (offset -59 lines).
Hunk #2 succeeded at 2227 (offset -70 lines).
Hunk #3 succeeded at 2320 (offset -70 lines).

(but that may be because I'm running kexec-tools-2.0.0-69.el6.x86_64)

After applying the patch, I did:

[root@dhcp-100-18-122 ~]# rm -f /boot/initrd-2.6.32-28.el6.x86_64kdump.img
[root@dhcp-100-18-122 ~]# service kdump restart
Stopping kdump:[  OK  ]
No kdump initial ramdisk found.[WARNING]
Rebuilding /boot/initrd-2.6.32-28.el6.x86_64kdump.img
Starting kdump:[  OK  ]
[root@dhcp-100-18-122 ~]# 

After this I performed a crash, and in the second kernel I saw:

Loading SELINUX policy
type=1404 audit(1277330173.610:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
SELinux: 2048 avtab hash slots, 196553 rules.
SELinux: 2048 avtab hash slots, 196553 rules.
SELinux:  9 users, 13 roles, 3245 types, 157 bools, 1 sens, 1024 cats
SELinux:  77 classes, 196553 rules
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.
(plus some more SELinux rules loading)

After this the core was taken and the guest rebooted.  On the subsequent reboot no relabel was required, so it looks like this fixes the issue!

Thanks,
Chris Lalancette

I don't think you should be checking /etc/selinux/config at all.

You want to execute load_policy even if SELinux is disabled in /etc/selinux/config.  Because it will remove selinux from the kernel.

If you see that SELinux is disabled in /etc/selinux/config and do not run load_policy, you will be running with SELinux configured in the kernel although no policy loaded.  Which is different then what the normal kernel would do.

Not sure what you're talking about dan, the patch that I wound up including in comment 16 doesn't touch /etc/selinux/config at all.

Your right.  I misread it.  Sorry about that.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.