Getting userns enabled in vendor kernels

DISCUSSION Daniel P. Berrange 7 participants 7 messages Nov 13, 2013 – Nov 15, 2013 4 messages not in the archive

lore

Share & tools

lore

Daniel P. Berrange

author

2013-11-13 15:13 UTC #0 lore raw

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/[email protected]>
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

Signature · 4 lines

|: 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 :|

A message that is not in the archive (sent off-list or not yet received): [email protected]

Serge Hallyn

2013-11-13 16:30 UTC #2 lore raw

Quoted 21 lines · 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.

Quoted 6 lines

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

Quoted 24 lines

commit 5eaf563e53294d6696e651466697eb9d491f3946
Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>
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
Signature · 4 lines
|: 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 :|

James Bottomley

2013-11-14 15:52 UTC #3 lore raw

In reply to a message not in the archive

Quoted 34 lines · 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/[email protected]>
Date: Mon Nov 21 17:22:31 2011 -0800
userns: Allow unprivileged users to create user namespaces.

Quoted 7 lines

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

A message that is not in the archive (sent off-list or not yet received): 1384444373.2005.8.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org

Aristeu Rozanski

2013-11-14 17:44 UTC #5 lore raw

(Replying also to Serge, same argument)

Quoted 4 lines · James Bottomley

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.

Signature · 1 line

Aristeu

A message that is not in the archive (sent off-list or not yet received): [email protected]

Serge E. Hallyn

2013-11-14 17:48 UTC #7 lore raw

Quoted 10 lines · Aristeu Rozanski

(Replying also to Serge, same argument)
Quoted 4 lines · James Bottomley
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

Gao feng

2013-11-15 05:19 UTC #8 lore raw

In reply to a message not in the archive

Quoted 25 lines · 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.

Quoted 8 lines

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/[email protected]>
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Eric W. Biederman

2013-11-15 08:52 UTC #10 lore raw

Quoted 8 lines · Gao feng

Quoted 6 lines · Daniel P. Berrange
commit 5eaf563e53294d6696e651466697eb9d491f3946
Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>
Date: Mon Nov 21 17:22:31 2011 -0800
userns: Allow unprivileged users to create user namespaces.

Quoted 7 lines

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