Good question - no, we don't. Developers can request for certain whitelisted commands to be executed within an environment that we know to be safe. For example, you can specify a list of system packages, and dotcloud will install them from the official LTS Ubuntu repository.
There's an ongoing discussion in the Docker community on the best way to make this possible in a shared environment. One possibility is to add support for OpenVZ, which has a better track record on that front (although it's not clear how much of the perceived difference is just fud). Another is to combine namespaces with SELinux, so that even if you break out of the namespace, you're stuck in a "limbo" context with no ability to do harm. Lastly, there's the possibility of extra instrumentation around the container, to limit the risk - for example you could allow root privileges only for a whitelist of commands on a whitelist of base images. Or you could only authorize network connectivity with a whitelist of remote hosts (keeping in mind most use cases which require root access involve short-lived image building). Or you could map containers with root privileges to dedicated virtual machines, separately from the unprivileged containers. Etc.
To clarify, I'm talking about our use of containers at dotCloud, which is a multi-tenant environment.
Docker _does_ allow running processes as root inside a container, and it also allows dropping privileges to the uid of your choice. It all depends on your particular use case.
Docker allows 'everything' minus the explicit list linked to in the article. What it should do is allow an explicit list, which recently became possible.
Comments
Do you allow any of that untrusted code to run AS ROOT within a container, though? (If so: what capabilities do you allow it to have?)
Good question - no, we don't. Developers can request for certain whitelisted commands to be executed within an environment that we know to be safe. For example, you can specify a list of system packages, and dotcloud will install them from the official LTS Ubuntu repository.
There's an ongoing discussion in the Docker community on the best way to make this possible in a shared environment. One possibility is to add support for OpenVZ, which has a better track record on that front (although it's not clear how much of the perceived difference is just fud). Another is to combine namespaces with SELinux, so that even if you break out of the namespace, you're stuck in a "limbo" context with no ability to do harm. Lastly, there's the possibility of extra instrumentation around the container, to limit the risk - for example you could allow root privileges only for a whitelist of commands on a whitelist of base images. Or you could only authorize network connectivity with a whitelist of remote hosts (keeping in mind most use cases which require root access involve short-lived image building). Or you could map containers with root privileges to dedicated virtual machines, separately from the unprivileged containers. Etc.
To clarify, I'm talking about our use of containers at dotCloud, which is a multi-tenant environment.
Docker _does_ allow running processes as root inside a container, and it also allows dropping privileges to the uid of your choice. It all depends on your particular use case.
what capabilities do you allow it to have?
Docker allows 'everything' minus the explicit list linked to in the article. What it should do is allow an explicit list, which recently became possible.