Breaking Out of Docker via RunC (opens in new tab)

(twistlock.com)

116 pointszelivans7y ago20 comments

20 comments

16 comments · 5 top-level

awilddocker7y ago· 7 in thread

why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately

cyphar7y ago

Allowing your users to run something as root inside a container should violate a security audit. And yes, Docker is almost irresponsible to continue defaulting to root.

But containers themselves should not -- there are plenty of security benefits to using containers. There is no real difference between an LXC container and a runc container besides the fact that Docker defaults to running thing as root and without user namespaces. That is obviously a bad decision, but it's not an indictment of containers as a concept.

MotiveMe7y ago

We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.

otterley7y ago

AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.

1 more reply

cyphar7y ago

If you use user namespaces and don't run as host root, they provide a clear security value (unless your alternative is that you use user namespaces in your program, at which point you are making your own container runtime). Docker's (and LXC's) default seccomp profile has blocked something like 95% of kernel 0days since they were added, for instance.

yutghgh7y ago

Because the abstractions are good and the implementation gets better over time as with any other software. Obviously truly sensitive data should be handled on separate physical nodes (defense in depth).

praptak7y ago

I am not sure why this got downvoted, it is a valid question which got an informative response.

dasil0037y ago

Because it's a hyperbolic rhetorical question. Security teams don't just unilaterally ban things without context, especially things that provide significant business value. It's about threat modeling and what the risk is in practice for the company and use case in question.

1 more reply

helper7y ago· 2 in thread

This is a really great exploration of this vulnerability.

It makes me sad that lxc doesn't get more love. LXC has had unprivileged containers as its default for 5+ years now. Its a really solid tool set that has mostly been passed over for lack of marketing.

barbecue_sauce7y ago

The reason Docker gets so much attention is its container image repository infrastructure. I'm sure LXC has something similar, but Docker's is built-in and has almost anything you can think of. (Of course, this presents other security/trust issues).

bboreham7y ago

Need to be careful that Docker and LXC both default to unprivileged, however they use the term to mean different things.

If you say “don’t run your containers as root on the host”, this matches the issue better.

yutghgh7y ago· 1 in thread

This is very interesting, because most docker break outs I see are exploits in the linux kernel, but this is one of the few in the containerization components themselves (first one I remember in runC).

cpuguy837y ago

Definitely not the first. There was one with leaking file descriptors which weren't opened with O_CLOEXEC.

Another with ptrace (fixed by making the process non-dumpable).

amerine7y ago· 1 in thread

Are those diagrams generated via something or did you create it in an app?

uvuv7y ago

They're created using https://www.draw.io/

simosx7y ago

A post by Christian Brauner (LXC/LXD developer) on how LXC and LXD are affected. In summary, unprivileged containers (as found in LXD) are not affected.

https://brauner.github.io/2019/02/12/privileged-containers.h...

j / k navigate · click thread line to collapse

20 comments

16 comments · 5 top-level

awilddocker7y ago· 7 in thread

why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately

cyphar7y ago

Allowing your users to run something as root inside a container should violate a security audit. And yes, Docker is almost irresponsible to continue defaulting to root.

MotiveMe7y ago

otterley7y ago

AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.

1 more reply

cyphar7y ago

yutghgh7y ago

praptak7y ago

I am not sure why this got downvoted, it is a valid question which got an informative response.

dasil0037y ago

1 more reply

helper7y ago· 2 in thread

This is a really great exploration of this vulnerability.

barbecue_sauce7y ago

bboreham7y ago

Need to be careful that Docker and LXC both default to unprivileged, however they use the term to mean different things.

If you say “don’t run your containers as root on the host”, this matches the issue better.

yutghgh7y ago· 1 in thread

cpuguy837y ago

Definitely not the first. There was one with leaking file descriptors which weren't opened with O_CLOEXEC.

Another with ptrace (fixed by making the process non-dumpable).

amerine7y ago· 1 in thread

Are those diagrams generated via something or did you create it in an app?

uvuv7y ago

They're created using https://www.draw.io/

simosx7y ago

A post by Christian Brauner (LXC/LXD developer) on how LXC and LXD are affected. In summary, unprivileged containers (as found in LXD) are not affected.

https://brauner.github.io/2019/02/12/privileged-containers.h...

j / k navigate · click thread line to collapse