Re: SELinux on Desktop Profile

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EABEIAAYFAlMZAgMACgkQGYlqHeQRhkzlZwD8CoYN3NlII4JAEKtv2xka6Htl
TYu+b/JHgir7L0rps8AA/ihiVgTSm+KjkAb/w1MOYbDDMh2tZsxH8u+5NqHrJSsz
=9uvr
-----END PGP SIGNATURE-----