Date: Thu, 28 Jan 2016 12:17:22 -0800 From: Kees Cook <keescook@...omium.org> To: Robert Święcki <robert@...ecki.net> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, 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" <linux-doc@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled On Thu, Jan 28, 2016 at 11:11 AM, Robert Święcki <robert@...ecki.net> wrote: > 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. Yes, exactly. I want to find a way to offer admins a way to reduce attack surface. I have no interest in blame; this is a matter of practicality. It exposes a less well tested set of APIs to non-privileged users, so let's offer a way to remove that when desired. -Kees -- Kees Cook Chrome OS & Brillo Security
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.