This exploit relies on unprivileged access to user namespaces: `sysctl kernel.unprivileged_userns_clone = 1`
This is the default setting for Debian/Ubuntu, and also Arch Linux kernels. If you don't have a need for that setting, (eg. running Docker commands without sudo), you should probably disable that anyway.
But also e.g. by the chrome sandbox used by e.g. electron apps (or e.g. 1password). Through that sandbox helper binary can also work with being a suid program.
I also wouldn't be too surprised if e.g. proton will start using user namspaces at some point in the future.
So for any non-hardened desktop linux system you probably should _not_ disable it!
(For many servers or special hardened Linux it often isn't a bad idea to disable it.)
:\ It really is unfortunate that that setting is great for letting people run containers (and the like) without giving them root access... but also has a bad track record of then having vulnerabilities that allow root access.
I'm not a kernel developer so take with a grain of salt; what I've heard suggested is that it's not fundamentally bad and if we'd had it from day one it would be fine, but a lot of kernel interfaces were designed with the idea that only root could use them so they didn't worry about certain security matters as much. And maybe that was never ideal but it could even be reasonable; if only root can trigger a bug that gives you root access... it's not good because it could be used to work around other restrictions, but one can imagine that it wouldn't exactly be a priority. But then what actually happened is that very late in the game we got this new feature that allows any old user to access these less-protected interfaces, and that's resulted in a certain amount of... catching up.
the real problem is not that. this is nothing but a way to DROP privilege!
the problem is that containers require tons of hacks on the network side to just-work. and docker main selling point is all the usafe hacks it does for it.
so obviously, any container solution will adopt these hacks eventually, and there is the problem.
you end up with a perfectly sane namespace functionality that removes access, but then the kernel opens the gate because network hacks are good
AIU the cause is Netfilter API that doesn't sanitize its input, because only root can call it, so there is no need to sanitize. Then unprivileged user namespaces open all root API to unprivileged user, so nonsanitizing Netfilter API became available to unprivileged user.
that's my point. why from a point users didn't have access to netfiltet now gives users access to netfilter? from a command which should be adding more restraint no less.
also people focus on this only being a problem now with priv escalation... but all that was always a problem before unprivileged containers... by allowing container code to exploit host kernel code, but nobody called it a privilege escalation then because you started your container as root. sigh.
The sysctl command isn't available on specific kernel configurations. You could try running `unshare -Urn`. If it runs without sudo (and you haven't configured any specific permissions yourself), unprivileged namespaces are enabled.
This is the default setting for Debian/Ubuntu, and also Arch Linux kernels. If you don't have a need for that setting, (eg. running Docker commands without sudo), you should probably disable that anyway.