Re: SELinux on Desktop Profile

Sven Vermeulen <[email protected]>
Newsgroups gmane.linux.gentoo.hardened
Message-ID <CAPzO=NxiCLCtAL+7ttiDLgfa1j3HA1qsgKGjAL==pZWqdu97sw@mail.gmail.com>
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" <[email protected]> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.