Breaking Out of Docker via RunC(twistlock.com)
twistlock.com
Breaking Out of Docker via RunC
https://www.twistlock.com/labs-blog/breaking-docker-via-runc-explaining-cve-2019-5736/
5 comments
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.
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.
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).
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.
If you say “don’t run your containers as root on the host”, this matches the issue better.
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).
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).
Another with ptrace (fixed by making the process non-dumpable).
Are those diagrams generated via something or did you create it in an app?
They're created using https://www.draw.io/
why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
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.
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.
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.
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.
Something I've been wondering for a while (and you may be placed to answer): is firecracker part of the isolation story for Fargate - or is it regular EC2 instances?
Hi, I'm from the core compute engineering part of AWS.
Like most good stories, there's a beginning, middle, and end. We're in the middle now, and Fargate uses both regular EC2 instances and Firecracker in some cases.
Like most good stories, there's a beginning, middle, and end. We're in the middle now, and Fargate uses both regular EC2 instances and Firecracker in some cases.
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.
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).
I am not sure why this got downvoted, it is a valid question which got an informative response.
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.
Good security teams*. I have definitely experienced overzealous bad security.
https://brauner.github.io/2019/02/12/privileged-containers.h...