[arch-general] user namespaces

[Daniel Micay]

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.

> I would like to suggest that arch stops to disable this feature in
> future kernel versions.
>
> Resoning:
> 
> The original reason to block user namespaces were a number of security
> issues that allowed unprivileged users to access features they should
> not have access to. Due to the nature of user namespaces to provide
> isolated user environments with access to privileged features like
> other
> namespaces (inside that isolated namespace only), it should be obvious
> that this feature had to be designed carefully in order not to harm
> the
> security outside the namespace. Even though there have been issues,
> this
> feature is now considered stable enough for distros like debian and
> red
> hat to allow its use even for unprivileged users.

There's still an unrelenting torrent of security issues from it. Maybe
wait until that stops before proposing this. I don't think it's going to
stop because of how this feature is designed. It greatly increases the
attack surface and there isn't going to be a mitigating factor that
changes this situation. It's a fundamentally flawed, garbage feature and
 the arguments for it are nonsense. There are better ways to do this, by
simply not tying your hands and refusing to implement anything in user
space but instead pretending that all common features must happen in the
kernel despite major security risks and poor semantics.

> Moreover there are many applications that use this feature to provide
> or
> enhance security
> Among them are:
> 
> lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
> chromium

There's one well-written sandbox there (Chromium's usage) and it doesn't
require this feature. They also don't need this feature on platforms
where they have control like Android, since they can implement it in a
saner way where it doesn't massively increase kernel attack surface.

> After working with sandboxing applications for several month, it seems
> clear to me that disabling user namespaces decreases the security of
> the
> system significantly. Some of these applications can not provide core
> features due to user namespaces missing. Others have significant
> security features disabled for this reasons. But the worst part is how
> some of these projects dealt with the missing feature: Many are using
> suid bits to execute the application as root to get access to the
> features they would have inside a user namespace. And for those who
> have
> worked with suid applications and their security it will not be
> surprising that they have failed to do this securely, leading to not
> just a few local root exploits.

There's no hard requirement that they have to do it that way. They can
use a service where the user doesn't control the environment used to
spawn the application (like setuid) or full control over the environment
where it ends up being run. Application containers *really* do not need
this feature. It's far better to do it in a more secure, saner way vs.
exposing massive kernel attack surface.

> Taking firejail just as an example:
> (CVE-2017-5207)
> (CVE-2017-5206)
> (CVE-2017-5180)
> (CVE-2016-10122)
> (CVE-2016-10118)
> (CVE-2016-9016)

A junk, insecure application is not a reason to greatly reduce kernel
security for everyone.

> And that is just from the last release...
> 
> non of these issues would have been possible if user namespaces could
> be
> used, which is btw. what bubblewrap does if the feature is available,
> but since it isn’t on arch they have to use suid too (but bubblewrap
> is
> designed with security in mind for a change, so no known issues so
> far)
> Chromium is another case that has to use suid to use its sandbox and
> while I consider the developers very skilled in regards to security
> (they build a very nice broker architecture sandbox on windows too)
> there have been local root exploits in the linux version of chromium
> because of this.

Chromium has had a couple vulnerabilities there. Can you point to any
that are full blown privesc? I can point to 30+ kernel bugs from the
past couple years that are privesc via user namespaces. Also those
kernel vulnerabilities impact *everyone*.

> Even while looking at the surface of this problem it becomes clear
> this
> causes way more problems then it solves. Considering arch will be or
> already is the only linux distribution to disable this feature,
> developers of future applications will have to chose between
> droppingsupport for arch or to keep using features like suid that pose
> a real security threat opposite to user namespaces.

Nope, you're just ignoring / misrepresenting the facts here and failing
to present a real proposal. Try again, and propose something where
attack surface is not increased beyond the cases where this feature is
actually required. Enabling it globally when people install something
like Chromium doesn't qualify.

User namespaces are far more real of a security threat than these fears
you're presenting here, and doing it as you propose would impose those
risks on EVERYONE so that the few can have their poorly designed
container features based on this.

> Therefore I urge the people responsible to reconsider their choice an
> enable user namespaces in future kernel versions of arch linux.

Present a real proposal taking into account the very real reasons to
avoid this that you are skirting around. If you aren't going to present
technical solutions to the problems, which are certainly possible and
could be implemented, then I don't think anything should be changed.

I have thoughts on how to enable this while containing the attack
surface but seeing as I have no interest in the feature and have a lot
of far more important work to do than working on toy features, I don't
plan on doing anything about this myself.

> Bug reports regarding user namespaces:
> 
> https://bugs.archlinux.org/task/36969
> https://bugs.archlinux.org/task/49337

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170201/2baaca48/attachment-0001.asc>