linux-kernel - Re: [PATCH v2] sysctl: allow CLONE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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