5 ms·

> 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 sock

by cyphar 8y ago

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

mistrial9 8y ago
great tip - but nothing to do with 'holy' .. thx
- cyphar 8y ago
  It's a common idiom. https://idioms.thefreedictionary.com/for+the+love+of https://idioms.thefreedictionary.com/for+the+love+of
benatkin 8y ago
This is where it comes from and that's probably why it isn't explained in the post: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa... It seems like if the author(s) of docker-letsencrypt-nginx-proxy-companion had assumed something like docker compose or kubernetes that neatly handles sharing volumes between containers, they probably wouldn't have made the mistake of giving a docker container access to docker for such a trivial use. I disagree that there's never a good reason to do this though. A docker control panel, or a CI or FaaS that spawns docker containers, can be a good reason to do this. https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-d... BTW there's no escaping the container when you're doing this intentionally.
- cyphar 8y ago
  > I disagree that there's never a good reason to do this though. The number of cases where it is an acceptable idea to do this (compared to the number of cases where people do this because they read it on a random blog post) is so small that it is statistically insignificant. In my view, it is much better to tell people to never do something which is very rarely useful. People who know better would know when to ignore that warning (which I would hope would be the sort of people who would write a CI or FaaS), while those who don't know better likely wouldn't use it in a way that is "safe". The blog post you link to is quite old (this was at a time when most users were well aware of what docker.sock did -- so much so that vulnerabilities I helped find in Docker from that time were not regarded vulnerabilities because they required docker.sock access!). I agree with Jerome's point which was to dissuade usage of Docker-in-Docker. His point was not that bind-mounting the docker.sock is generally an okay thing to do -- and as I said I think that we should be far more vocal about how dangerous this is (because people don't listen otherwise -- as has been shown by the fact that there are still plenty of users that have Docker listening on a TCP socket without client certificates). > BTW there's no escaping the container when you're doing this intentionally. I don't know what you mean by this -- if you bind-mount the docker.sock inside a container that container can trivially get root access on the host (AuthZ plugins can make it harder but as I said they are rarely used and cannot protect you from sufficiently clever attackers). My demo with 'mount --bind' was just to show how it worked, the same thing happens with '-v' (which is just a bind-mount under the hood). Now, if you argue that the code in the container is always something you trust (which I think is a questionable assumption as it assumes that your code is not exploitable) then sure -- if all the code on your machine is safe you have no worries. But then the obvious question arises -- why do you need the isolation properties of containers in the first place? Why not just run in a chroot?
sneak 8y ago
> people still expose Docker over the internet -- which is literally a free root-level RCE for anyone who figures out you're hosting it By default, docker-machine (which sets up internet-accessible docker instances) uses TLS client certificates, so no, this does not give a "free root-level RCE". This is just spreading FUD. (This does not detract from the parent's point that "access to docker.sock" == "root on the host". That part is true.)
- cyphar 8y ago
  I was not referring to docker-machine here, I'm not sure why you think I was referring to it (I didn't even mention it). I was talking about people who do `dockerd -H tcp://:8080` and ignore the warning that tells them this is insecure. This is not a strawman, there were blog posts in the past few months where they mentioned in passing that their firewall was misconfigured and allowed unauthenticated access to their Docker hosts[1]. I didn't mention TLS certificates with -H tcp:// because it wasn't really related to the main point I was making -- yes you can configure it to be secure but again security is not the default. I felt so strongly about this I pushed for having a required flag to allow insecure TCP access[2]. I am more than aware this can be done safely, it just isn't done safely often enough that you see this type of misconfiguration in blog posts. [1]: https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers https://kromtech.com/blog/security-center/cryptojacking-inva... [2]: https://github.com/moby/moby/pull/37299 https://github.com/moby/moby/pull/37299
  - sneak 8y ago
    Security with client certificates is the default using the vendor-supplied tooling for bringing up remote docket hosts, docker-machine. This is why I brought it up. It’s not some 3p whatever, this is the vendor’s tooling and it is not insecure by default.
roland-s 8y ago
Socket exposure can be avoided by running jwilder's nginx and docker-gen containers separately as explained in his repo (you still bind to tthe docker socket but on a separate unexposed local container): https://github.com/jwilder/nginx-proxy/blob/master/README.md#separate-containers https://github.com/jwilder/nginx-proxy/blob/master/README.md...
carlopellegrini 8y ago
I was a bit worried too about exposing the docker socket, even to a well trusted image and even if it seems it'a a widely adopted practice for such automatic configurations. Fortunately ducaale suggested https://hub.docker.com/r/steveltn/https-portal/ https://hub.docker.com/r/steveltn/https-portal/. I adapted the site and will publish a follow-up about using this image for nginx - let's encrypt configuration.
- carlopellegrini 8y ago
  Here the follow-up: https://www.archij.com/improving-the-blog-security/ https://www.archij.com/improving-the-blog-security/

