From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755059AbcAVWtw (ORCPT <rfc822;w@1wt.eu>);
	Fri, 22 Jan 2016 17:49:52 -0500
Received: from a.ns.miles-group.at ([95.130.255.143]:11949 "EHLO radon.swed.at"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753361AbcAVWtv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 22 Jan 2016 17:49:51 -0500
Subject: Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled
To: Kees Cook <keescook@chromium.org>,
        Andrew Morton <akpm@linux-foundation.org>
References: <1453502345-30416-1-git-send-email-keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Andy Lutomirski <luto@amacapital.net>,
        =?UTF-8?Q?Robert_=c5=9awi=c4=99cki?= <robert@swiecki.net>,
        Dmitry Vyukov <dvyukov@google.com>,
        David Howells <dhowells@redhat.com>, Miklos Szeredi <mszeredi@suse.cz>,
        Kostya Serebryany <kcc@google.com>,
        Alexander Potapenko <glider@google.com>,
        Eric Dumazet <edumazet@google.com>,
        Sasha Levin <sasha.levin@oracle.com>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com
From: Richard Weinberger <richard@nod.at>
X-Enigmail-Draft-Status: N1110
Message-ID: <56A2B209.7000403@nod.at>
Date: Fri, 22 Jan 2016 23:49:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1453502345-30416-1-git-send-email-keescook@chromium.org>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 22.01.2016 um 23:39 schrieb Kees Cook:
> There continues to be unexpected side-effects and security exposures
> via CLONE_NEWUSER. For many end-users running distro kernels with
> CONFIG_USER_NS enabled, there is no way to disable this feature when
> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER so
> admins not running containers or Chrome can avoid the risks of this
> feature.

Last time such a patch came up I was not thrilled because hiding
a scary feature behind a knob IMHO doesn't make it any better nor helps
finding issues.
But as userns is still a source of a lot of issues and distros enable
it by default a knob for the admin seems to be a good idea by now. ;-\

Thanks,
//richard