11

My team has been getting pretty excited about using docker because it promises to simplify our deployments and provide a number of other design and operational benefits. We recently started to really get things rolling with it and ran into some issues with the fact that the docker daemon runs as root.

In general, my stance on running server platforms as root is "don't". We recently went through a bunch of battles to get our operators to stop doing this and to even stop running things under accounts that can modify the server deployment. So right off the bat, I have problem here that it seems a little hypocritical to go back to these same people and ask them to set up docker to run as root.

I'm not the first to comment on risks posed by the docker daemon running as root. According to this "Eventually, it is expected that the Docker daemon will run restricted privileges, ..." Should we just wait for this to be addressed? I thought docker would improve our security profile but this seems to make it worse. My enthusiasm has been deflated for docker and I'm not sure I am motivated to make a case for using it in this state to our risk team.

EDIT: I should clarify that I'm not specifically concerned here with the issues around users being members of the "docker" group. It's important to know about but that can be managed. I really appreciate all the great answers here (both pro and con). I think I've been conflating the daemon with the containers themselves. I probably need to work on a clarified mental model of the docker architecture. Again lots of great stuff here all around. I'll have to ruminate a bit before accepting an answer.

Am I wrong to think this is a major flaw with docker?

  • I think that you're overly paranoid. The docker daemon cannot be accessed remotely unless you explicitly enable that. Otherwise it can only be accessed by first rooting the physical machine, at which point containers are at stake anyway (you have bigger things to worry about then). From the point of view of a container, it doesn't matter whether the docker daemon runs as root, first of all they are isolated (as if a different machine), and also the kernel always "runs as root", too. – Damon Oct 9 '15 at 22:13
  • In addition to what Damon wrote, there should be good defense in depth in practice. If the security of the entire system will crumble just because the Docker daemon is running as root and successfully exploited, then there are more important things to focus on. I don't think there is a yes/no answer to this question but I would suggest putting together a threat model if you haven't already to understand what is the risk of Docker running as root in your environment. Not to sound cliche but if you can achieve a huge win for your business and this risk is low for your environment, roll with it. – user79331 Oct 10 '15 at 4:15
  • I'm not sure I understand your statement "If the security of the entire system will crumble just because [X] is running as root and successfully exploited." When an application that is running as root is exploited, the chance that exploiter can take control of the system is increased. I don't think this is something to take lightly. – JimmyJames Oct 19 '15 at 15:17
6

The docker daemon does run as root, as it interfaces with the host operating system in a farily fundamental manner, however that's no different than most/any system daemon that makes use of linux capabilities which require that privilege.

This doesn't mean that using docker is insecure, just that you need to be careful with how you use it. Luckily there is already some fairly good security configuration advice available on this from Docker themselves and in the form of a security configuration "best practices" guide from the Center for Internet Security

A couple of practical considerations which you do need to be aware of when running docker.

First up is that if someone is a member of the "docker" group on the host, they're effectively root on the system as it's possible to use docker to escalate privileges in this case. So you need to treat membership of that group on production hosts with care.

Docker uses Linux capabilities to restrict what actions a user inside a container can take, so just being root inside a container doesn't necessarily mean automatic root on the host. That said you do need to be careful with things like volume mounts (so if you mount a system directory from the host into a container for example) as this can allow a root user inside a container to make changes to files on the host.

You can also reduce the capabilities provided to a container fairly easily, which can improve the security of the process further.

Also remember you don't need to run processes in containers as root, you can run as other users with a bit of configuration, and this mitigates the volume mounting risk.

I find that the way to think about containers is as processes on the host. If you compare running things in containers to running them directly on the host, I'd say that the container architecture is likely to add security rather than remove it, as you've got a better defined interface between the process and the host and more control over what the process can do on the host.

