Hacker News Reader

Comment by mrfusion | Hacker News Reader

Would docker make a good sandbox or can applications break out?

Unfortunately, no, Docker is not a good sandbox, because it prioritizes compatibility over security while choosing a very wide API (the Linux kernel API) as its security boundary.

Privilege escalation vulnerabilities are found in the Linux kernel fairly regularly -- like, monthly, sometimes weekly. An attacker who can run arbitrary code in your Docker container would only need to wait a couple weeks for the next vulnerability report (or poke around the kernel code and find a new one) and then hit you before you can patch. The most recent example is this batch of CVEs: http://www.openwall.com/lists/oss-security/2015/07/22/7

Part of the problem is that the Linux kernel API is gigantic with lots of obscure features that haven't been carefully vetted. One way to solve this problem is to drastically constrain the attack surface by doing things like using seccomp-bpf to block obscure system calls, not mounting /proc or /sys, etc. Unfortunately doing this will sometimes break apps. Usually the apps can be tweaked to work around the missing features.

Docker is not meant to be a sandbox. Docker is meant to be able to run any arbitrary Linux software. So Docker comes down on the side of compatibility, and does not use attack-surface-reduction techniques (unless you manually configure them, which no one does).

In contrast, Sandstorm.io (of which I am lead developer) prioritizes security over compatibility, and makes attack surface reduction mandatory for all apps. Some docs:

https://docs.sandstorm.io/en/latest/developing/security-prac...

https://blog.sandstorm.io/news/2014-08-13-sandbox-security.h...

The second link is almost exactly a year old, but has proven true: we've seen a lot of kernel exploits in the last year that were non-events for Sandstorm. The above-mentioned CVE, for example, did not affect Sandstorm because we block the modify_ldt syscall.

Note that Google Chrome's sandbox pioneered these techniques -- they originally created seccomp-bpf.

It makes a good sandbox because it uses a chroot/pivot_root + unshares pid/net/uts/mnt/ipc namespaces, but it doesn't use user namespaces so root in the container is root on the host which is a bit scary.

And user namespaces are really close to being merged: https://github.com/docker/docker/issues/15187

Great!

Thanks. Have there been documented breakouts or it more theoretical?

Not in recent versions.

http://www.openwall.com/lists/oss-security/2015/07/22/7 is three weeks old and would allow breaking out of Docker. Bugs like this (in Linux) are found regularly.

Even if the code can't break out, be aware of other issues of non-fully virtualized multi-tenancy:

https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf

Another important point: running untrusted code in Linux containers is not considered safe in all configurations, but it is safe in some configurations. So if you know what you're doing, you can already configure Docker to run untrusted payloads. That is what platforms like Heroku, Dotcloud, Google App Engine have been doing for years. The most important aspect of such a configuration is: don't allow running it as root (you can specify uid/gid privilege drop from Docker's CLI, management API and in the image format).

Classic app engine doesn't use docker, and Managed VMs app engine is run in a Compute Engine VM in the customer's own project, partly to avoid having to worry about running untrusted code since Compute Engine handles the security there.

You are correct. GAE classic is not a good example since it uses language-specific sandboxing. Hopefully you'll agree that my overall point still stands: when configured and managed properly there is consensus that you can run certain untrusted payloads in linux containers today.

I'll have to take your word for it :) I'm not savvy enough about this topic - I just know the MVM architecture.

Yes, where that configuration involves:

- Not running as root.

- Enabling the no_new_privs prctl to prevent attacks on buggy setuid binaries.

- Using an aggressive seccomp-bpf filter.

- Hiding /proc, /sys, most of /dev, etc.

- Other things I'm forgetting at the moment. :)

Given the list of things you need to do to ensure security, I'm going to go out on a limb and say that "configured and managed properly" is something that does not happen in reality. Until there is something more fundamental making breaches impossible, you're never going to be sure that there isn't something that you've missed.

It's ok that Docker containers are not yet secure sandboxes, and it would be a great if that changed.

Exactly. It really needs to be the platform's job to provide a reasonable sandbox configuration that users can turn on or off as a single switch. Or, better yet, one that is always on. Because while it's generally easy for apps to work around things like missing /proc, most developers aren't going to bother if it isn't mandatory that they do so.

But potentially breaking compatibility with existing apps is understandably not something Docker wants to do. (Whereas it's something sandstorm.io is happy to do, because apps already need to be tweaked in other ways for it.)

Reply on news.ycombinator.com