[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP145pigHJ0CsuvWy=9s1g+Pb2xfLPbqFcYfEP_Dww=6c-G2Yg@mail.gmail.com>
Date: Thu, 28 Jan 2016 20:11:23 +0100
From: Robert Święcki <robert@...ecki.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>, "Serge E. Hallyn" <serge.hallyn@...ntu.com>,
Andy Lutomirski <luto@...nel.org>, "Austin S. Hemmelgarn" <ahferroin7@...il.com>,
Richard Weinberger <richard@....at>, Dmitry Vyukov <dvyukov@...gle.com>, David Howells <dhowells@...hat.com>,
Kostya Serebryany <kcc@...gle.com>, Alexander Potapenko <glider@...gle.com>, Eric Dumazet <edumazet@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>, linux-doc@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled
2016-01-28 18:48 GMT+01:00 Eric W. Biederman <ebiederm@...ssion.com>:
> Kees Cook <keescook@...omium.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
