selinux denials due to race conditions? [solved]

[vaxbrat]

I just joined the hardened-gentoo mailing list but thought I might give this a shot here too. I'm on the 2006.1 unstable profile for selinux and think I may have a race condition that results in avc denials before selinux has finished labeling things like /dev. For example, the first denial below appears to be where /etc/hotplug.d/default/default.hotplug is peeking and poking around with /dev/null. The denial has it as a system_u:object_r:file_t, but when I look at it from a running system I see it as a system_u:object_r:null_device_t. Can the hardened folk chime in about whether I'm missing something blatantly obvious? Should I be messing around in /etc/runlevels/boot to put dependencies in various scripts (although selinux isn't a script so how would I make it a dependency?)

snippet from a dmesg:

[vaxbrat]

Got confirmed that it is indeed a race condition. However I noticed that udev really has taken over everything from hotplug so that it's no longer needed. That got rid of a good number of denials since udev doesn't get around to doing its thing until later and thus avoids the race.

[vaxbrat]

Here's the detailed story for the race condition. Until udev has finished doing its thing and mounted its own /dev, the system is using the primordial static /dev from your root's filesystem. Selinux gets /selinux up and running and is still at work doing the genfs context labeling of /dev, /tmp and company when the init process gets kicked. So init initially gets busy using the static nodes. Unfortunately these all have the default labeling of file_t and don't get picked up later by relabeling since udev now overlays the /dev directory with its own.

In order to relabel the static /dev you need to get a bit sneaky by "remounting" your root filesystem somewhere else. Let's say /mnt/rawroot

[vaxbrat]

Can't seem to stay away from this thread for some reason

Here's a couple more things in the rawroot that need proper labeling:

[R. Bosch]

[vaxbrat]

This:

[R. Bosch]

Thought of that, but failed:

[vaxbrat]

So if you do

[R. Bosch]

Yes, but the thing is; I can't repeat this. I removed /selinux and ran mkdir /selinux to see if it would make any difference, but the system still refuses to set the context correctly.

[vaxbrat]

What role are you in when you try to label? Even in permissive mode, I wonder if context labeling wants you to be a sysadm_t before doing its thing.

It's interesting that the security_t type may only be on the /selinux mount point and the security filesystem itself. I don't see a file labeling rule for security_t in /etc/selinux/strict/contexts/files/file_contexts. It must be hard coded somewhere.

[R. Bosch]

Did not matter... root admin or root the user. Both incapable. A way around it is to compile the kernel with security labels but without selinux support. I use this kernel to install the base system before reboot.

Did any of this made it in any documentation yet?
_________________
Greetings / Met vriendelijke groet,

R. Bosch

[seventhguardian]

[DeathStar]

An easier way to fix this along with all other labels is to:

Boot into Permissive mode, then do the following:

mount -o bind / /mnt/rawroot
chroot /mnt/rawroot /bin/bash

env-update && source /etc/profile

rlpkg -avr

This will relabel all files on the system, including all dev devices back to what they should be for SELinux.