Received: by 10.223.164.202 with SMTP id h10csp3652755wrb; Tue, 28 Nov 2017 15:05:34 -0800 (PST) X-Google-Smtp-Source: AGs4zMb3oml5OyMv0+jou3mOUYvajQq50feGVPDuMA1CJEcEqJf8k3N7xsF80sGL+EwJwcI7GmgI X-Received: by 10.98.245.68 with SMTP id n65mr782941pfh.113.1511910333907; Tue, 28 Nov 2017 15:05:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511910333; cv=none; d=google.com; s=arc-20160816; b=hUp+Q4qEyPNQGINMDTBz8qYz8KigUeg0HnVMmoJ8A4yjcjw3TqvpqT1omkeKNH/gG1 2pti4ZuITck6Jd/RpNeV0qvqEFbOB8pJZu5GBoAs/Baq/nsZvFD36iWQ9mtewX6bSlDG T2SfpbRTiWsvOsQn+48oCu+WqpA/0rFlCF8ArCFWMYDp8NYKGUiUQYjca8+vLIW3Imwm 6XwKOPjcwLU2WJXKofFn4TSbLkKYky6NUFNM8PoFj7NNupkuyJSAm2Lcz8dvKEIQqL3B JNcTTJFEG/6F4S7Bei3pnwuqRw7WGukLv1vly5fvlOPbjuIpXv4aMszlCqd9fSFtqXqv H9Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=x0OQjb9DvtxCDyEYdTo9BvPTFyxm8PTUeT8yXKokNe8=; b=tMHcG0qYtH9y/Y9I3gmYUhAuKQ9Oy5XyJJr/SfDe+pBzMiGtMvwddoOKZJlhdlMo6F tYlr95nnDLbjywqyumRIuzEAZB4Z9S1MxINlvmhG8Kvf64SWuxVxKFsaGSQOB6ciFYxV L+/wRk0xUnrpVU4avRbZFbMelqvFjpo8uGj+wrgwPtGSfBFCTAyh2xADqUvaRVpKuuE4 F2F7bhJ63WwtTI91GfQ+PypwK+DjL9IXvy3+zrbfHwAKaiitq9mwNnGrRynsQJptWh3i d6GSlEMeMHh3jNLoXUYV9wbRBhc+DRvvxdB4K3EFsvntfST22ehLdpTBSaAirAFaT+Qw cwHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3si213570plb.153.2017.11.28.15.05.23; Tue, 28 Nov 2017 15:05:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753224AbdK1XEn (ORCPT + 70 others); Tue, 28 Nov 2017 18:04:43 -0500 Received: from h2.hallyn.com ([78.46.35.8]:36418 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbdK1XEl (ORCPT ); Tue, 28 Nov 2017 18:04:41 -0500 Received: by h2.hallyn.com (Postfix, from userid 1001) id 65F38120219; Tue, 28 Nov 2017 17:04:40 -0600 (CST) Date: Tue, 28 Nov 2017 17:04:40 -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: [PATCHv2 2/2] userns: control capabilities of some user namespaces Message-ID: <20171128230440.GB28297@mail.hallyn.com> References: <20171110053757.21170-1-mahesh@bandewar.net> <20171126064037.GB30279@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@google.com): ... > >> diff --git a/security/commoncap.c b/security/commoncap.c > >> index fc46f5b85251..89103f16ac37 100644 > >> --- a/security/commoncap.c > >> +++ b/security/commoncap.c > >> @@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns, > >> { > >> struct user_namespace *ns = targ_ns; > >> > >> + /* If the capability is controlled and user-ns that process > >> + * belongs-to is 'controlled' then return EPERM and no need > >> + * to check the user-ns hierarchy. > >> + */ > >> + if (is_user_ns_controlled(cred->user_ns) && > >> + is_capability_controlled(cap)) > >> + return -EPERM; > > > > I'd be curious to see the performance impact on this on a regular > > workload (kernel build?) in a controlled ns. > > > Should it affect? If at all, it should be +ve since, the recursive > user-ns hierarchy lookup is avoided with the above check if the > capability is controlled. Yes but I expect that to be the rare case for normal lxc installs (which are of course what I am interested in) > The additional cost otherwise is this check > per cap_capable() call. And pipeline refetching? Capability calls also shouldn't be all that frequent, but still I'm left wondering... From 1585346534208812755@xxx Tue Nov 28 21:24:32 +0000 2017 X-GM-THRID: 1583656299755400145 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread