why are unprivilged user namespaces enabled by default? why by default give user the ability to run iptables and other stuff (mount?) (even though it runs in an "unprivilged" namespace)
For example, Chrome uses namespaces to implement its process sandbox. However, Chrome installs a setuid-root binary, so that it doesn't need "unpriveleged" namespaces enabled. This is sad, though: setuid-root binaries are inherently a security risk of their own. It would be nice if Chrome did not need to install a suid-root binary. But, it can only possibly avoid this in the future if unprivileged user namespaces are widely available. Bugs like this unfortunately delay that future.
Incidentally, programs like Chrome that set up namespace-based sandbox also commonly use seccomp to prevent the sandboxed code from using exotic kernel features -- including namespaces. So user namespaces won't be available to sandboxed code regardless of whether you enable unprivileged user namespaces at the system level.
Personally I feel that on a single-user desktop, there's little point in enforcing a separation between users and root -- everything interesting is probably available to your user account anyway. But sandboxes like Chrome's are obviously essential to security on desktops. So I'd tend to say, on a single-user desktop, enabling unprivileged user namespaces improves security overall, by encouraging the use of sandboxes.
Multi-user systems are a different story, obviously.
Electron apps too (if sandboxing is enabled).
Bubblewrap (used by flatpack, idk. about snap) prefers user namespaces, too.
All of them could can have suid fallbacks they would prefer to not have.
Tbh. if Linux had a proper capability system it probably would make sense to attach a "user ns" capability to binaries which in the past used suid-root for namespaces and not allow "other" processes to use it.
> there's little point in enforcing a separation between users and root
I don't agree. But it is a different discussion. (And a complicated discussion too as Linux desktop is IMHO currently lacking in various security areas as security requirements have changed. So often when you argue they should do this you get non productive answers like "oh but you also could do [that other think which also need to change sooner or later]". Anyway it can make the difference between it being easily able to steal all password from your password manager and it only being able to steal the passwords you did use since infection. Or it being able to steel a early boot full disk encryption key. etc. etc.)
I agree but I don't think that's fundamental. It's pointless on Linux because any attacker can simply alias `sudo` to something and wait.
But I can imagine a modern desktop OS where there's a useful admin account. Windows is pretty close. Much better than Linux on that front.
If a Chrome bug is found that allows web pages to arbitrary code execution, it can be chained with an exploit like this to infect more than just the user account, potentially, depending on the computer, the firmware itself.
For normal botnet/cryptocurrency stealing malware once it has user access it has everything it needs.
Of course, such a platform basically exists: the web platform.
I think everything-is-a-web-site is the realistic way we get to secure desktops. I don't like it but it's hard to imagine anything else getting traction from here.
* The mechanism for granting capabilities to binaries is convoluted, requiring special tools, filesystem support, and fiddly code. It's surprisingly tedious to make it work.
* There's no specific capability for user namespaces. When they require privileges at all, they require CAP_SYS_ADMIN. This capability is basically equivalent to root anyway. In fact, many Linux capabilities can easily be escalated to full root privileges.
My personal opinion is that Linux "capabilities" are not worth using most of the time. (I also hate that they are called "capabilities", a word that I would rather reserve for object-capabilities, which are an actually-useful security model!)