Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 397567 - initramfs (dracut) fails to boot up a SELinux system in enforcing/strict mode
Summary: initramfs (dracut) fails to boot up a SELinux system in enforcing/strict mode
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: SE Linux Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-03 22:57 UTC by Sven Vermeulen (RETIRED)
Modified: 2013-04-11 16:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Vermeulen (RETIRED) gentoo-dev 2012-01-03 22:57:37 UTC
Right after switching SELinux on, the system stalls for several minutes, displaying denials such as:

denied { read write } for comm="init" path="/dev/console" dev=tmpfs scontext=init_t tcontext=tmpfs_t class=chr_file

denied { search }  for comm="init" name="/" dev=tmpfs scontext=init_t tcontext=tmpfs_t class=dir

This points to incorrect labels set to the device files.

grsec also shows segmentation fails in /sbin/rc:

grsec: Segmentation fault occurred at (nil) in /sbin/rc[rc:1552]

The error is shown 3 times after which grsec reports "more alerts, logging disabled for 10 seconds". After that (4639 callbacks suppressed), only denials on "/" { search } are displayed.

Exactly 5 minutes later (from boot-time 5.51 to 306.06) the search denials and segfaults are shown again. 

Reproducible: Always
Comment 1 Sven Vermeulen (RETIRED) gentoo-dev 2012-01-14 14:47:16 UTC
Booting with enforcing=0 and then later switching (setenforce 1) works fine. But SELinux kernels without this (development) support still fail.

Current issue seems to be that the /init in the initramfs runs in kernel_t but does too many things before it calls load_policy (which is needed to have knowledge about other domains than kernel_t) so labels are all wrong. But calling load_policy earlier might require that policy.26 is part of the initramfs as well (which is again an issue since the policy file is updated many times compared to the initramfs)

Current advise: if you need initramfs support, boot with enforcing=0 (so enable selinux development in the kernel) and then switch to enforcing afterwards (for instance in an initscript). 

Also, grsec users which configure chroot restrictions will need to /unset/ CONFIG_GRKERNSEC_SYSCTL_ON since an initramfs uses chroot extensively (and grsec would deny most of them). You can set them later (through sysctl.conf) and then lock (grsec_lock) the sysctls.
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2012-02-22 21:23:00 UTC
Need to check https://bugs.gentoo.org/attachment.cgi?id=302829 as well here (see if tar needs to be updated)
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2012-02-27 19:49:28 UTC
Use of "permissive" boot solution documented in hardened-docs overlay and on gentoo wiki (http://wiki.gentoo.org/wiki/Knowledge_Base:Booting_SELinux_with_an_initramfs)
Comment 4 Sven Vermeulen (RETIRED) gentoo-dev 2012-07-21 19:22:49 UTC
Seems recently initramfs systems might boot pretty far even without the enforcing=0 at the beginning. As long as the initramfs doesn't load the policy itself, it is pretty much running in unconfined (the initramfs is treated as a trusted resource) and when Gentoo's init is called, the policy is loaded.
Comment 5 Sven Vermeulen (RETIRED) gentoo-dev 2013-04-11 16:28:25 UTC
Marking this as fixed, I've been able to boot in enforcing mode immediately using genkernel, where the initramfs is responsible for the LVM (root is on lvm, and separate /usr as well).