Also it's worth nothing that a richer user mapping architecture is coming fairly soon to docker (planned for 1.9) which will add some more options for restricting actions in a container.

  • "I find that the way to think about containers is as processes on the host. If you compare running things in containers to running them directly on the host, I'd say that the container architecture is likely to add security rather than remove it..." That's a really good way of putting it. I might add that while containers might not have quite the security separation from a host as a VM does, one can always run containers inside a VM for scenarios that require stronger security promises. The Docker documentation describes a basic Virtualbox set-up: docs.docker.com/machine/get-started – mostlyinformed Oct 10 '15 at 18:57
  • 1
    "however that's no different than most/any system daemon that makes use of linux capabilities which require that privilege". It does not require it. It is the very same thing I reproach to libvirt and Docker: Linux makes things to nicely meet the least privilege axiom: one does not need root privileges to run a virtual machine or a sandboxed environment. However, for historical reasons and because it makes things easier for developers and end-user by avoiding any privilege issue, these layers requires root privileges on the host system. Convenient? Yes. Secure? No. – WhiteWinterWolf Oct 12 '15 at 7:29
  • 1
    @WhiteWinterWolf to clarify are you thinking that the docker daemon shouldn't need root or that containers that it instantiates shouldn't? My thinking is that the docker daemon does as it'll set up things like new bridges/IPtables rules etc to set-up a container which I would think of as privileged operations. Containers running as root is a different prospect and I'd agree (as would docker as they're implementing user namespacing) – Rоry McCune Oct 12 '15 at 20:19
  • 1
    I hope for Docker that compatibility with user namespacing will be really available for 1.9 since, as I said in my answer, this feature has been postponed several times since it becomes available in LXC. Qemu, for instance, provides a minimal very small SUID utility (runnable only by Qemu group members) which transparently takes in charge bridges creation/deletion. Apart from that all the rest is running as end-user, which reduces the attack surface compared to a root daemon. Maybe in a future version Docker will be able to completely drop root privileges, but I fear this may not be soon. – WhiteWinterWolf Oct 13 '15 at 9:53
  • @WhiteWinterWolf it got committed to master over the weekend and as that's before the 1.9 feature freeze date yesterday, it looks probable to have made the cut for this version (absent problems in test I'd guess) (The commit is here github.com/docker/docker/commit/…) and the pull request is linked from that. – Rоry McCune Oct 13 '15 at 10:32
5

No, you aren't.

Or, put it another way, if you are mistaken to be concerned, there are a lot of security experts who are similarly mistaken. Just to take a few prominent examples:

-The experts interviewed here about Docker security, and specifically about the daemon root issue. Including a guy from CERT:

Yes, that's right, Docker, and many other container technologies, need root access to do their magic. And, like any other program that needs root access, with great power comes great opportunities to wreak havoc.

As Aaron Cois, a researcher at CERT at Carnegie Mellon University recently told the DevOps publication, "One of the biggest threats I see with Docker is its positioning and the implied security in the language. The reality is that these containers don’t contain anything." With root access that's indeed the case.

Also, running anything with root privileges within the container apparently is problematic "A process running as root (UID 0) in a container has root-level privileges on the underlying host when interacting with the kernel."

That piece provides a good bit more about the specifics of issues related to the daemon's root status in particular, and a good overview of the security issues that are a little worrisome with Docker in general.

-Here's a really good analysis from a team that talks about a number of security issues regarding Docker, including some directly related to the daemon-as-root architecture, and how to combat/mitigate them. The presenters here offer a mixed-to-somewhat positive view of Docker security in general, but they make it clear there are a number of possible threat-vectors that have to be on one's mind when creating a set-up.

You get the point, I think. (Google reveals plenty more pieces articulating those points, and I've personally read a few others here and there over the past year or so.) Now, I'm not bashing Docker by any stretch of the imagination, and it seems like if your careful in how you set up and maintain things you can greatly reduce the threats that Docker's less-than-rock-solid security architecture allows to exist, including deamon-as-root. (And certainly containers are easy & convenient to use as all-get-out.) But you are definitely, certainly not wrong to have some concerns about Docker not using a good, modern approach that includes maximum reasonable privilege-reduction (as Docker stands today, at least).

  • Thanks for your comments. I accepted the answer above mainly because it helped disabuse me of the notion that because the docker daemon runs under root that the containers also run under root. I see now that these are separate concerns. They are still concerns, though, and we are now researching how to secure the containers properly. – JimmyJames Oct 19 '15 at 15:23
4

The article from Daniel Walsh, leader of the RHEL Docker enablement team (so not the kind of guy who would have any reason to fight against Docker), about Docker security is also interesting. One of the key thought is that one must "just assume that privileged processes running within the container are the same as privileged processes running outside of the container.".

This is a relatively old article, July 2014. Linux containers (on which relies Docker) have evolved and in January 2014 they introduced unprivileged containers ensuring that privileged process inside the container are now running with end-users privileges from the host system point-of-view.

However, this feature is still not supported in Docker and was postponed several times.

In another answer pertaining to Docker security I also mentioned several other security oriented projects which were relying on Docker before leaving it due to security issues.

So, as you said, Docker "promises to simplify our deployments and provide a number of other design and operational benefits", this is certainly true and seems to be the main goal for Docker, but as Daniel Walsh highlighted it security through isolation is not a part of these promises.

As often there is a compromise to be found between security and functionality. Docker seems to position itself on the functionality side of the ladder. It's up to you decide if the value added by Docker features worth it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.