Unprivileged user namespaces make it possible for unprivileged programs to set up sandboxes.

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.

Chromes sandbox uses unprivileged namespaces but has a suid-root fallback.

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.)

> there's little point in enforcing a separation between users and root

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.

Yes, I agree. But I don't think the path forward is to re-establish the security of root. Instead the path forward is to stop granting the full capabilities of the user to every program the user runs. In Android, for example, every app has its own user account. That is meaningful! I wish every desktop app were sandboxed by default, but it requires redesigning so many interfaces that you might as well think of it as a whole new platform.

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.

Even on a Linux desktop OS with a single user, it's still a security risk as it skips over a last line of defence.

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.

Sure but most malware doesn't really care about infecting more than the user. The only reason to infect firmware is to gain persistence in the face of OS reinstalls, but those are very rare in general. Only targeted NSA level malware is going to bother with that.

For normal botnet/cryptocurrency stealing malware once it has user access it has everything it needs.

If you're able to throw a 0day at a target, there's nothing stopping you from throwing it again after they reinstall.

Is there a reason why user namespaces cannot be enabled per executable? setcap "something something user ns" /usr/bin/chrome?

In theory that might work. In practice, it doesn't help much; you might as well stick with setuid-root.

* 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!)

Because if they didn't keep having bugs like this, they'd be a great security feature. Like, it'd be great if running flatpaks didn't require a suid binary on the host in order to isolate apps.