Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161020AbbBDVcM (ORCPT ); Wed, 4 Feb 2015 16:32:12 -0500 Received: from mail-la0-f42.google.com ([209.85.215.42]:36394 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932213AbbBDVcJ (ORCPT ); Wed, 4 Feb 2015 16:32:09 -0500 MIME-Version: 1.0 In-Reply-To: <20150204212743.GA21475@mail.hallyn.com> References: <20150204211617.GA20787@mail.hallyn.com> <20150204212743.GA21475@mail.hallyn.com> From: Andy Lutomirski Date: Wed, 4 Feb 2015 13:31:47 -0800 Message-ID: Subject: Re: [RFC] Implement ambient capability set. To: "Serge E. Hallyn" Cc: Christoph Lameter , "Andrew G. Morgan" , Serge Hallyn , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , lkml , Andrew Morton 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: 2209 Lines: 50 On Wed, Feb 4, 2015 at 1:27 PM, Serge E. Hallyn wrote: > Quoting Andy Lutomirski (luto@amacapital.net): >> On Wed, Feb 4, 2015 at 1:16 PM, Serge E. Hallyn wrote: >> > Quoting Andy Lutomirski (luto@amacapital.net): >> >> On Wed, Feb 4, 2015 at 10:49 AM, Christoph Lameter wrote: >> >> > + >> >> > + if (!cap_valid(arg2)) >> >> > + return -EINVAL; >> >> > + >> >> > + new =prepare_creds(); >> >> > + if (arg3 == 0) >> >> > + cap_lower(new->cap_ambient, arg2); >> >> > + else >> >> > + cap_raise(new->cap_ambient, arg2); >> >> > + return commit_creds(new); >> >> > + >> >> >> >> This let you add capabilities you don't even have to cap_ambient. I'm >> >> fine with that as long as the cap evolution rule changes, as above. >> > >> > How about if instead we do restrict it to what's in pP? I don't >> > want CAP_SETPCAP to become a cheap way to get all caps back. With >> > or without NNP. >> >> We'd also have to modify everything that can change pP to change pA as >> well if we went this route. I'd be okay with that, but it would make >> the patch much larger, and I'm not entirely sure I see the benefit. >> It would keep the number of possible states smaller, which could be >> nice. > > Do you mean if we didn't require NNP? I'm suggesting that even if > we require NNP we should restrict any new bits added to pA to be > in pP at the prctl call. Then whether or not to drop them from > pA when they are dropped from pP, I'm not yet certain. I mean regardless of whether we require NNP. I think that, unless we change the evolution rule, we would need to drop from pA when bits are dropped from pP to preserve the idea that dropping bits from pP drops them for good (as long as ruid != 0 or some securebit is set). -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/