Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1354359

Re: Thoughts on tightening up user namespace creation

Show key headers only | View raw

On 2016-03-09 13:51, Colin Walters wrote:
> On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote:
>> On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> Hi all-
>>>
>>> There are several users and distros that are nervous about user
>>> namespaces from an attack surface point of view.
>>>
>>>   - RHEL and Arch have userns disabled.
>>>
>>>   - Ubuntu requires CAP_SYS_ADMIN
>>>
>>>   - Kees periodically proposes to upstream some sysctl to control
>>> userns creation.
>>
>> And here's another ring0 escalation flaw, made available to
>> unprivileged users because of userns:
>>
>> https://code.google.com/p/google-security-research/issues/detail?id=758
>
> Looks like Andy won't have to eat his hat ;)
>
>> The change in attack surface is _substantial_. We must have a way to
>> globally disable userns.
>
> No one would object if it was enabled but only accessible to
> CAP_SYS_ADMIN though, right?  This could be useful for
> writing setuid binaries that expose some of the features, but e.g. not
> CAP_NET_ADMIN.
At least Google Chrome (and probably Chromium) is using user namespaces 
without CAP_SYS_ADMIM (although AFAIUI, it's because they can't use the 
other namespace types effectively as a regular user).
>
> Andy's suggestion of having this be a per-namespace setting makes
> sense to me.  Currently some container tools that do use userns
> are by default denying it to be recursive (Sandstorm.io and Docker 1.10 at least)
> by using a seccomp filter on clone().  If we had this setting that
> filter wouldn't be necessary, and would solve the issue that seccomp filters
> aren't robust against the kernel adding new API, e.g. a new CLONE_NEWUSER_NONEWPRIVS
> which might enable chroot() but not CAP_NET_ADMIN.
>
Personally, I like the suggestion from Alexander Larsson to make a 
cgroup controller.  Container tools obviously want some degree of 
hierarchical control (even if it's just saying that the hierarchy ends 
here), and it would simplify the possibility of running more than one 
container stack on the same host (I know at least a couple people who 
would love to be able to safely use Docker on the same host as LXC or 
lmctfy).

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Thoughts on tightening up user namespace creation Andy Lutomirski <luto@amacapital.net> - 2016-03-08 06:20 +0100
  Re: Thoughts on tightening up user namespace creation "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-03-08 07:10 +0100
    Re: Thoughts on tightening up user namespace creation Andy Lutomirski <luto@amacapital.net> - 2016-03-08 19:40 +0100
      Re: Thoughts on tightening up user namespace creation "Serge E. Hallyn" <serge@hallyn.com> - 2016-03-08 23:50 +0100
  Re: Thoughts on tightening up user namespace creation Alexander Larsson <alexl@redhat.com> - 2016-03-08 11:10 +0100
  Re: Thoughts on tightening up user namespace creation ebiederm@xmission.com (Eric W. Biederman) - 2016-03-08 17:50 +0100
  Re: Thoughts on tightening up user namespace creation Kees Cook <keescook@chromium.org> - 2016-03-09 19:20 +0100
    Re: Thoughts on tightening up user namespace creation Colin Walters <walters@verbum.org> - 2016-03-09 20:00 +0100
      Re: Thoughts on tightening up user namespace creation "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-03-09 20:10 +0100
      Re: Thoughts on tightening up user namespace creation "Serge E. Hallyn" <serge@hallyn.com> - 2016-03-09 20:30 +0100
        Re: Thoughts on tightening up user namespace creation Kees Cook <keescook@chromium.org> - 2016-03-09 20:30 +0100
    Re: Thoughts on tightening up user namespace creation "Serge E. Hallyn" <serge@hallyn.com> - 2016-03-09 20:10 +0100
      Re: Thoughts on tightening up user namespace creation Kees Cook <keescook@chromium.org> - 2016-03-09 20:20 +0100

csiph-web