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 >
