Should not give access to the host's Docker socket

[aschrijver]

I came upon your cool project via HN, but at the same time there was another Hacker News thread running the front page: Host Your Blog on DigitalOcean with Docker, Nginx ....

The top comment here, by @cyphar , who warned strongly against giving access to the host's Docker socket:

volumes: - /var/run/docker.sock:/var/run/docker.sock:ro

Please for the love of all that is holy, do not ever do this! Giving access to the host's Docker socket is equivalent to giving a container unrestricted root access to your host. Mounting the socket read-only doesn't protect you in any way either, because you can still connect to and write to the socket! Seriously, try it:

% touch /tmp/docker.sock
% mount --bind -o ro /var/run/docker.sock /tmp/docker.sock # this is -v /var/run/docker.sock:/foo:ro
% docker -H unix:///tmp/docker.sock run --privileged -v /:/host -it ubuntu bash
# # I couldn't write to it, but I can connect and write to the connection...
# cat /host/etc/shadow # whoops!

(The full container escape is left as an exercise for the reader. It's pretty trivial though.)

To be fair, there are unix-like DAC controls that do restrict this somewhat but given that most people run containers as root or they don't use user namespaces this is still an issue.

Please stop doing this, please stop telling people to do this, and please stop making images that access docker.sock. I understand that this is something that a lot of people do, so it's obviously not exclusively the fault of the author for doing what the majority of people appear to be doing, but I think that this deserves to be said much stronger than it was in the past (people still expose Docker over the internet -- which is literally a free root-level RCE for anyone who figures out you're hosting it).

And yes, AuthZ plugins exist but nobody really uses them as far as I'm aware -- and personally (as someone who maintains container runtimes and other low-level container tools) I would not feel confident in depending on any AuthZ plugin's profile to protect against a container escape where you give unprivileged users access to /var/run/docker.sock. Even if I were to write one.

I am not the expert on the issue, but it may be worthwhile to investigate the implications more closely.

[SteveLTN]

That's certainly a valid point. I know you could have security issues if you share the docker socket.

Unfortunately this feature is requested by a lot though, I don't think it is wise to just remove this functionality.

But I would add STRONG WARNINGS in that section of documentation and in console to discourage people from doing that, or at least ask them to verify the source code before doing so.

Thank you for you advice!

[aschrijver]

There's is good sources of information around. I found the article below, which you could maybe refer to in the README:

https://dev.to/petermbenjamin/docker-security-best-practices-45ih

[cyphar]

I think a really important takeaway is that the :ro doesn't actually add any protection (and adding it wouldn't make much sense if it did -- the protocol used is HTTP so if you couldn't write then you couldn't use the socket for anything). But 👍 to having a all-caps warning in the documentation around this section. Preferably with <blink> tags if GitHub markdown supports them. 😸

[SteveLTN]

@cyphar You are right. I should stress that the :ro doesn't make the docker api read-only in the docs as well.

[aschrijver]

I have no time to look at it closer now (got to go), but this SO answer hints at possible workarounds:

• https://integratedcode.us/2016/04/08/user-namespaces-sharing-the-docker-unix-socket/
• https://integratedcode.us/2016/04/20/sharing-the-docker-unix-socket-with-unprivileged-containers-redux/

Maybe it has something useful.

[SteveLTN]

I updated the documentation here, and put comments in all code examples like the following:

volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro # DANGEROUS, see the warning above

Closing this issue now.

[aschrijver]

That should be clear enough. Great!

[cyphar]

Yeah this is better.

As an aside, the linked blog post doesn't fully explain how bad it is to bind-mount the docker.sock -- it's much worse than just being able to access host files through volumes. You can escape from the container very trivially with docker.sock access. But that doesn't really change the recommendation, so just ignore my complaints. :P