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


Groups > linux.kernel > #1320955

Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled

From Robert Święcki <robert@swiecki.net>
Newsgroups linux.kernel
Subject Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled
Date 2016-01-28 20:20 +0100
Message-ID <qW0gN-80O-5@gated-at.bofh.it> (permalink)
References <qVVTR-4Lm-37@gated-at.bofh.it> <qVZ1n-6V6-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


2016-01-28 18:48 GMT+01:00 Eric W. Biederman <ebiederm@xmission.com>:
> Kees Cook <keescook@chromium.org> writes:
>
>> +     if (sysctl_userns_restrict && !(capable(CAP_SYS_ADMIN) &&
>> +                                     capable(CAP_SETUID) &&
>> +                                     capable(CAP_SETGID)))
>> +             return -EPERM;
>> +
>
> I will also note that the way I have seen containers used this check
> adds no security and is not mentioned or justified in any way in your
> patch description.
>
> Furthermore this looks like blame shifting.  And quite frankly shifting
> the responsibility to users if they get hacked is not an acceptable
> attitude.

I think I might start understanding your point. Which, if I'm not
mistaken, is that it's not user namespaces which are buggy, but rather
some pieces of the kernel which would otherwise not be reachable from
the typical low-priv level of regular users (e.g. bugs in SOCK_RAW
sockets or iptables or mounts)?

If so, I can agree with such wording, but the proposed sysctl might
still be needed in such case. I guess those bits of the kernel which
were not reachable previously from non-priv users historically got
much less attention in terms of time spent on security reviews and
security fuzzing. And as much as users of the kernel would like to see
those pieces of the kernel to be tested to a level that the attack
surface reachable from unprivileged users level were tested, it will
not happen tomorrow. And our best option now might be to have some
switchable setting to disable this attack surface for those users who
feel they need it. In the meantime, we can concentrate on sec
reviewing those newly reachable kernel APIs, so some day we could
remove this sysctl.

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


Thread

[PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-28 15:40 +0100
  Re: [kernel-hardening] [PATCH v2] sysctl: allow CLONE_NEWUSER to be  disabled "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-28 16:30 +0100
  Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-28 19:00 +0100
    Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled Robert Święcki <robert@swiecki.net> - 2016-01-28 20:20 +0100
      Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-28 21:20 +0100
  Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-28 19:00 +0100
    Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-28 21:10 +0100

csiph-web