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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jan 2016 12:08:10 -0800
From:	Kees Cook <keescook@...omium.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	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>,
	Robert Święcki <robert@...ecki.net>,
	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 9:41 AM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Kees Cook <keescook@...omium.org> writes:
>
>> There continue to be unexpected security exposures when users have access
>> to CLONE_NEWUSER.
>
> So how does this sucessfully address that issue?

I've explained this several times. It disables new user namespaces.
I've asked earlier but got no answer: is revocation a requirement for
this feature?

>> For admins of systems that do not use user namespaces
>> and are running distro kernels with CONFIG_USER_NS enabled, there is
>> no way to disable CLONE_NEWUSER. This provides a way for sysadmins to
>> disable the feature to reduce their attack surface without needing to
>> rebuild their kernels.
>>
>> This is inspired by a similar restriction in Grsecurity, but adds
>> a sysctl.
>>
>
> I have already nacked this patch.   Thank you for removing the broken
> capability in sysctl check.  But this does not address any of the other
> issues I have raised.

I also asked about implementation directions but got no reply: do you
want this as an rlimit, or something else?

> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>
> Further as far as I can tell this is just about a witch hunt.  Isn't
> that what you call a campaign against something when the complaining
> party does not understand something persecutes it and does not bother to
> try and understand?
>
> I have already told you what kind of direction would be acceptable.  I
> gave concrete suggests and here you are wasting our time with this patch
> again.

I wanted to have a "clean" version of the sysctl patch and figured I'd
share it since it was the implementation that Andy and others had
showed interest in, even if it won't be the final version of this
feature.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security