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]

Message-ID: <87wpqteh4y.fsf@x220.int.ebiederm.org>
Date:	Thu, 28 Jan 2016 11:41:17 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kees Cook <keescook@...omium.org>
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-kernel@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled

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?

> 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.

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.

Eric