4 ms·
I think we'll see more security incidents involving Docker in the future as it becomes more popular. I have worked with it for a few months now and I can alread
by ThePhysicist 11y ago
I think we'll see more security incidents involving Docker in the future as it becomes more popular. I have worked with it for a few months now and I can already see a few attack vectors that could easily be exploited if the corresponding Docker features are not used properly.
For example, as Docker can by default mount anything that root can mount, running
docker run -i --volume=/:/data -t ubuntu
will give you complete root access to your file system in the docker container (the talk mentions some Docker features that will mitigate this kind of attacks, notably UID mapping). Of course no one would willingly do that, but if you mount user resources into your containers and the resource name contains something that an external user might control (e.g. his/her username), then injection attacks become possible. Even with UID mapping enabled this can leak sensitive information about your host system into the container. And since people often use containers to run untrusted code (e.g. for CI systems), this can be a large security threat in my opinion.
Personally I really like Docker and I think it (or similar technologies) will change many aspects of IT/Devops/Data Analysis in the future, I just think that maybe they should have some more sensible defaults for security-relevant settings, i.e. only grant network access to containers if you ask for it, restrict default memory usage by default, limit the type of volumes you can mount, etc.
- fpoling 11y agoMy problem with Docker is that although the advise was always not to run images with root, in practice all Docker tools defaults to do precisely that and there are no plans to change the defaults. At least these days they do provide options to restrict containers so secure usage is possible (--cap-drop=all is a good start), but still the amount of efforts to follow good security practices is high.
- b1661727 11y agoYes, this has been my experience as well. It's either add your user to the docker group (which makes it equivalent to a root account) or run everything docker related with sudo. Your best bet is to run docker in it's own virtual machine which is somewhat ironic.
- raesene4 11y agoWith 1.10 you can just enable User namespaces, which allows for root in a container to map to a non-privileged user outside the container, that way it's a one-time (per instance) change.
- mbreese 11y agoWhile this is a nice security boost once you're in the container, don't you still need to be root (docker group) in order to start the container? It honestly doesn't help me much if I have to give users root in order to start a container, even if they are wrapped inside the container.
- raesene4 11y agoYep, at the moment, with raw docker engine, if a user has access to create containers, they're basically able to get root on the box, as the docker daemon runs as root and there isn't any authorization control by default, so it doesn't work well for that kind of scenario. With that said there's a couple of ways this is getting addressed. 1) in 1.10 authorization plugins landed as a feature,so it's possible to add this functionality. 2) there's a number of services which run on top of Docker Engine (e.g. Docker Universal Control Plane) which have authentication/authorisation at that level.
- cuckcuckspruce 11y agoThis is what sudo is for. Give each user access to run their containers (and only their containers) as a member of the docker group in sudoers.