Re: [gentoo-hardened] locked out of selinux

[Mike Edenfield]

Markus Bartl wrote:

> Sep 29 20:20:22 odin type=1400 audit(1222712401.300:3): avc:  denied  {
> read write } for  pid=1 comm="init" path="/dev/console" dev=sda3
> ino=1485226 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t tclass=chr_file
> Sep 29 20:20:22 odin type=1400 audit(1222712401.304:4): avc:  denied  {
> ioctl } for  pid=1 comm="init" path="/dev/tty0" dev=sda3 ino=1485112
> scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t
> tclass=chr_file
> Sep 29 20:20:22 odin type=1400 audit(1222712401.316:5): avc:  denied  {
> read write } for  pid=1081 comm="rc" name="console" dev=sda3 ino=1485226
> scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:file_t
> tclass=chr_file
> Sep 29 20:20:22 odin type=1400 audit(1222712401.364:6): avc:  denied  {
> read write } for  pid=1083 comm="consoletype" name="console" dev=sda3
> ino=1485226 scontext=system_u:system_r:consoletype_t
> tcontext=system_u:object_r:file_t tclass=chr_file
> Sep 29 20:20:22 odin type=1400 audit(1222712401.364:7): avc:  denied  {
> getattr } for  pid=1083 comm="consoletype" path="/dev/console" dev=sda3
> ino=1485226 scontext=system_u:system_r:consoletype_t
> tcontext=system_u:object_r:file_t tclass=chr_file

These are actually pretty harmless -- it just means your static /dev 
isn't labeled correctly.  This is because the stage3 tarballs don't have 
any SELinux information in them, so when you unpack it the /dev files 
are there with no labels, but by the time you get SELinux working enough 
to relabel your filesystems, udev has taken over /dev.

If you want to get rid of these AVC's from your dmesg, you just need to 
relabel the static dev entries.  It's a bit tricky but you only need to 
do it once:

# mkdir -p /mnt/realroot
# mount -o bind / /mnt/realroot
# setfiles -r /mnt/realroot \
   /etc/selinux/strict/contexts/files/file_contexts \
   /mnt/realroot/dev
# umount /mnt/realroot

*However*, I don't this this is really the cause of your problems. 
Gentoo's boot process is capable of continuing without access to 
/dev/console (though /dev/null may give it problems), and very early on 
udev mounted and everything fixes itself.

Have you manually unmasked any packages related to booting?  In 
particular, openrc/baselayout2 won't work with the SELinux userland from 
portage, and have given me similar boot failures.

Also, can you be more precise about what failed on boot?  How far does 
your boot process get? Do you get any of the normal Gentoo boot messages 
(the colorized ones)?

--Mike