Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 597229 - [RHEL6]: After kdump, SELinux relabel is required
Summary: [RHEL6]: After kdump, SELinux relabel is required
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Han Pingtian
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-28 13:12 UTC by Chris Lalancette
Modified: 2010-11-10 20:55 UTC (History)
6 users (show)

Fixed In Version: kexec-tools-2.0.0-88.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-10 20:55:17 UTC
Target Upstream Version:

Attachments (Terms of Use)
patch to load selinux policy (deleted)
2010-06-23 17:40 UTC, Neil Horman
no flags Details | Diff

Description Chris Lalancette 2010-05-28 13:12:43 UTC
Description of problem:
I have RHEL-6 running as a KVM guest on a RHEL-6 host.  I configured kdump inside the guest.  After doing an "echo c > /proc/sysrq-trigger", the kexec successfully completes, the dump is successfully performed, and the guest reboots.  However, on the subsequent reboot, I get:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.

That doesn't seem right to me; I shouldn't have to relabel my filesystem just because my kernel crashed.  It almost seems like the kdump kernel is booting with SELinux totally disabled, thus requiring the relabel.

The kdump kernel booted with a kernel command-line of:

ro root=/dev/mapper/vg_dhcp10018122-lv_root rd_LVM_LV=vg_dhcp10018122/lv_root rd_LVM_LV=vg_dhcp10018122/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us  apic=verbose console=tty0 console=ttyS0,115200 irqpoll maxcpus=1 reset_devices apic=verbose memmap=exactmap memmap=640K@0K memmap=130412K@33408K elfcorehdr=163820K

I'm starting the bug report against selinux-policy, though it could also be the kexec-tools that are at fault here.

Version-Release number of selected component (if applicable):

How reproducible:

Comment 2 Daniel Walsh 2010-05-28 13:27:55 UTC
This is a kernel issue.

Comment 5 Bill Nottingham 2010-06-07 21:57:54 UTC
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.

Comment 6 Jarod Wilson 2010-06-10 15:56:00 UTC
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/ (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.

Comment 7 Daniel Walsh 2010-06-16 15:26:32 UTC
Does k

Comment 8 Daniel Walsh 2010-06-16 15:28:09 UTC

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?

Comment 9 Eric Paris 2010-06-16 17:40:16 UTC
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!

Comment 10 Jarod Wilson 2010-06-16 18:15:28 UTC
(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.

Comment 11 Daniel Walsh 2010-06-16 19:07:30 UTC
Loading policy should not take up much memory.

Comment 12 Jarod Wilson 2010-06-16 19:16:03 UTC
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.

Comment 13 Jarod Wilson 2010-06-16 19:25:10 UTC
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...

Comment 14 Cong Wang 2010-06-17 05:47:07 UTC
I am not familiar with selinux at all, does adding 'semodule -B' into kdump initrd help?

Comment 15 Daniel Walsh 2010-06-17 13:09:57 UTC

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



Comment 16 Neil Horman 2010-06-23 17:40:29 UTC
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!

Comment 17 Chris Lalancette 2010-06-23 17:56:25 UTC
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!

Chris Lalancette

Comment 18 Daniel Walsh 2010-06-25 18:29:15 UTC
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.

Comment 19 Neil Horman 2010-06-25 19:07:37 UTC
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.

Comment 20 Daniel Walsh 2010-06-25 19:46:38 UTC
Your right.  I misread it.  Sorry about that.

Comment 22 2010-11-10 20:55:17 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.