Hacker News new | past | comments | ask | show | jobs | submit login

I would recommend using Rootless Docker over this cheat sheet. It makes half the issues they are trying to work around redundant. It also solves the issue with Docker punching a hole through UFW..

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




Some of the points in TFA are fixes to be done in the Dockerfile, meaning that any user of the Docker image would benefit, not just those who run rootless Docker.


What are the trade offs of using rootless?


Your host OS has to allow for unprivileged user namespaces, which can add significant attack surface. There is a sysctl for this:

`sudo sh -c "echo 1 > /proc/sys/kernel/unprivileged_userns_clone`

Basically user namespaces let you do the same thing as pid or network namespaces, but with users. This means you can have a "fake" root user. The Linux kernel, marvel of software that it is, is easily confused by this and basically hands you trivial privescs if you're this "fake" root user.

This problem is pretty much only getting worse because user namespaces are becoming more powerful whereas kernel security is staying the same (ie: not moving at all).

That's why it's gated in most distros by default.


> That's why it's gated in most distros by default.

Debian used to gate them behind a sysctl, but that's changing in the upcoming Bullseye release:

"The previous Debian default was to restrict this feature to processes running as root, because it exposed more security issues in the kernel. However, as the implementation of this feature has matured, we are now confident that the risk of enabling it is outweighed by the security benefits it provides."

https://www.debian.org/releases/bullseye/amd64/release-notes...

Ubuntu has allowed user namespaces by default for years. Which distros are still holding out?


I'm on Debian Buster.


The advantage of rootless though, over user namespaces with a rootful Docker daemon is that in rootless all the components run as standard user, so a compromise of the Docker daemon should just allow for escape to a standard user.

Not sure about most distros gating that sysctl. Ubuntu works fine with rootless Docker with no changes and looking at their install instructions, there's only mention of setting that sysctl on debian and arch.


> The advantage of rootless though, over user namespaces with a rootful Docker daemon is that in rootless all the components run as standard user, so a compromise of the Docker daemon should just allow for escape to a standard user.

Yep. I just was answering the question, which is what the tradeoff is.

> Not sure about most distros gating that sysctl. Ubuntu works fine with rootless Docker with no changes and looking at their install instructions, there's only mention of setting that sysctl on debian and arch.

Interesting. I haven't checked in a while. I'm also not on the latest debian though.


Are these vulnerabilities actual bugs, or just misfeatures?


actual bugs, qualys’s recent cve-2021-33909 is one example.


To clarifymy stance, now that I have a bit more time this evening… unprivileged userns is the only way forward for linux sandboxing on a bare-metal host past the boundaries of POSIX isolation. so from a security perspective I do hope most distros get this turned on at some point, and that these bugs stop being so commonplace.


There may be some overhead with networking if your application uses a very large amount of bandwidth. See:

https://github.com/rootless-containers/rootlesskit/tree/v0.1...

Otherwise for general dockerized applications, you won't notice any difference.

You may find some quirks, but these can all be worked around easily as described on the rootless docker page.

We run it in production with no issues so far.


Our develompent setup uses docker swarm which requires Overlay networking which is not supported in rootless. Otherwise I'd probably use rootless docker on my dev machine.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: