Getting userns enabled in vendor kernels

Getting userns enabled in vendor kernels

[Daniel P. Berrange]

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-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
  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].

Regards,
Daniel

[1] https://bugzilla.redhat.com/show_bug.cgi?id=917708
[2] https://bugs.archlinux.org/task/36969
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: Getting userns enabled in vendor kernels

[Serge Hallyn]

Quoting Daniel P. Berrange (berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> 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]

Hi Daniel,

in the past I've used a patch to add a sysctl, default off, which
prevents unprivileged users from using CLONE_NEWUSER [1].  A debian kernel
maintainer also seemed to want that.  I haven't re-pushed it since Eric
complained about precise way I did it, and the Ubuntu kernel team is
not currently requiring it...  But it sounds like it would set a lot
of minds at ease to continue with that.

I still really prefer not to have it upstream, as imo it'll slow down
our finding any remaining issues...  (I think a few months ago it was
an appropriate patch to have;  today I've seen enough subtle issues
discussed that I'm starting to feel more confident the way it is)
But it'd be good if everyone used the same patch.

[1] http://kernel.ubuntu.com/git?p=serge/ubuntu-saucy.git;a=commit;h=5c847404dcb2e3195ad0057877e1422ae90892b8

>   commit 5eaf563e53294d6696e651466697eb9d491f3946
>   Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>   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].
> 
> Regards,
> Daniel
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=917708
> [2] https://bugs.archlinux.org/task/36969
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: 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-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>   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

Re: Getting userns enabled in vendor kernels

[Aristeu Rozanski]

(Replying also to Serge, same argument)
On Thu, Nov 14, 2013 at 07:52:53AM -0800, James Bottomley wrote:
> 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.

True, but the status we have now is that USER_NS is disabled completely
in Fedora. This approach will split the process in two: enable part of
it, let it soak, solve problems, enable user created namespaces later.

-- 
Aristeu

Re: Getting userns enabled in vendor kernels

[Serge E. Hallyn]

Quoting Aristeu Rozanski (aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> (Replying also to Serge, same argument)
> On Thu, Nov 14, 2013 at 07:52:53AM -0800, James Bottomley wrote:
> > 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.
> 
> True, but the status we have now is that USER_NS is disabled completely
> in Fedora. This approach will split the process in two: enable part of
> it, let it soak, solve problems, enable user created namespaces later.

Right - so my suggestion is that we agree on a 100% identical patch for anyone
who must use such a patch to justify enabling USER_NS to use.  But that we not
push it upstream.  (Ubuntu would hopefully not use it - unless the overmount bug
does not get fixed in a timely manner.)

-serge

Re: Getting userns enabled in vendor kernels

[Gao feng]

On 11/13/2013 11:13 PM, 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-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>   Date:   Mon Nov 21 17:22:31 2011 -0800
> 
>     userns: Allow unprivileged users to create user namespaces.

I don't know what's the benefit this commit brings and what's use
case this commit tries to support.

In most use case, the container/namespace is create by privilged
user and the id-map can prevent unsafe things.

IMO, I think this patch can be reverted.

Thanks

Re: Getting userns enabled in vendor kernels

[Eric W. Biederman]

Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> writes:

> On 11/13/2013 11:13 PM, Daniel P. Berrange wrote:
>> 
>>   commit 5eaf563e53294d6696e651466697eb9d491f3946
>>   Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>>   Date:   Mon Nov 21 17:22:31 2011 -0800
>> 
>>     userns: Allow unprivileged users to create user namespaces.
>
> I don't know what's the benefit this commit brings and what's use
> case this commit tries to support.
>
> In most use case, the container/namespace is create by privilged
> user and the id-map can prevent unsafe things.
>
> IMO, I think this patch can be reverted.

This patch brings tremendous benefit, and by itself is completely safe.

It is the added ns_capable calls that are potentially dangerous, and it
seems you like the idea of taking advantage of those.

The goal is to not let anything that is not safe for an unprivileged
user to use happen in a user namespace.  One primary use for user
namespaces is separate administrative domains.  Aka allowing someone you
don't trust with root privileges to do things on your box.  You trust
them with shell access but that is another story.

So if it is safe enough in general for people with shell access to use
the functionality.  Restricting the creation of user namespaces to root
is silly.

Restricting user namespaces creation to root really is a form of
sticking your fingers in your, closesing your eyes, and going
la-la-la-la I can't hear you.  When faced with security issues.

For production use it is either as safe as the rest of the kernel or it
is not.  A sysctl so you can turn user namespaces on/off so you can
experiment with them while they are maturing is something that might be
reasonable.  But again that is another form of CYA.  But a likely a
reasonable CYA for a distroy kernel.

I intend to fix bugs and enable people to actually use their kernel not
run around and trying and point the blame for things that go wrong at
others.

And now back to my regularly scheduled bug fixing.

Eric