Option to not use UID 1000 for `dind-rootless`?

[imthosea]

User 1000 is me on my server, and I'm in the sudoers file. In case of a container breakout it would be nice to be able to change the UID the docker daemon runs under to something other than UID 1000. A build arg could be put into in the dind image

[tianon]

Hmm, rather than a build arg (which would require rebuilding the existing image), we should probably put something like this into the documentation for the variant (as this is the easiest method I'm aware of to change that UID/GID):

FROM docker:dind-rootless
USER root
RUN set -eux; \
	sed -i -e 's/^rootless:1000:1000:/rootless:1234:5678:/' /etc/passwd; \
	sed -i -e 's/^rootless:1000:/:5678:/' /etc/group; \
	chown -R rootless ~rootless
USER rootless

(Also, running rootless inside a container still requires --privileged on the container, so the risk of a breakout being real bad on the host too is still high. 🙈 ❤️)

[imthosea]

I'm confused-what does

RUN set -eux; \
	sed -i -e 's/^rootless:1000:1000:/rootless:1234:5678:/' /etc/passwd; \
	sed -i -e 's/^rootless:1000:/:5678:/' /etc/group; \
	chown -R rootless ~rootless

do?
Also, I'm trying to avoid using a new Dockerfile since that wouldn't work auto updating with watchtower. Unless there's a way to have it auto rebuild on a new update?

[tianon]

Even if we had a build-arg, you'd have to rebuild the image to use it, so I'm not sure what you're hoping for here. 😅

The example I've provided changes the UID/GID of the default user in the image to a different one.

It sounds like you're trying to use this as a security boundary though, and I'm going to reiterate my caution that it probably is not as strong of a security boundary as you're hoping for (because --privileged means most of the protections of the container are removed).

[imthosea]

Unless I'm mistaken, doesn't it drop root entirely before opening the socket? So privileged would only give access to the unprivileged user on the host?

[tianon]

It does drop UID/GID to the specified non-root UID/GID, yes, but --privileged also disables all the seccomp, apparmor, etc protections of Docker, which would be applied for something like a standard SSH session, so it is strictly more privileged than the same UID/GID might have in a "normal" session on the host.