[Lxc-users] How much LXC is secure?

[Serge Hallyn]

Quoting Adam Ryczkowski (adam.ryczkowski at statystyka.net):
> On 11.11.2013 13:43, Daniel P. Berrange wrote:
> > On Mon, Nov 11, 2013 at 01:19:25PM +0100, Adam Ryczkowski wrote:
> >> Last year I've read many times, that LXC have some outstanding
> >> security issues, and are the encapsulation is not tight enough to
> >> prevent hijacking the host, when the guest is compromised. But I
> >> never managed to find out, how exactly does one escape the LXC
> >> container.
> >>
> >> I'm using the LXC containers as a holders for virtual computers
> >> (just as advertized in
> >> https://help.ubuntu.com/12.04/serverguide/lxc.html) in hope, that
> >> this will make another line of defense against hackers anyway.
> >>
> >> Recently the host got hacked (Ubuntu 12.04 precise with kernel
> >> 3.8.2) , and I have renewed suspicions about the impenetrability of
> >> LXC.
> >>
> >> I wonder what is the state of affairs now. How does one implement
> >> virtual computers inside LXC containers, so root on a guest cannot
> >> get root rights on host?
> > If you have a process running as "root" inside the container, then
> > you should assume it is *insecure* unless the container is configured
> > with either a user namespace uid+gid mapping, or some mandatory
> > access control (MAC) system like SELinux / AppArmour.  Without the
> > uid/gid mapping or a MAC layer, root in the container has all sorts
> > of access to stuff in sysfs & procfs that it can use to cause havoc
> > in the host, and quite possibly other things besides.
> >
> > Daniel
> Do you know by chance, how does it apply to the long Ubuntu 12.04? It 
> uses AppArmour, but how sufficiently it is configured out-of-the-box?

Using lxc as described in the server guide on 12.04, apparmor is
enabled by default.  We say it's enough to protect against accidental
host abuse by root in the container, but not against malicious attacks.

> How to check if the server uses uid+gid mapping?

If the kernel has the support, then /proc/self/uid_map will exist.  Lxc
itself currently supports it if you run a kernel that does.  You can
get such a kernel at ppa:ubuntu-lxc/kernel if you like, or you can use
ubuntu trusty's kernel, which is working quite well.

As Daniel said, it's been possible for awhile to use lxc.id_map to
run containers in a user namespace - when started by root on the host.
For the next few months, the focus will be on allowing non-root users
to create, start, control, and destroy (at least simple) containers.

As for your host getting hacked, I'd really be curious to know how it
happened.  Do you have any information on the attack vector?

The most glaring hole is kernel system call 0-days.  Especially in
commonly used syscalls.  You can use user namespace to map root in
a container to uid 100000 on the host;  you can use selinux/apparmor
and cgroups to protect against access of host resources;  you can use
seccomp to prevent the container from using system calls which you don't
expect it to use, and/or which may be suspect - like 32/64-bit compat
syscalls.  But if there's going to be an 0-day in SYS_futex, none of
that will help.

-serge