Re: [PLUG] runc/docker hole

[Rich Freeman <r-plug@thefreemanclan.net>]

On Tue, Feb 12, 2019 at 7:47 AM jeff <jeffv@op.net> wrote:
>
> https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/
>
> How bad is this? As bad as you can imagine.

IMO, not really.

LXC is vulnerable but isn't even issuing a CVE [1].  With both Docker
and LXC only privileged containers are affected, and privileged
containers should not be considered secure.

I would never run untrusted code in a privileged container.  UID 0 in
the container is UID 0 on the host.  The kernel isolation for these
processes is good for containing random bugs and letting these
processes use their own libraries and so on, but nobody from Linus on
down considers it reliable enough for hosting untrusted code.
Non-root processes in a privileged container are more secure, though
if they have access to local exploits to gain root in the container
then they can probably gain root on the host.

In general I'd be really cautious about hosting code you don't control
in a container.  I'd personally stick to VMs for this sort of
application.  Unprivileged containers are going to be more secure, and
if you're hosting customer containers you could give each customer its
own non-root UID and run their containers in these, which should layer
the container isolation underneath the standard UID isolation in the
host.  They can have root in unprivileged containers - these processes
only have root in the context of the container and the processes lose
privs from the host.  Even then, linux namespaces are new enough that
it is possible that vulnerabilities will be found.

If you're using privileged containers to host stuff that you'd
otherwise be hosting in services on the host, then there is nothing to
see here.  I'd certainly deploy the patches since you want containers
to have isolation, but you're not really exposed to any new risk as
root on the host already can do everything.

Oh, and for the curious, nspawn is apparently not affected by this
particular bug.  I would consider privileged nspawn containers to be
just as unsafe anyway.

[1]:
https://linuxcontainers.org/lxc/security/

As privileged containers are considered unsafe, we typically will not
consider new container escape exploits to be security issues worthy of
a CVE and quick fix. We will however try to mitigate those issues so
that accidental damage to the host is prevented.

Privileged containers are defined as any container where the container
uid 0 is mapped to the host's uid 0. In such containers, protection of
the host and prevention of escape is entirely done through Mandatory
Access Control (apparmor, selinux), seccomp filters, dropping of
capabilities and namespaces.

Those technologies combined will typically prevent any accidental
damage of the host, where damage is defined as things like
reconfiguring host hardware, reconfiguring the host kernel or
accessing the host filesystem.

LXC upstream's position is that those containers aren't and cannot be root-safe.

They are still valuable in an environment where you are running
trusted workloads or where no untrusted task is running as root in the
container.

We are aware of a number of exploits which will let you escape such
containers and get full root privileges on the host. Some of those
exploits can be trivially blocked and so we do update our different
policies once made aware of them. Some others aren't blockable as they
would require blocking so many core features that the average
container would become completely unusable.


-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug