[Lxc-users] Mitigating LXC Container Evasion?

[Olivier Mauras]

That's where MAC system comes handy.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

"Michael H. Warfield" <mhw at WittsEnd.com> wrote:

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 | 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!
_____________________________________________

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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110731/3711f962/attachment.html>