4 ms·

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

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)

yjftsjthsd-h 3y ago
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.
_factor 3y ago
The issue is the “just works” philosophy. Most defaults are insecure and require technical expertise and hardening.
kentonv 3y ago
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.
- dathinab 3y ago
  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.)
- IshKebab 3y ago
  > 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.
  - PlutoIsAPlanet 3y ago
    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.
    - IshKebab 3y ago
      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.

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)

yjftsjthsd-h 3y ago

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.

_factor 3y ago

The issue is the “just works” philosophy. Most defaults are insecure and require technical expertise and hardening.

kentonv 3y ago

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.

dathinab 3y ago
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.)
IshKebab 3y ago
> 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.
- PlutoIsAPlanet 3y ago
  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.
  - IshKebab 3y ago
    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.