Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753839AbcCISvT (ORCPT ); Wed, 9 Mar 2016 13:51:19 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:53966 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753782AbcCISvI (ORCPT ); Wed, 9 Mar 2016 13:51:08 -0500 Message-Id: <1457549467.650797.544465346.49653120@webmail.messagingengine.com> X-Sasl-Enc: vM2gYoYTRRSdmCqTyXuhgQrHgzhSAohnuu7Y+wHN2VlV 1457549467 From: Colin Walters To: Kees Cook , Andy Lutomirski Cc: linux-kernel@vger.kernel.org, "Eric W. Biederman" , Linux Containers , Alexander Larsson , Serge Hallyn , Stephane Graber , Seth Forshee MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-f945545c In-Reply-To: References: Subject: Re: Thoughts on tightening up user namespace creation Date: Wed, 09 Mar 2016 13:51:07 -0500 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1473 Lines: 36 On Wed, Mar 9, 2016, at 01:14 PM, Kees Cook wrote: > On Mon, Mar 7, 2016 at 9:15 PM, Andy Lutomirski wrote: > > Hi all- > > > > There are several users and distros that are nervous about user > > namespaces from an attack surface point of view. > > > > - RHEL and Arch have userns disabled. > > > > - Ubuntu requires CAP_SYS_ADMIN > > > > - Kees periodically proposes to upstream some sysctl to control > > userns creation. > > And here's another ring0 escalation flaw, made available to > unprivileged users because of userns: > > https://code.google.com/p/google-security-research/issues/detail?id=758 Looks like Andy won't have to eat his hat ;) > The change in attack surface is _substantial_. We must have a way to > globally disable userns. No one would object if it was enabled but only accessible to CAP_SYS_ADMIN though, right? This could be useful for writing setuid binaries that expose some of the features, but e.g. not CAP_NET_ADMIN. Andy's suggestion of having this be a per-namespace setting makes sense to me. Currently some container tools that do use userns are by default denying it to be recursive (Sandstorm.io and Docker 1.10 at least) by using a seccomp filter on clone(). If we had this setting that filter wouldn't be necessary, and would solve the issue that seccomp filters aren't robust against the kernel adding new API, e.g. a new CLONE_NEWUSER_NONEWPRIVS which might enable chroot() but not CAP_NET_ADMIN.