3 ms·

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 wa

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

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