| 1 |
On Fri, 2014-03-07 at 18:56 +1100, wraeth wrote: |
| 2 |
|
| 3 |
Firstly, sorry for double-post before - bad connection and all :-/ |
| 4 |
|
| 5 |
> On Thu, 2014-03-06 at 15:15 +0000, Sven Vermeulen wrote: |
| 6 |
> > If you do something like the following, does the context then appear? |
| 7 |
> > |
| 8 |
> > #v+ |
| 9 |
> > mount -o remount,context=system_u:object_r:var_run_t /run |
| 10 |
> > #v- |
| 11 |
|
| 12 |
So I've been slowly plugging away at this trying to figure out why I |
| 13 |
can't seem to get my /run filesystem mounted with the correct security |
| 14 |
context. Here's what I've tried so far: |
| 15 |
|
| 16 |
manually issue `mount -o remount,context=...` |
| 17 |
Fails with "/run not mounted or bad option". From my readings on the |
| 18 |
'net, the kernel will actually refuse to remount context-labelled |
| 19 |
filesystems. This is also echoed in mount's manpage: |
| 20 |
"Note that kernel rejects any remount request that includes the context |
| 21 |
option even if unchanged from the current context." |
| 22 |
|
| 23 |
drop into emergency boot shell and remount /run |
| 24 |
Same as above, the filesystem refuses to remount. |
| 25 |
|
| 26 |
patch init script for dracut initramfs |
| 27 |
I actually thought this could be the best way to resolve the issue. I |
| 28 |
was quickly disillusioned. At the time the init script mounts the /run |
| 29 |
filesystem, the kernel has yet to initialize SELinux, and according to |
| 30 |
mail archive [1] (I see I'm not the first) mount will actually strip |
| 31 |
context options from mount commands if it finds that SELinux is not |
| 32 |
active. I can't help but agree with this as per the dmesg output: |
| 33 |
|
| 34 |
[ 8.540741] dracut: Mounted root filesystem /dev/mapper/luks-dbfe9b56-8185-4cea-8f52-086bd41382df |
| 35 |
[ 8.809942] dracut: Switching root |
| 36 |
<snip> |
| 37 |
[ 9.420023] SELinux: Completing initialization. |
| 38 |
[ 9.420024] SELinux: Setting up existing superblocks. |
| 39 |
|
| 40 |
sysinit service |
| 41 |
I even went to the length of creating a service in the sysinit.target |
| 42 |
prior to systemd-udevd.service to remount the run filesystem using the |
| 43 |
same method that the dracut init script uses - to mount the filesystem |
| 44 |
as /newrun, copy everything over, then `mount --move` it. This again |
| 45 |
failed, but honestly I'm not surprised at that. |
| 46 |
|
| 47 |
So at this stage I was somewhat frustrated that I hadn't come up with |
| 48 |
any solution, so I decided to try looking at a working example to see |
| 49 |
where the difference may lie. So I fired up a freshly installed virtual |
| 50 |
machine running Fedora 20, got into a terminal and: |
| 51 |
|
| 52 |
[root@asinine ~]# mount | grep run |
| 53 |
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) |
| 54 |
|
| 55 |
This looks remarkably familiar... |
| 56 |
nemesis ~ # mount | grep run |
| 57 |
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755) |
| 58 |
|
| 59 |
So now I feel I should ask the obvious question: does the /run |
| 60 |
filesystem, being a tmpfs-based filesystem, need to be mounted with |
| 61 |
specific security contexts, or is the mount option of 'seclabel' |
| 62 |
sufficient? |
| 63 |
|
| 64 |
If 'seclabel' is sufficient, then I don't think I need to do anything |
| 65 |
else with regards to filesystem labelling or anything like that - just |
| 66 |
the copious avc denials to contend with now! :) |
| 67 |
|
| 68 |
Cheers; |
| 69 |
wraeth |
| 70 |
|
| 71 |
[1] http://www.gossamer-threads.com/lists/gentoo/hardened/269150 |
Archives