3 ms·

If there's basically no security, it would be more honest to do away with the "docker" group and just say that you need to give root to all docker users.

woodrowbarlow 2y ago
this is why, when you install docker, it doesn't add any users to the group automatically. it's an extra "post-installation step" listed in the documentation, with a big warning flag explaining that this is effectively equivalent to handing out root. https://docs.docker.com/engine/install/linux-postinstall/ https://docs.docker.com/engine/install/linux-postinstall/
slayerjain 2y ago
I think this is the reason docker on linux requires appending sudo to the command by default. Creating a docker group and adding the user to the docker group to avoid sudo is more of a convenience thing, and the implication seems to be well documented now - https://docs.docker.com/engine/install/linux-postinstall/ https://docs.docker.com/engine/install/linux-postinstall/ so if someone sacrificed convenience over security, I think the authors can't do much. Also I think there's no such thing as secure vs non-secure product, instead its levels of security.
- slayerjain 2y ago
  Thanks to who ever upvoted my comment. Someone had downvoted me (╥﹏╥)
dathinab 2y ago
It is for me also still a irritating wonder why most Linux distros ship docker like they do (which often doesn't include the docker group but sets it up in a way where it's likely users end up using it, and security warnings related to it are often more then lacking). I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Also if you care you probably want to combine rootless (or non-rootless but still user namespace using) docker with a linux secure module setup like SELinux, as it can make security vulnerabilities in rootless docker (and well docker in general) much harder to exploit.
- akdev1l 2y ago
  > I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Upstream doesn’t support that configuration as default and it will likely break all the docker tutorials online that assume a rootful daemon. (A quick example: google “Jenkins docker integration” and it will likely tell you to pass through the docker socket) Hence package maintainers don’t want to take the burden of maintaining that.
  - dathinab 2y ago
    But exactly that is the issue especially something like Jenkins shouldn't use the default docker setup, but one of the multiple ways it can be hardened (mainly rootfull using user namespaces or rootless using user namespaces). also to quote that documentation: > By default, the Docker Pipeline plugin will communicate with a local Docker daemon, typically accessed through docker.sock. which means that iff they do it right it will just work frictionless. Rootless docker still has a local socket and in a proper setup $DOCKER_HOST is used to point to it. $DOCKER_HOST is used the docker command, and any other application which communicates with the docker socket instead MUST handle it or it's a pretty big bug even in the absence of rootless. And again you don't need rootless, you can also configure user namespaces with rootfull docker. Which isn't fixing all issues for all use cases, but fixes the ones which are an security issue for Jenkins. In general the only place where a default docker setup can be security wise acceptable is where it's acceptable to always explicitly use sudo, e.g. no developer setup. Which mainly leaves use cases like using it for long running manual managed services, but then using podman instrumented through systemd (systemd directly supports OCI images as services) is still most times preferable.
akdev1l 2y ago
Or just use podman or any other rootless container runtime

woodrowbarlow 2y ago

this is why, when you install docker, it doesn't add any users to the group automatically. it's an extra "post-installation step" listed in the documentation, with a big warning flag explaining that this is effectively equivalent to handing out root. https://docs.docker.com/engine/install/linux-postinstall/ https://docs.docker.com/engine/install/linux-postinstall/

slayerjain 2y ago

I think this is the reason docker on linux requires appending sudo to the command by default. Creating a docker group and adding the user to the docker group to avoid sudo is more of a convenience thing, and the implication seems to be well documented now - https://docs.docker.com/engine/install/linux-postinstall/ https://docs.docker.com/engine/install/linux-postinstall/ so if someone sacrificed convenience over security, I think the authors can't do much. Also I think there's no such thing as secure vs non-secure product, instead its levels of security.

slayerjain 2y ago
Thanks to who ever upvoted my comment. Someone had downvoted me (╥﹏╥)

dathinab 2y ago

It is for me also still a irritating wonder why most Linux distros ship docker like they do (which often doesn't include the docker group but sets it up in a way where it's likely users end up using it, and security warnings related to it are often more then lacking). I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Also if you care you probably want to combine rootless (or non-rootless but still user namespace using) docker with a linux secure module setup like SELinux, as it can make security vulnerabilities in rootless docker (and well docker in general) much harder to exploit.

akdev1l 2y ago
> I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups). Upstream doesn’t support that configuration as default and it will likely break all the docker tutorials online that assume a rootful daemon. (A quick example: google “Jenkins docker integration” and it will likely tell you to pass through the docker socket) Hence package maintainers don’t want to take the burden of maintaining that.
- dathinab 2y ago
  But exactly that is the issue especially something like Jenkins shouldn't use the default docker setup, but one of the multiple ways it can be hardened (mainly rootfull using user namespaces or rootless using user namespaces). also to quote that documentation: > By default, the Docker Pipeline plugin will communicate with a local Docker daemon, typically accessed through docker.sock. which means that iff they do it right it will just work frictionless. Rootless docker still has a local socket and in a proper setup $DOCKER_HOST is used to point to it. $DOCKER_HOST is used the docker command, and any other application which communicates with the docker socket instead MUST handle it or it's a pretty big bug even in the absence of rootless. And again you don't need rootless, you can also configure user namespaces with rootfull docker. Which isn't fixing all issues for all use cases, but fixes the ones which are an security issue for Jenkins. In general the only place where a default docker setup can be security wise acceptable is where it's acceptable to always explicitly use sudo, e.g. no developer setup. Which mainly leaves use cases like using it for long running manual managed services, but then using podman instrumented through systemd (systemd directly supports OCI images as services) is still most times preferable.

akdev1l 2y ago

Or just use podman or any other rootless container runtime