5 ms·

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 contain

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.

bigmac 11y ago
And user namespaces are really close to being merged: https://github.com/docker/docker/issues/15187 https://github.com/docker/docker/issues/15187
- davexunit 11y ago
  Great!
mrfusion 11y ago
Thanks. Have there been documented breakouts or it more theoretical?
- eropple 11y ago
  Not in recent versions.
  - kentonv 11y ago
    http://www.openwall.com/lists/oss-security/2015/07/22/7 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.
- count 11y ago
  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 https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf
shykes 11y ago
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).
- skj 11y ago
  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.
  - shykes 11y ago
    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.
    - skj 11y ago
      I'll have to take your word for it :) I'm not savvy enough about this topic - I just know the MVM architecture.
    - kentonv 11y ago
      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. :)
      - skj 11y ago

bigmac 11y ago

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

davexunit 11y ago
Great!

mrfusion 11y ago

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

eropple 11y ago
Not in recent versions.
- kentonv 11y ago
  http://www.openwall.com/lists/oss-security/2015/07/22/7 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.
count 11y ago
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 https://www.cs.unc.edu/~reiter/papers/2014/CCS1.pdf

shykes 11y ago

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).

skj 11y ago
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.
- shykes 11y ago
  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.
  - skj 11y ago
    I'll have to take your word for it :) I'm not savvy enough about this topic - I just know the MVM architecture.
  - kentonv 11y ago
    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. :)
    - skj 11y ago