On Wed, Feb 01, 2017 at 01:20:41AM -0500, Daniel Micay via arch-general wrote:
On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
Summary:
Arch Linux is one of the few, if not the only distribution that still disables or restricts the use of unprivileged user namespaces, a feature that is used by many applications and containers to provide secure sandboxing. There have been request to turn this feature on since Linux 3.13 (in 2013) but they are still being denied. While there may have been some reason for doing so a few year ago, leading to many distributions like Debian and Red Hat to restrict its use to privileged users via a kernel patch (they never disabled it completely), today arch seems to be the only distribution to block this feature. Even conservative distros like Debian 8 and 9 have this feature fully enabled.
There are still endless unprivileged user namespace vulnerabilities and it's a nearly useless feature. The uid/gid mapping is poorly thought out and immature without the necessary environment (filesystem support, etc.) built around it, but no one really wants it for that reason. They want it because it started pretending that it can offer something that it can't actually deliver safely. There are much better ways to do unprivileged sandboxes with significantly less risk than CLONE_NEWUSER or setuid executables where the user controls the environment. Anything depending on this mechanism instead of properly designed plumbing for it is simply lazy garbage. Lack of a proper layer on top of the kernel providing infrastructure (systemd is so far from that) on desktop/server Linux is not going to be fixed by delegating everything to the kernel even when it massively increases attack surface.
BTW, why can't one simply create a *privileged* lxc container on a host filesystem mounted with nosuid, then create an unprivileged user inside that container for browsing / viewing of untrusted pdfs, etc? But I still believe that the idea of sandboxing a web browser is idiotic... Cheers, -- Leonid Isaev