4 ms·

Docker containers do not need to run as root and the documentation does recommend running containers as non-root users. Yet, unless something is default, it's h

Docker containers do not need to run as root and the documentation does recommend running containers as non-root users. Yet, unless something is default, it's hard to make users follow best practices. For that reason, user namespaces are important. Now, while they're not in a stable release yet, user namespaces have landed into Docker's master branch. Don't expect to wait long for this feature. If you feel there are further actionable steps to move best-practices into default behaviors in Docker today, or improve security please feel free to submit a PR or open a thread on the mailing list. (If it's a vulnerability, however, email security@docker.com)

eropple 11y ago
> Docker containers do not need to run as root and the documentation does recommend running containers as non-root users. Yet, unless something is default, it's hard to make users follow best practices. For that reason, user namespaces are important. Definitely, but, in my experience, it gets worse than that, and why this is really important and not just important. Most containers are built on top of full OS images, with a full OS image's worth of vulnerabilities (some inert because services aren't running, but setuid's still respected--and I wonder how many setuid'd tools are actively tested in a containerized environment!), and it's rare in my experience that those base containers actually get updated after the end user selects one and a version to go along with it. Which means that even a properly-built container that doesn't run its internals as a non-root user may--and a pessimist might say "probably does"--have user escalation bugs squirreled away somewhere that the user not only doesn't know about, but isn't capable of auditing or is even aware that they might exist. This, not "users don't read docs", is why I am so very, very salty about this in Docker, and while I'm glad that now Docker users (and, full disclosure, I'm not one anymore in part because of the poor security story--monolithic do-everything daemon running as root, no user namespaces--and in part just not wanting to be the stooge for somebody's platform play) don't have to "expect to wait long", this was promised in something like Docker 1.4, a year ago.
- kylequest 11y ago
  > Most containers are built on top of full OS images, with a full OS image's worth of vulnerabilities This is one of the problems DockerSlim (http://dockersl.im http://dockersl.im) is trying to address. You take those containers built on full OS images and you remove everything your app is not using reducing the attack surface.
- ecnahc515 11y ago
  Disclaimer: I work at CoreOS. Have you considered using rkt as an alternative to docker? It tries to avoid a lot of the security related problems docker has. Specifically there's no daemon which runs as root, instead rkt is invoked directly, so the only time rkt requires root, is the actual execution of a container, not downloading or verifying for example. Next, rkt by default wont run unsigned or untrusted images meaning by default you must trust the image/author, and finally rkt has the ability to run your container in a light weight VM using lkvm, getting you all the benefits of VM level isolation, but you have the ability to use the same container tooling for it all, and decreasing the overhead by optimizing for the container use-case. Recently rkt also got support for logging different events into the TPM audit log, making it possible to have tamper-proof audit trails of what containers have run on your system. User namespaces are also implemented, but I'm not sure how well tested they are. Solving the problem of using, and creating large full OS images is quite difficult. As a stepping stone we have also created a tool which scans container images on our Quay.io registry looking for images effected by CVEs. This should hopefully help until we can properly solve creating functional minimal containers easily, but that's unfortunately not quite as easy as just telling people to use buildroot (you still need a way to update those images and know when apps need have security updates). Hope this helps.
  - eropple 11y ago
    > Have you considered using rkt as an alternative to docker? I have, and I respect it a lot more--and CoreOS in general has struck me for quite some time as being the adults in the room in this space, I think the value prop remains very shaky but I appreciate that CoreOS seems to give a damn--but I don't have a lot of use for rkt in general. The only place I have any multi-tenancy, I'm using FreeBSD and jails. (I'd like to use Illumos or OpenIndiana, as I better understand that stack than I do FreeBSD, but cperciva has done a great job with FreeBSD AMIs on AWS and I don't have the bandwidth to maintain an OpenIndiana AMI.)
    - jzelinskie 11y ago
      Have you taken a look at jetpack[0]? Jetpack is an implementation of the appc specification, just like rkt, but is intended for use on FreeBSD. [0]: https://github.com/3ofcoins/jetpack https://github.com/3ofcoins/jetpack
mbreese 11y ago
Don't you need root access to even start the container? I think that's there is a disconnect here. There is a difference between running a container as root and the process w/in the container running as root. Sure, you don't need to have the process running as root in the container, but you need to have root-equivalent access to start the container. For a (large) subset of use-cases, this just isn't an option. I should be able to allow any given user of a system the ability to start a docker container and be confident that they won't be able to break the host system. Until this is the case, you don't have security in Docker.
- davexunit 11y ago
  The key is user namespaces. Unprivileged users can create containers easily via user namespaces. Once the user creates a user namespace, they have root in that namespace and are free to unshare the rest of the namespaces. This is how I wrote 'guix environment --container'[0], a tool for creating isolated development environments using the GNU Guix package manager. The big caveat is that unprivileged users do not setuid/setgid capability, so the number of uids/gids in the container is limited to 1, but I believe that even this is being dealt with in Linux now. [0] https://gnu.org/software/guix/manual/html_node/Invoking-guix-environment.html#Invoking-guix-environment https://gnu.org/software/guix/manual/html_node/Invoking-guix...
- ewindisch 11y ago
  You also need to be root to manage your init process and in production, this is how Docker is treated. That said, I've seen work being done to add RBAC, given there are a set of users that desire this.

eropple 11y ago

> Docker containers do not need to run as root and the documentation does recommend running containers as non-root users. Yet, unless something is default, it's hard to make users follow best practices. For that reason, user namespaces are important. Definitely, but, in my experience, it gets worse than that, and why this is really important and not just important. Most containers are built on top of full OS images, with a full OS image's worth of vulnerabilities (some inert because services aren't running, but setuid's still respected--and I wonder how many setuid'd tools are actively tested in a containerized environment!), and it's rare in my experience that those base containers actually get updated after the end user selects one and a version to go along with it. Which means that even a properly-built container that doesn't run its internals as a non-root user may--and a pessimist might say "probably does"--have user escalation bugs squirreled away somewhere that the user not only doesn't know about, but isn't capable of auditing or is even aware that they might exist. This, not "users don't read docs", is why I am so very, very salty about this in Docker, and while I'm glad that now Docker users (and, full disclosure, I'm not one anymore in part because of the poor security story--monolithic do-everything daemon running as root, no user namespaces--and in part just not wanting to be the stooge for somebody's platform play) don't have to "expect to wait long", this was promised in something like Docker 1.4, a year ago.

kylequest 11y ago
> Most containers are built on top of full OS images, with a full OS image's worth of vulnerabilities This is one of the problems DockerSlim (http://dockersl.im http://dockersl.im) is trying to address. You take those containers built on full OS images and you remove everything your app is not using reducing the attack surface.
ecnahc515 11y ago
Disclaimer: I work at CoreOS. Have you considered using rkt as an alternative to docker? It tries to avoid a lot of the security related problems docker has. Specifically there's no daemon which runs as root, instead rkt is invoked directly, so the only time rkt requires root, is the actual execution of a container, not downloading or verifying for example. Next, rkt by default wont run unsigned or untrusted images meaning by default you must trust the image/author, and finally rkt has the ability to run your container in a light weight VM using lkvm, getting you all the benefits of VM level isolation, but you have the ability to use the same container tooling for it all, and decreasing the overhead by optimizing for the container use-case. Recently rkt also got support for logging different events into the TPM audit log, making it possible to have tamper-proof audit trails of what containers have run on your system. User namespaces are also implemented, but I'm not sure how well tested they are. Solving the problem of using, and creating large full OS images is quite difficult. As a stepping stone we have also created a tool which scans container images on our Quay.io registry looking for images effected by CVEs. This should hopefully help until we can properly solve creating functional minimal containers easily, but that's unfortunately not quite as easy as just telling people to use buildroot (you still need a way to update those images and know when apps need have security updates). Hope this helps.
- eropple 11y ago
  > Have you considered using rkt as an alternative to docker? I have, and I respect it a lot more--and CoreOS in general has struck me for quite some time as being the adults in the room in this space, I think the value prop remains very shaky but I appreciate that CoreOS seems to give a damn--but I don't have a lot of use for rkt in general. The only place I have any multi-tenancy, I'm using FreeBSD and jails. (I'd like to use Illumos or OpenIndiana, as I better understand that stack than I do FreeBSD, but cperciva has done a great job with FreeBSD AMIs on AWS and I don't have the bandwidth to maintain an OpenIndiana AMI.)
  - jzelinskie 11y ago
    Have you taken a look at jetpack[0]? Jetpack is an implementation of the appc specification, just like rkt, but is intended for use on FreeBSD. [0]: https://github.com/3ofcoins/jetpack https://github.com/3ofcoins/jetpack

mbreese 11y ago

Don't you need root access to even start the container? I think that's there is a disconnect here. There is a difference between running a container as root and the process w/in the container running as root. Sure, you don't need to have the process running as root in the container, but you need to have root-equivalent access to start the container. For a (large) subset of use-cases, this just isn't an option. I should be able to allow any given user of a system the ability to start a docker container and be confident that they won't be able to break the host system. Until this is the case, you don't have security in Docker.

davexunit 11y ago
The key is user namespaces. Unprivileged users can create containers easily via user namespaces. Once the user creates a user namespace, they have root in that namespace and are free to unshare the rest of the namespaces. This is how I wrote 'guix environment --container'[0], a tool for creating isolated development environments using the GNU Guix package manager. The big caveat is that unprivileged users do not setuid/setgid capability, so the number of uids/gids in the container is limited to 1, but I believe that even this is being dealt with in Linux now. [0] https://gnu.org/software/guix/manual/html_node/Invoking-guix-environment.html#Invoking-guix-environment https://gnu.org/software/guix/manual/html_node/Invoking-guix...
ewindisch 11y ago
You also need to be root to manage your init process and in production, this is how Docker is treated. That said, I've seen work being done to add RBAC, given there are a set of users that desire this.