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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users