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
signature.asc
Description: This is a digitally signed message part
