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