On Sun, 2011-07-31 at 17:59 +0200, Robert Kawecki wrote: > Dnia 2011-07-30, sob o godzinie 21:10 -0400, Matthew Franz pisze: > > Had seen some previous discussions before, but are there any ways to > > mitigate this design vulnerability? > > > > http://blog.bofh.it/debian/id_413 > > > > Are there any workarounds? > > > > Thanks, > > > > - mdf > > > > The blog post explicitly mounts /sys... Why would you want your > container to even have the capability to mount anything?
Let's see... Where shall we start. If you're containerizing a "machine" or full system there's a laundry list of reasons you would want to. Maybe you want to mount an image, like a CD image or maybe an encrypted file system? Then, there's a variety of fuse file systems you might want access to for a variety of reasons. Maybe you want to run a service, like bind's named in a bind mounted chrooted environment (default for running name servers on Fedora for some time now: /var/named on /var/named/chroot/var/named type none (rw,bind) /var/named/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind) /etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind) /etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind) /etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind) /usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind) /etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind) /etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind) That gets done by "service named start". > If possible, drop CAP_SYS_ADMIN. That's been proposed as a workaround for some of the remount problems we have to where a partition is suppose to be mounted ro but the container can remount it rw. I've actually tried that trick. Yeah, that was an epic failure. Generally not possible in a generalized system container. Way too many things are impacted by CAP_SYS_ADMIN. Disabling that, you can't even set your own hostname in the container. You can't set crypto keys either. That's a sledge hammer approach that won't work in many if not most system containers. A simply application container? It might work in, depending on the application. Check out "man capabilities" and scroll down to CAP_SYS_ADMIN and look at that laundry list under it (and I'm not totally sure that list is comprehensive in the man page either) and honestly say there are not reasons for a container wanting to do at least one or two of them (even given that every container I have sets its own hostname). Gotta be a better answer than that. Regards, Mike -- 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
------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users