Re: [gentoo-hardened] SELinux on Desktop Profile

[Sven Vermeulen]

The seclabel option isn't sufficient unless the /run location has its
labels reset as part of the bootup (akin to "restorecon -R /run" which
might be the case with systems and/or in fedora.

/run *must* have var_run_t as label. The context= mount option is "just" a
way to achieve that.

Wkr,
  Sven
On Mar 11, 2014 10:43 AM, "wraeth" <wraeth@××××××××××××.net> wrote:

> 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
>