swift at gentoo
Apr 8, 2012, 4:44 AM
Post #5 of 6
(242 views)
Permalink
|
On Wed, Apr 04, 2012 at 12:12:35PM +0100, Paul de Vrieze wrote:
> I decided to finally take the plunge and try to see if I could get selinux
> on my machine. There were some easy problems to fix (like selinux-cups not
> depending on selinux-lpd) but it seems that latest openrc with latest udev
> and latest kernel don't really like eachother. I get quite some errors at
> boot as well as misslabeled dynamic files (/run and /dev are misslabeled).
> I've attached the errors and the output of relabeling /dev
Hmm, I can't seem to reproduce all you see, although I can see it is
becoming quite messy nowadays. Is the /run mislabeling still a fact? What
might be happening (although I can't confirm this here) is that your
(unmounted) /run has no good label. The moment openrc mounts it (through
/lib64/rc/sh/init.sh) the mount inherits the context, but it also means that
if you relabel, you are only relabeling the tmpfs (and not the real
directory).
You can "solve" it by bindmounting your root file system, and then setting
the context of /run (chcon -t var_run_t should suffice).
The /dev is another issue. I currently don't have to deal with it as I'm
forced to use an initramfs (as I have a separate /usr) so I need to relabel
/dev anyhow before switching to enforcing mode :-( But I can imagine what
happens... kdevtmpfs runs as kernel_t and creates device files in /dev
(which are labeled device_t).
From what I read, udev is supposed to relabel the files. Although I can't
confirm this, I also see that udev isn't the first thing that is started
(and that, if it gets started in enforcing mode, it might already need a
correctly labeled /dev when running without unconfined domains).
Oh well, still lots of work ahead.
Wkr,
Sven Vermeulen
|
relabeldev
