1 |
On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote: |
2 |
> On Thu, Mar 06, 2014 at 12:40:21AM +1100, wraeth wrote: |
3 |
> > * Rebuild util-linux * |
4 |
> > This should happen just prior to the first reboot (and any initrd's |
5 |
> > should be rebuilt to include the new mount binary, i guess). |
6 |
> |
7 |
> Wouldn't the package (util-linux) be rebuild anyway? It uses USE=selinux so |
8 |
> the "emerge -uDN world" should rebuild it (with libselinux bindings). |
9 |
|
10 |
This *would* be done with an `emerge -uDN @world`; however the manual |
11 |
has you modify your fstab to include mount point contexts (code listing |
12 |
1.3/1.4/1.8), build the SELinux-enabled kernel (listing 1.7), then |
13 |
reboot after listing 1.9, with the world update coming in at listing |
14 |
2.5. |
15 |
|
16 |
Doing a world update prior to then is advised against as per the note |
17 |
below listing 1.5 ("Do not rebuild your system right now <snip> pull in |
18 |
SELinux policies which could make your system unreachable ..."). |
19 |
|
20 |
However, as I experienced following through this, rebooting as |
21 |
instructed, without rebuilding util-linux, failed to mount the |
22 |
filesystems as it hasn't been built against libselinux. |
23 |
|
24 |
As per your comment below about keeping track of where things are |
25 |
mentioned, I can file this as a bug, too. |
26 |
|
27 |
> > * Select policy type * |
28 |
> > This is more of a note on the documentation (I know it's out of date, |
29 |
> > (or at least so the wiki says) but for reference nonetheless). |
30 |
> |
31 |
> Where on the wiki does it say that? The SELinux handbook is not out of |
32 |
> date. It had an issue if you use 'targeted' as you rightly said but that's a |
33 |
> bug, not due to potentially being outdated. And not having it registered as |
34 |
> a bug on bugs.gentoo.org made it so it took a while before it got properly |
35 |
> noticed (I can read mailinglists from work, but when I can do a bit of |
36 |
> Gentoo development I check the bug list and forget that there were things |
37 |
> mentioned on the mailinglist). |
38 |
|
39 |
I could have sworn that I saw it say somewhere that the documentation |
40 |
was in need of updating, but now that I'm looking, I can't find it... I |
41 |
didn't want to file a bug (given my understanding at the time that the |
42 |
documentation was known to be in need of updating) since it would just |
43 |
be pointing out what's already known - I just wanted to add my |
44 |
observation so that whenever changes were made, it would be considered. |
45 |
|
46 |
That being said, it *was* just a matter of ordering of steps, and it's |
47 |
now been reported and resolved. :) |
48 |
|
49 |
> Can you check your dmesg or logs? I don't know systemd-remount-fs but |
50 |
> perhaps it's because /run is already mounted and thus it cannot mount it |
51 |
> (without being smart enough to use "-o remount"). |
52 |
> |
53 |
> If you do something like the following, does the context then appear? |
54 |
> |
55 |
> #v+ |
56 |
> mount -o remount,context=system_u:object_r:var_run_t /run |
57 |
> #v- |
58 |
> |
59 |
> My system gives the following: |
60 |
> |
61 |
> #v+ |
62 |
> $ mount | grep run |
63 |
> tmpfs on /run type tmpfs (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime) |
64 |
> #v- |
65 |
|
66 |
I had a brief look at this last night but haven't had a look in-depth as |
67 |
yet. I did notice that there is a point during boot at which it |
68 |
relabels the /dev and /run filesystems, but the resulting mount point |
69 |
still does not have the appropriate context. This could be either due |
70 |
to /run already being mounted, or an issue with the initrd. |
71 |
|
72 |
I don't have access to that machine at the moment, but I'll investigate |
73 |
this more thoroughly and see what I can figure out. |
74 |
|
75 |
Thanks for the help, and I'll let you know what I find. |
76 |
|
77 |
Cheers; |
78 |
wraeth |