From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: "Daniel P. Berrange"
<berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: Getting userns enabled in vendor kernels
Date: Fri, 15 Nov 2013 13:19:45 +0800 [thread overview]
Message-ID: <5285AEF1.6000503@cn.fujitsu.com> (raw)
In-Reply-To: <20131113151330.GZ32643-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
next prev parent reply other threads:[~2013-11-15 5:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 15:13 Getting userns enabled in vendor kernels Daniel P. Berrange
[not found] ` <20131113151330.GZ32643-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-13 16:30 ` Serge Hallyn
2013-11-14 15:52 ` James Bottomley
[not found] ` <1384444373.2005.8.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
2013-11-14 17:44 ` Aristeu Rozanski
[not found] ` <20131114174401.GF12097-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-14 17:48 ` Serge E. Hallyn
2013-11-15 5:19 ` Gao feng [this message]
[not found] ` <5285AEF1.6000503-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-11-15 8:52 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5285AEF1.6000503@cn.fujitsu.com \
--to=gaofeng-bthxqxjhjhxqfuhtdcdx3a@public.gmane.org \
--cc=berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox