linux-kernel - Re: [kernel-hardening] Re: [PATCH 0/2] 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: <20160126073852.GC6652@ubuntumail>
Date:	Tue, 26 Jan 2016 07:38:52 +0000
From:	Serge Hallyn <serge.hallyn@...ntu.com>
To:	kernel-hardening@...ts.openwall.com
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Richard Weinberger <richard@....at>,
	Andy Lutomirski <luto@...capital.net>,
	Robert Święcki <robert@...ecki.net>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	David Howells <dhowells@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	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>
Subject: Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER
 to be disabled

Quoting Kees Cook (keescook@...omium.org):
> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
> > So I have concerns about both efficacy and usability with the proposed
> > sysctl.
> 
> Two distros already have this sysctl because it was so strongly
> requested by their users. This needs to be upstream so we can manage
> the effects correctly.

Which two distros?  Was it in fact requested by their users?

My opinion remains that long-term this is a bad thing.  If we're going to
have this upstream, it should be clearly marked so as to be easily
removable at some point down the road.  Userspace that cannot count on a
feature (in the best case) won't use it or (much worse) will fall back
to broken behavior in one case or the other.