4 ms·

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 a

by 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
    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.
    - kentonv 11y ago
      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.)

by skj 11y ago

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
  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.
  - kentonv 11y ago
    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.)