5 ms·

On Linux, at least, being able to access the docker daemon (i.e. being in the docket group) is essentially equivalent to being root, in that there are trivial w

On Linux, at least, being able to access the docker daemon (i.e. being in the docket group) is essentially equivalent to being root, in that there are trivial ways to become root if you can start an arbitrary container (e.g. bind-mounting / into a container). So, it’s perhaps unclear how this exploit is significantly worse. Yes, you get access to SYSTEM, but Docker’s permission model appears to be predominantly “if you can control Docker then you own the machine”. Is this not the case on Windows?

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
zapita 8y ago
The difference as I understand it is documentation. For Linux, the Docker docs make it abundantly clear what the security model is - don’t give access to the daemon socket to anyone you don’t trust to be root. For Windows on the other hand there seems to be no official documentation on the topic. Instead some “unofficial” documentation has popped up to fill the void, making insecure recommendations in the process. This then becomes Docker’s problem. I think it’s a good general lesson for documenting a platform: in the end you are responsible not only for what you explain to your users, but also for what they explain to each other. This can be frustrating because it makes you responsible for something you cannot control, like Docker couldn’t control the recommendations on that github thread. But you are still on the hook for addressing it - in this case probably by filling the gap in official documentation.
- tjoff 8y ago
  > This can be frustrating because it makes you responsible for something you cannot control If bad recommendations are a product of bad/non-existent documentation then that very much is something you can control and a direct consequence of that neglect. If docker couldn't be bothered the blame should not be with the bad recommendations.
deleted 8y ago
[deleted]
derefr 8y ago
If you can control Docker, you can do what Docker does. But Docker doesn’t need to be able to do everything (as long as you’re sure that you’ll never need to run a container that needs to do those things.) Specifically, you can run the Docker daemon itself under any combination of cgroup+namespace restrictions (i.e. “in a container”, though not usually in the sense of running Docker in Docker.)
- fulafel 8y ago
  Sadly, many docker images you might want to try fail when run under Docker running in a unprivileged container.
- TheDong 8y ago
  > you can run the Docker daemon itself under any combination of cgroup+namespace restrictions Not really though. The docker daemon needs access to the mount call, so it either must be root or root within its namespace. It's incredibly difficult to remove any meaningful permissions from the docker daemon. This is true to run any container, not just one that has bindmounts. The docker daemon was not built to be anything but root, and running it as "docker in docker" only works with "--privileged", which is to say, with no security restrictions.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

zapita 8y ago

The difference as I understand it is documentation. For Linux, the Docker docs make it abundantly clear what the security model is - don’t give access to the daemon socket to anyone you don’t trust to be root. For Windows on the other hand there seems to be no official documentation on the topic. Instead some “unofficial” documentation has popped up to fill the void, making insecure recommendations in the process. This then becomes Docker’s problem. I think it’s a good general lesson for documenting a platform: in the end you are responsible not only for what you explain to your users, but also for what they explain to each other. This can be frustrating because it makes you responsible for something you cannot control, like Docker couldn’t control the recommendations on that github thread. But you are still on the hook for addressing it - in this case probably by filling the gap in official documentation.

tjoff 8y ago
> This can be frustrating because it makes you responsible for something you cannot control If bad recommendations are a product of bad/non-existent documentation then that very much is something you can control and a direct consequence of that neglect. If docker couldn't be bothered the blame should not be with the bad recommendations.

deleted 8y ago

[deleted]

derefr 8y ago

If you can control Docker, you can do what Docker does. But Docker doesn’t need to be able to do everything (as long as you’re sure that you’ll never need to run a container that needs to do those things.) Specifically, you can run the Docker daemon itself under any combination of cgroup+namespace restrictions (i.e. “in a container”, though not usually in the sense of running Docker in Docker.)

fulafel 8y ago
Sadly, many docker images you might want to try fail when run under Docker running in a unprivileged container.
TheDong 8y ago
> you can run the Docker daemon itself under any combination of cgroup+namespace restrictions Not really though. The docker daemon needs access to the mount call, so it either must be root or root within its namespace. It's incredibly difficult to remove any meaningful permissions from the docker daemon. This is true to run any container, not just one that has bindmounts. The docker daemon was not built to be anything but root, and running it as "docker in docker" only works with "--privileged", which is to say, with no security restrictions.