Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933994AbcCITHf (ORCPT ); Wed, 9 Mar 2016 14:07:35 -0500 Received: from h2.hallyn.com ([78.46.35.8]:34816 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933889AbcCITH1 (ORCPT ); Wed, 9 Mar 2016 14:07:27 -0500 Date: Wed, 9 Mar 2016 13:07:25 -0600 From: "Serge E. Hallyn" To: Kees Cook Cc: Andy Lutomirski , Colin Walters , Linux Containers , Serge Hallyn , "linux-kernel@vger.kernel.org" , Seth Forshee , Stephane Graber , "Eric W. Biederman" Subject: Re: Thoughts on tightening up user namespace creation Message-ID: <20160309190725.GA2218@mail.hallyn.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1706 Lines: 41 Quoting Kees Cook (keescook@chromium.org): > 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 Kees, I think you think this makes your point, but all it does is make me want to argue with you and start flinging back cves against kvm, af_unix, sctp, etc. > > I think there are three main types of concerns. First, there might be > > some as-yet-unknown semantic issues that would allow privilege > > escalation by users who create user namespaces and then confuse > > something else in the system. Second, enabling user namespaces > > exposes a lot of attack surface to unprivileged users. Third, > > allowing tasks to create user namespaces exposes the kernel to various > > resource exhaustion attacks that wouldn't be possible otherwise. > > > > Since I doubt we'll ever fully address the attack surface issue at > > least, would it make sense to try to come up with an upstreamable way > > to limit who can create new user namespaces and/or do various > > dangerous things with them? > > The change in attack surface is _substantial_. We must have a way to > globally disable userns. I'm confused. Didn't we agree a few months ago, somewhat reluctantly, on a sysctl?