[Lxc-users] read only rootfs

[Michael H. Warfield]

On Mon, 2011-07-04 at 22:16 +0200, Matto Fransen wrote: 
> Hi,
> 
> On Mon, Jun 27, 2011 at 06:05:13PM +0200, Samuel Maftoul wrote:
> 
> > I'm searching for a solution to have a read only rootfs inside an LXC
> > container.
> 
> I have a webserver running this way :)
> 
> > I created a container with the busybox template, this container works.
> > As soon as I try to mount it read only I have this message in the logs:
> 
> Create a rootfs outside the container.
> In the config of your container you add lines like:
> lxc.mount.entry=/path/to/rootfs/lib /var/lib/lxc/<container>/rootfs/lib none ro,bind 0 0
> and so on for all the dir's you want to mount readonly
> 
> Also create some system directories:
> # system mounts
> lxc.mount.entry=proc /var/lib/lxc/<container>/rootfs/proc proc none defaults 0 0
> lxc.mount.entry=shmfs /var/lib/lxc/<container>/rootfs/dev/shm tmpfs mode=0644 0 0
> lxc.mount.entry=sysfs /var/lib/lxc/<container>/rootfs/sys sysfs defaults  0 0

I find the bind mount is providing protection for propagating mount
point option changes from the guest to the host or to other guests.
That's good.

Unfortunately, I also still find that if there's a -o remount,ro in the
halt/reboot script, it still sets /dev/pts to ro and that still
propagates to the host and to the other containers triggering random
acts of terrorism like "unable to create pty/0" in the containers and
inability to start new containers in the host.  Not sure if we can apply
a bind to that or not.  I've been commenting those remounts out of the
halt and reboot scripts but I recently upgraded some containers from F12
to F13 and then to F14 and that installed new scripts.  Since I was
commenting out those lines automatically when I started the containers,
I didn't catch it and it clobbered the host.  Fortunately, I caught it
and just did a "mount -o remount,rw /dev/pts" in the host and everything
was back to normal.  Guess I'll do a "preshutdown" script that runs in
the containers to catch that and prevent it but it doesn't change the
fact a the container can have a serious impact on the host.

> And add the following line to the config of your container:
> lxc.cap.drop=sys_admin

Doing this also triggers random acts of terrorism in my containers.  The
sys_admin cap is far to broad and affects far to many other things like
setting the host names.  It would also prevent using the loopback device
and setting crypto keys on loopback devices and prevent mounting other
file systems like iso images and encrypted file systems or nfs file
systems from within the container.  I can only assume that autofs would
be totally broken.

> This last line prevents that one can jumo out of the readonly bind mounts from
> inside the container :)

We need a better way than that.

This needs kernel work in the container logic but, if something is
mounted ro outside the container, the container should treat it as ro
hardware and disallow rw remounting.  That's one thing.

The kernel should also prohibit, totally, the propagation of remount
options from inside a container to the outer host or to other
containers.  That is tantamount to a security vulnerability and clearly
a violation of container isolation.  It amounts to a semi-local Denial
of Service (DoD) vulnerability (semi-local because it's local to that
machine and its constellation of guests but it propagates between
guests).  I don't see any clean fix for this that doesn't involve
creating other problems (like dropping sys_admin) which violates the
ability to virtualize the machines properly.

> Cheers,
> 
> Matto
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110715/53d28e7e/attachment.pgp>