Re: SELinux on Desktop Profile

On Fri, 2014-03-07 at 18:56 +1100, wraeth wrote:

Firstly, sorry for double-post before - bad connection and all :-/

> On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote:
> > 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-

So I've been slowly plugging away at this trying to figure out why I
can't seem to get my /run filesystem mounted with the correct security
context.  Here's what I've tried so far:

manually issue `mount -o remount,context=...`
Fails with "/run not mounted or bad option".  From my readings on the
'net, the kernel will actually refuse to remount context-labelled
filesystems.  This is also echoed in mount's manpage:
"Note that kernel rejects any remount request that includes the context
option even if unchanged from the current context."

drop into emergency boot shell and remount /run
Same as above, the filesystem refuses to remount.

patch init script for dracut initramfs
I actually thought this could be the best way to resolve the issue.  I
was quickly disillusioned.  At the time the init script mounts the /run
filesystem, the kernel has yet to initialize SELinux, and according to
mail archive [1] (I see I'm not the first) mount will actually strip
context options from mount commands if it finds that SELinux is not
active.  I can't help but agree with this as per the dmesg output:

[    8.540741] dracut: Mounted root filesystem /dev/mapper/luks-dbfe9b56-8185-4cea-8f52-086bd41382df
[    8.809942] dracut: Switching root
<snip>
[    9.420023] SELinux:  Completing initialization.
[    9.420024] SELinux:  Setting up existing superblocks.

sysinit service
I even went to the length of creating a service in the sysinit.target
prior to systemd-udevd.service to remount the run filesystem using the
same method that the dracut init script uses - to mount the filesystem
as /newrun, copy everything over, then `mount --move` it.  This again
failed, but honestly I'm not surprised at that.

So at this stage I was somewhat frustrated that I hadn't come up with
any solution, so I decided to try looking at a working example to see
where the difference may lie.  So I fired up a freshly installed virtual
machine running Fedora 20, got into a terminal and:

[root@asinine ~]# mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

This looks remarkably familiar...
nemesis ~ # mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)

So now I feel I should ask the obvious question: does the /run
filesystem, being a tmpfs-based filesystem, need to be mounted with
specific security contexts, or is the mount option of 'seclabel'
sufficient?

If 'seclabel' is sufficient, then I don't think I need to do anything
else with regards to filesystem labelling or anything like that - just
the copious avc denials to contend with now! :)

Cheers;
wraeth

[1] http://www.gossamer-threads.com/lists/gentoo/hardened/269150

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

iF4EABEIAAYFAlMe2o8ACgkQGYlqHeQRhkzrAQD/RWtlO1VSaRTiAUYLzQXgeS7j
Q2/VfRggnniW/bqIzpQA/jxvsXC/+ymR0a8Orwv1N5cTbgyUQMF1k6R7Akrq9+N5
=JKeu
-----END PGP SIGNATURE-----