Getting userns enabled in vendor kernels

[James Bottomley]

On Wed, 2013-11-13 at 15:13 +0000, Daniel P. Berrange wrote:
> The user namespace work gave us two new features
> 
>  - Ability to set UID/GID mappings between containers & host
>  - Ability for unprivileged users to create namespaces
> 
> The first of these features is really critical to be able to make the
> use of LXC secure using DAC, rather than having to rely on the use of
> MAC (SELinux/AppArmour) protection.
> 
> The second feature is a nice, but it is not critical in the same way,
> since it is all about opening up new use cases, rather than securing
> existing use cases.
> 
> Both of these features are under the same CONFIG_USER_NS Kconfig setting,
> so you can't get the former without also getting the latter.
> 
> This is a problem because distro kernel maintainers are rejecting requests
> to enable CONFIG_USER_NS over concern that it significantly expands the
> attack surface accessible to unprivileged users. Fedora, RHEL & Arch Linux
> have all rejected enabling CONFIG_USER_NS as it is due to this concern.
> 
> This sucks, because there's a really pressing need to make the ID mapping
> feature available, while there isn't much sense of urgency over allowing
> unprivileged users to create namespaces.
> 
> In Fedora I managed to get agreement to enable CONFIG_USER_NS provided
> that the following patch is reverted [1]
> 
>   commit 5eaf563e53294d6696e651466697eb9d491f3946
>   Author: Eric W. Biederman <ebiederm at xmission.com>
>   Date:   Mon Nov 21 17:22:31 2011 -0800
> 
>     userns: Allow unprivileged users to create user namespaces.
> 
> If other distros have similar demands, I'm wondering if it is worth
> making the above patch be conditional on a new Kconfig parameter like
> CONFIG_USER_NS_UNPRIVILEGED ?
> 
> Arch Linux maintainers suggested that this patch be made conditional
> on a sysctl setting, defaulting to 0, so those who want the unprivileged
> users to create namespaces have to explicitly opt-in at runtime[2].

We'd be OK with this at Parallels too.  UID/GID mapping is essential so
container root is unprivileged in the host.  Ability for unprivileged
users to create a userns is required for nested containers (so the
unprivileged root can create one) which isn't a critical feature.

The thing that worries me is that turning this off means no-one will
work on the bugs and one day distros will start to use USER_NS for
things other than containers.  When that happens, container roots will
need to use it to bring up distro IaaS instances.

James