4 ms·
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/s
by staticassertion 5y ago
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.
- etaioinshrdlu 5y agoAre these vulnerabilities actual bugs, or just misfeatures?
- deleted 5y ago[deleted]
- noobquestion81 5y agoactual bugs, qualys’s recent cve-2021-33909 is one example.
- noobquestion81 5y agoTo 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.
- raesene9 5y agoThe 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.
- staticassertion 5y ago> 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.
- foresto 5y ago> 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/ch-information.en.html#linux-user-namespaces https://www.debian.org/releases/bullseye/amd64/release-notes... Ubuntu has allowed user namespaces by default for years. Which distros are still holding out?
- staticassertion 5y agoI'm on Debian Buster.