Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932860AbbERTo2 (ORCPT ); Mon, 18 May 2015 15:44:28 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:34479 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932824AbbERToE (ORCPT ); Mon, 18 May 2015 15:44:04 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Mon, 18 May 2015 12:43:42 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] capabilities: Ambient capabilities To: Christoph Lameter Cc: Jarkko Sakkinen , "Ted Ts'o" , "Andrew G. Morgan" , Andrew Morton , Serge Hallyn , Michael Kerrisk , Mimi Zohar , Linux API , Austin S Hemmelgarn , linux-security-module , Aaron Jones , LKML , Serge Hallyn , Markku Savela , Kees Cook , Jonathan Corbet 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: 2615 Lines: 66 On May 15, 2015 11:31 PM, "Christoph Lameter" wrote: > > It would be best to start a complete new thread about this. You > replied to earlier posts about ambient capabilities and > people may not see it as a new release. > > > pA obeys the invariant that no bit can ever be set in pA if it is > > not set in both pP and pI. Dropping a bit from pP or pI drops that > > bit from pA. This ensures that existing programs that try to drop > > capabilities still do so, with a complication. Because capability > > Ok that is a good improvement. > > > inheritance is so broken, setting KEEPCAPS, using setresuid to > > switch to nonroot uids, or calling execve effectively drops > > capabilities. Therefore, setresuid from root to nonroot > > conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set. > > Processes that don't like this can re-add bits to pA afterwards. > > > > The capability evolution rules are changed: > > > > pA' = (file caps or setuid or setgid ? 0 : pA) > > pP' = (X & fP) | (pI & fI) | pA' > > pI' = pI > > pE' = (fE ? pP' : pA') > > Isnt this equal to > > pE' = (fE & pP') | pA' > > which does not require conditionals and is symmetric to how pP' is > calculated. Your formula seems to indicate that pA' bits are not set if > fE is set. However they are already set unconditionally in pP' regardless. > This makes it more explicit I think. And I thought we are dealing with > bitmask arithmetic here? I think you're right, except that fE is a Boolean, not a bit mask, so fE | pP' is an odd thing to talk about. We could say (fE ? pP' : 0) | pA', which could simplify the code a tiny bit. > > > > If you are nonroot but you have a capability, you can add it to pA. > > If you do so, your children get that capability in pA, pP, and pE. > > For example, you can set pA = CAP_NET_BIND_SERVICE, and your > > children can automatically bind low-numbered ports. Hallelujah! > > I love this solution. > > > [2] The libcap capability mask parsers and formatters are > > dangerously misleading and the documentation is flat-out wrong. fE > > is *not* a mask; it's a single bit. This has probably confused > > every single person who has tried to use file capabilities. > > Hmmm... yes lets clean that up as well. Then your formula makes sense. > Maybe a follow-up patch to change the docs would be a good idea. --Andy -- 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/