From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755953AbdKJEaO (ORCPT ); Thu, 9 Nov 2017 23:30:14 -0500 Received: from h2.hallyn.com ([78.46.35.8]:40566 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755577AbdKJEaL (ORCPT ); Thu, 9 Nov 2017 23:30:11 -0500 Date: Thu, 9 Nov 2017 22:30:10 -0600 From: "Serge E. Hallyn" To: Mahesh Bandewar =?utf-8?B?KOCkruCkueClh+CktiDgpKzgpILgpKHgpYfgpLXgpL4=?= =?utf-8?B?4KSwKQ==?= Cc: "Serge E. Hallyn" , Mahesh Bandewar , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller Subject: Re: [PATCH resend 1/2] capability: introduce sysctl for controlled user-ns capability whitelist Message-ID: <20171110043010.GA3572@mail.hallyn.com> References: <20171103004433.39954-1-mahesh@bandewar.net> <20171109172201.GA26229@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com): ... > >> > >> ============================================================== > >> > >> +controlled_userns_caps_whitelist > >> + > >> +Capability mask that is whitelisted for "controlled" user namespaces. > >> +Any capability that is missing from this mask will not be allowed to > >> +any process that is attached to a controlled-userns. e.g. if CAP_NET_RAW > >> +is not part of this mask, then processes running inside any controlled > >> +userns's will not be allowed to perform action that needs CAP_NET_RAW > >> +capability. However, processes that are attached to a parent user-ns > >> +hierarchy that is *not* controlled and has CAP_NET_RAW can continue > >> +performing those actions. User-namespaces are marked "controlled" at > >> +the time of their creation based on the capabilities of the creator. > >> +A process that does not have CAP_SYS_ADMIN will create user-namespaces > >> +that are controlled. > > > > Hm. I think that's fine (the way 'controlled' user namespaces are > > defined), but that is design decision in itself, and should perhaps be > > discussed. > > > > Did you consider other ways? What about using CAP_SETPCAP? > > > I did try other ways e.g. using another bounding-set etc. but > eventually settled with this approach because of main two properties - No, I meant did you try other ways of defining a controlled user namespace, other than one which is created by a task lacking CAP_SYS_ADMIN? ... > >> +The value is expressed as two comma separated hex words (u32). This > > > > Why comma separated? whitespace ok? Leading 0x ok? What is the > > default at boot? (Obviously the patch tells me, I'm asking for it > > to be spelled out in the doc) > > > I tried multiple ways including representing capabilities in > string/name form for better readability but didn't want to add > additional complexities of dealing with strings and possible > string-related-issues for this. Also didn't want to reinvent the new > form so settled with something that is widely used (cpu > bounding/affinity/irq mapping etc.) and is capable of handling growing > bit set (currently 37 but possibly more later). Ok, thanks.