Linux – how to enable selinux in kernel

To quote a bit from the GRUB Manual which adds a bit of extra checking for katriel's answer.

You can teach GRUB to boot an entry only at next boot time. Suppose that your have an old kernel old_kernel and a new kernel new_kernel. You know that old_kernel can boot your system correctly, and you want to test new_kernel.

To ensure that your system will go back to the old kernel even if the new kernel fails (e.g. it panics), you can specify that GRUB should try the new kernel only once and boot the old kernel after that.

First, modify your configuration file. Here is an example:

 default saved        # This is important!!!
 timeout 10

 title the old kernel
 root (hd0,0)
 kernel /old_kernel
 savedefault

 title the new kernel
 root (hd0,0)
 kernel /new_kernel
 savedefault 0         # This is important!!!

Note that this configuration file uses default saved' (see default) at the head andsavedefault 0' (see savedefault) in the entry for the new kernel. This means that GRUB boots a saved entry by default, and booting the entry for the new kernel saves `0' as the saved entry.

With this configuration file, after all, GRUB always tries to boot the old kernel after it booted the new one, because `0' is the entry of the old kernel.

The next step is to tell GRUB to boot the new kernel at next boot time. For this, execute grub-set-default (see Invoking grub-set-default):

 # grub-set-default 1

This command sets the saved entry to `1', that is, to the new kernel.

This method is useful, but still not very robust, because GRUB stops booting, if there is any error in the boot entry, such that the new kernel has an invalid executable format. Thus, it it even better to use the fallback mechanism of GRUB. Look at next subsection for this feature.

If you're copying files from one filesystem to another, you can:

• If using cp, add the -c option to copy the SELinux context.
• If using tar, add the --selinux option to copy the SELinux context.

This may save you some time by ensuring that the destination files have the expected context, assuming that the contexts are correct to begin with.

As for fixfiles, it's a wrapper for restorecon, which is what I generally use. When /.autorelabel is present, the init script runs restorecon -p -r /, which prints the dots for six minutes, and then reboots afterward. I prefer -v for a verbose listing of the contexts which have changed, instead of -p. Either way, you should chroot into the filesystem before you run this.