This is a by design part of Docker's operation. What's perhaps a little more surprising (though it shouldn't be) is that anyone with create pod rights in a k8s cluster can do this by default on every worker node in the cluster. (unless the cluster operator or provider has implemented additional controls)

https://docs.docker.com/engine/install/linux-postinstall/

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/

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.

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.

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.

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.

then yes :)

https://docs.docker.com/engine/security/rootless/

Noteworthy alternate: podman

"Rootless containers allow you to contain privileges without compromising functionality."

Can you suggest any preferred alternative methods of isolation that offer similar efficacy and ease of use for quickly running complete software systems made by an unknown/untrusted actor?

It can. I think it's fair to assume that the standard developer setup to let them be productive is not this proper configuration.

> Can you suggest any preferred alternative methods of isolation that offer similar efficacy and ease of use for quickly running complete software systems made by an unknown/untrusted actor?

No. It's a hard problem! If it was easily solved we wouldn't be seeing all this development surrounding e.g. WebAssembly

While I agree that Docker as written isn’t good at security, your post has big “they’re holding the iPhone wrong!” vibes — and seemingly ignores the historic reasons that people would think it provides security.

More like "it just isn't meant to be used for that". At least not in the default configuration, and that's fine!

> seemingly ignores the historic reasons that people would think it provides security

I've been using docker since it was announced. People have always been very clear that docker is not a security boundary, at least not with its default configuration.

I’ve also used it since the beginning and that’s some mighty strong revisionism.

Docker was compared to VMs — with a tiny asterisk of fine print that it’s not actually configured to employ security features it’s built with.

By certain people, yes. They have always been wrong. Never by the docker team themselves.

> Disclaimer: There is no actual profit. That was just one of those clickbaity things everybody seems to like so much these days. Also, it’s not really fun. Alright, on with the show!

http://phrack.org/issues/49/1.html

It's sometimes called 'listing paper', as it was commonly used to print out listings of your code :

https://www.reddit.com/r/nostalgia/comments/noi8xm/dot_matri...

Hmm, wonder what became of my Epson MX80. Much fonder memories than the printers that came after it....

Often the holes for the tractor feed were also separated from the main part of the page by a perforation so that one could tear it off to leave a more-or-less pristine letter (or A4 over here) page of content.

Fiddling with the left-over narrow strips of hole-punched edging paper was one of those universal habits that you don't even notice until long after it's gone.

(Edit: _a_ I just realised I replied to the wrong parent post and _b_ now I'm wondering if you're somebody I know!)

As Pratchett said, "We've all passed a lot of water since those days..." :D

I remember being amazed when I discovered that there was this a system, called GNU/Linux, where everything you need was already packaged and easy to install.

Then came the Maven, npm & co.

Docker (and containers) is basically an universal package manager that was fulled by the success of open source, the arrival of a lot of new people (working on Mac and Windows) in that space and the adoption of the cloud. Docker Hub became the open source "app store".

The crime is the misleading term "container" because I bet a majority of people assume there is some security guarantee by design, what is absolutely false.

Actually container security is pretty hard and a most people don't really care because it doesn't run on their computer but in the cloud.

My guess is something like Kata containers, compatible with the container standards while leveraging hardware virtualization technology will prevail. Or a cleaner system, similar to NixOS/Guix but easier to use, will appear.

Rootless docker is still not the default choice somehow.

Podman however has been working rootlessly for a few years now, and does not suffer from many of the docker shortcomings.

Would you care to elaborate on the shortcomings? I use Docker in my home lab and have taken a couple runs at Podman but have not been highly motivated and reverted to Docker rather than fiddle with things to get my containers working. If I were aware of significant benefits for my usage, I might be inclined to keep trying. If the benefits are more relevant to enterprise or cloud environs, it probably does not matter much to me.

My use cases include Gitea (git server) which opens privileged ports inside the container that get mapped to unprivileged ports on the host and I believe that was a problem area.

Thanks!

You can either allow those ports to be mapped on your host, or you can map a higher port on the host 8000:80 or 4443:443. I did the former.

The biggest problem I have with docker other than root is that it touches the firewall for convenience. Any port you map on the host will be opened in nftables, as per the documentation[1]. Very dangerous default that few developers realize is a problem. You probably only want 80/443 open and proxy your subdomains on the host, but all ports are now exposed to the internet.

[1]: https://docs.docker.com/network/#published-ports

That rates a "Wow!" but seems like something more important to Enterprise/Cloud. It seems like it would be a Bad Thing to open a port because a DB server ran in a different container. That's not something that should be opened unless the DB is on a different host (VM) from an application that uses the DB.

In my case I have a firewall/router protecting my home LAN and don't generally run firewalls on individual hosts.

It's always a good idea to lock down everything you can and avoid unsafe defaults. If podman causes any friction there's most likely a good reason behind it. For me there are none and I've lost count of the containers I'm running.