On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote: > On Thu, Mar 06, 2014 at 12:40:21AM +1100, wraeth wrote: > > * Rebuild util-linux * > > This should happen just prior to the first reboot (and any initrd's > > should be rebuilt to include the new mount binary, i guess). > > Wouldn't the package (util-linux) be rebuild anyway? It uses USE=selinux so > the "emerge -uDN world" should rebuild it (with libselinux bindings).
This *would* be done with an `emerge -uDN @world`; however the manual
has you modify your fstab to include mount point contexts (code listing
1.3/1.4/1.8), build the SELinux-enabled kernel (listing 1.7), then
reboot after listing 1.9, with the world update coming in at listing
2.5.
Doing a world update prior to then is advised against as per the note
below listing 1.5 ("Do not rebuild your system right now <snip> pull in
SELinux policies which could make your system unreachable ...").
However, as I experienced following through this, rebooting as
instructed, without rebuilding util-linux, failed to mount the
filesystems as it hasn't been built against libselinux.
As per your comment below about keeping track of where things are
mentioned, I can file this as a bug, too.
> > * Select policy type *
> > This is more of a note on the documentation (I know it's out of date,
> > (or at least so the wiki says) but for reference nonetheless).
>
> Where on the wiki does it say that? The SELinux handbook is not out of
> date. It had an issue if you use 'targeted' as you rightly said but that's a
> bug, not due to potentially being outdated. And not having it registered as
> a bug on bugs.gentoo.org made it so it took a while before it got properly
> noticed (I can read mailinglists from work, but when I can do a bit of
> Gentoo development I check the bug list and forget that there were things
> mentioned on the mailinglist).
I could have sworn that I saw it say somewhere that the documentation
was in need of updating, but now that I'm looking, I can't find it... I
didn't want to file a bug (given my understanding at the time that the
documentation was known to be in need of updating) since it would just
be pointing out what's already known - I just wanted to add my
observation so that whenever changes were made, it would be considered.
That being said, it *was* just a matter of ordering of steps, and it's
now been reported and resolved. :)
> Can you check your dmesg or logs? I don't know systemd-remount-fs but
> perhaps it's because /run is already mounted and thus it cannot mount it
> (without being smart enough to use "-o remount").
>
> If you do something like the following, does the context then appear?
>
> #v+
> mount -o remount,context=system_u:object_r:var_run_t /run
> #v-
>
> My system gives the following:
>
> #v+
> $ mount | grep run
> tmpfs on /run type tmpfs
> (rw,rootcontext=system_u:object_r:var_run_t,seclabel,nosuid,nodev,noexec,relatime)
> #v-
I had a brief look at this last night but haven't had a look in-depth as
yet. I did notice that there is a point during boot at which it
relabels the /dev and /run filesystems, but the resulting mount point
still does not have the appropriate context. This could be either due
to /run already being mounted, or an issue with the initrd.
I don't have access to that machine at the moment, but I'll investigate
this more thoroughly and see what I can figure out.
Thanks for the help, and I'll let you know what I find.
Cheers;
wraeth
signature.asc
Description: This is a digitally signed message part
