[arch-general] user namespaces

[sivmu]

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.

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.

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

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.

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

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.


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 dropping
support for arch or to keep using features like suid that pose a real
security threat opposite to user namespaces.

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


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: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170201/8ecfd38c/attachment.asc>