4 ms·

The lack of user namespaces in Docker is just crazy. People talk about them being insecure, but what is more secure about running all of your containers as the

The lack of user namespaces in Docker is just crazy. People talk about them being insecure, but what is more secure about running all of your containers as the root user? Docker's security story is consistently lacking, it's like they actively try to do the worst thing possible.

eropple 11y ago
It's not the worst thing in the world, because a competent administrator/infrastructure engineer who's comfortable with the underlying tools can account for this and mitigate it. That said, Docker markets consciously and directly to people who are not competent, with an undercurrent of "you don't need competent people to use this!". And, as in most computer-y cases, it's not the fault of the incompetent and the ignorant that they trust the providers of tools; implicit in actually providing them is that they are generally safe with the defaults that are given. Which in Docker's case they're emphatically not. That hurts people, and very little gets me saltier than hurting people unnecessarily. (I haven't ruled out that it might be a lack of a culture of security, too, on the Docker team's part; there was that whole "oh, yeah, put desktop applications in Docker containers, never mind that now you're running Chrome as root and putting the unprivileged X socket in the container, letting it pump messages to any other application" thing from a Docker core contributor. Maybe they just don't know, themselves? Woof.)
antocv 11y ago
Nobody gives a tiny shit about security, see for example LetsEncrypt as well -- including some stupid "automation" which runs as root, wtf? Very dissapointing.
ewindisch 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. 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.
raesene4 11y ago
FWIW user namespacing is already available in docker experimental and will hopefully be getting into mainstream soon...
shykes 11y ago
Hi, Seccomp and user namespaces are in the Docker experimental build (https://docker.com/experimental https://docker.com/experimental) and should land in 1.10. Docker 1.9 supports all other namespaces, cgroups, pivot_root, cap drop, selinux, apparmor, uid/gid drop. You can also sign and verify all images with a built-in Notary/TUF implementation, and we partnered with Yubico to support hardware signing out of the box. I'm hoping we can make image signing the default in the near future, and make it mandatory within the year. At this point I'm comfortable saying Docker's security story is strong (although not perfect of course). But if you have specific suggestions for improvements we are interested! EDIT I got it wrong userns is still experimental and will land in 1.10

eropple 11y ago

It's not the worst thing in the world, because a competent administrator/infrastructure engineer who's comfortable with the underlying tools can account for this and mitigate it. That said, Docker markets consciously and directly to people who are not competent, with an undercurrent of "you don't need competent people to use this!". And, as in most computer-y cases, it's not the fault of the incompetent and the ignorant that they trust the providers of tools; implicit in actually providing them is that they are generally safe with the defaults that are given. Which in Docker's case they're emphatically not. That hurts people, and very little gets me saltier than hurting people unnecessarily. (I haven't ruled out that it might be a lack of a culture of security, too, on the Docker team's part; there was that whole "oh, yeah, put desktop applications in Docker containers, never mind that now you're running Chrome as root and putting the unprivileged X socket in the container, letting it pump messages to any other application" thing from a Docker core contributor. Maybe they just don't know, themselves? Woof.)

antocv 11y ago

Nobody gives a tiny shit about security, see for example LetsEncrypt as well -- including some stupid "automation" which runs as root, wtf? Very dissapointing.

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

raesene4 11y ago

FWIW user namespacing is already available in docker experimental and will hopefully be getting into mainstream soon...

shykes 11y ago

Hi, Seccomp and user namespaces are in the Docker experimental build (https://docker.com/experimental https://docker.com/experimental) and should land in 1.10. Docker 1.9 supports all other namespaces, cgroups, pivot_root, cap drop, selinux, apparmor, uid/gid drop. You can also sign and verify all images with a built-in Notary/TUF implementation, and we partnered with Yubico to support hardware signing out of the box. I'm hoping we can make image signing the default in the near future, and make it mandatory within the year. At this point I'm comfortable saying Docker's security story is strong (although not perfect of course). But if you have specific suggestions for improvements we are interested! EDIT I got it wrong userns is still experimental and will land in 1.10