by cyphar 8y ago

mistrial9 8y ago

great tip - but nothing to do with 'holy' .. thx

cyphar 8y ago
It's a common idiom. https://idioms.thefreedictionary.com/for+the+love+of https://idioms.thefreedictionary.com/for+the+love+of

benatkin 8y ago

This is where it comes from and that's probably why it isn't explained in the post: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa... It seems like if the author(s) of docker-letsencrypt-nginx-proxy-companion had assumed something like docker compose or kubernetes that neatly handles sharing volumes between containers, they probably wouldn't have made the mistake of giving a docker container access to docker for such a trivial use. I disagree that there's never a good reason to do this though. A docker control panel, or a CI or FaaS that spawns docker containers, can be a good reason to do this. https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-d... BTW there's no escaping the container when you're doing this intentionally.

cyphar 8y ago
> I disagree that there's never a good reason to do this though. The number of cases where it is an acceptable idea to do this (compared to the number of cases where people do this because they read it on a random blog post) is so small that it is statistically insignificant. In my view, it is much better to tell people to never do something which is very rarely useful. People who know better would know when to ignore that warning (which I would hope would be the sort of people who would write a CI or FaaS), while those who don't know better likely wouldn't use it in a way that is "safe". The blog post you link to is quite old (this was at a time when most users were well aware of what docker.sock did -- so much so that vulnerabilities I helped find in Docker from that time were not regarded vulnerabilities because they required docker.sock access!). I agree with Jerome's point which was to dissuade usage of Docker-in-Docker. His point was not that bind-mounting the docker.sock is generally an okay thing to do -- and as I said I think that we should be far more vocal about how dangerous this is (because people don't listen otherwise -- as has been shown by the fact that there are still plenty of users that have Docker listening on a TCP socket without client certificates). > BTW there's no escaping the container when you're doing this intentionally. I don't know what you mean by this -- if you bind-mount the docker.sock inside a container that container can trivially get root access on the host (AuthZ plugins can make it harder but as I said they are rarely used and cannot protect you from sufficiently clever attackers). My demo with 'mount --bind' was just to show how it worked, the same thing happens with '-v' (which is just a bind-mount under the hood). Now, if you argue that the code in the container is always something you trust (which I think is a questionable assumption as it assumes that your code is not exploitable) then sure -- if all the code on your machine is safe you have no worries. But then the obvious question arises -- why do you need the isolation properties of containers in the first place? Why not just run in a chroot?

sneak 8y ago

> people still expose Docker over the internet -- which is literally a free root-level RCE for anyone who figures out you're hosting it By default, docker-machine (which sets up internet-accessible docker instances) uses TLS client certificates, so no, this does not give a "free root-level RCE". This is just spreading FUD. (This does not detract from the parent's point that "access to docker.sock" == "root on the host". That part is true.)

cyphar 8y ago
I was not referring to docker-machine here, I'm not sure why you think I was referring to it (I didn't even mention it). I was talking about people who do `dockerd -H tcp://:8080` and ignore the warning that tells them this is insecure. This is not a strawman, there were blog posts in the past few months where they mentioned in passing that their firewall was misconfigured and allowed unauthenticated access to their Docker hosts[1]. I didn't mention TLS certificates with -H tcp:// because it wasn't really related to the main point I was making -- yes you can configure it to be secure but again security is not the default. I felt so strongly about this I pushed for having a required flag to allow insecure TCP access[2]. I am more than aware this can be done safely, it just isn't done safely often enough that you see this type of misconfiguration in blog posts. [1]: https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers https://kromtech.com/blog/security-center/cryptojacking-inva... [2]: https://github.com/moby/moby/pull/37299 https://github.com/moby/moby/pull/37299
- sneak 8y ago
  Security with client certificates is the default using the vendor-supplied tooling for bringing up remote docket hosts, docker-machine. This is why I brought it up. It’s not some 3p whatever, this is the vendor’s tooling and it is not insecure by default.

roland-s 8y ago

Socket exposure can be avoided by running jwilder's nginx and docker-gen containers separately as explained in his repo (you still bind to tthe docker socket but on a separate unexposed local container): https://github.com/jwilder/nginx-proxy/blob/master/README.md#separate-containers https://github.com/jwilder/nginx-proxy/blob/master/README.md...

carlopellegrini 8y ago

I was a bit worried too about exposing the docker socket, even to a well trusted image and even if it seems it'a a widely adopted practice for such automatic configurations. Fortunately ducaale suggested https://hub.docker.com/r/steveltn/https-portal/ https://hub.docker.com/r/steveltn/https-portal/. I adapted the site and will publish a follow-up about using this image for nginx - let's encrypt configuration.

carlopellegrini 8y ago
Here the follow-up: https://www.archij.com/improving-the-blog-security/ https://www.archij.com/improving-the-blog-security/