Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933987AbcCITM0 (ORCPT ); Wed, 9 Mar 2016 14:12:26 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:34248 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933303AbcCITMR (ORCPT ); Wed, 9 Mar 2016 14:12:17 -0500 MIME-Version: 1.0 In-Reply-To: <20160309190725.GA2218@mail.hallyn.com> References: <20160309190725.GA2218@mail.hallyn.com> Date: Wed, 9 Mar 2016 11:12:16 -0800 X-Google-Sender-Auth: eKlChrpfxBDaxoodVT8Q8n7deHk Message-ID: Subject: Re: Thoughts on tightening up user namespace creation From: Kees Cook To: "Serge E. Hallyn" Cc: Andy Lutomirski , Colin Walters , Linux Containers , Serge Hallyn , "linux-kernel@vger.kernel.org" , Seth Forshee , Stephane Graber , "Eric W. Biederman" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2170 Lines: 56 On Wed, Mar 9, 2016 at 11:07 AM, Serge E. Hallyn wrote: > 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 can run a distro kernel without kvm and sctp, because I can leave their modules unloaded. There is no such option for userns. The last af_unix CVEs I see were 2 from 2013, and before that, 2010. There's no comparison here on frequency. >> > 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? No, Eric refused it and wanted finer-grained controls. -Kees -- Kees Cook Chrome OS & Brillo Security