Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934690AbbEOObi (ORCPT ); Fri, 15 May 2015 10:31:38 -0400 Received: from resqmta-ch2-09v.sys.comcast.net ([69.252.207.41]:52430 "EHLO resqmta-ch2-09v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754794AbbEOObb (ORCPT ); Fri, 15 May 2015 10:31:31 -0400 Date: Fri, 15 May 2015 09:31:27 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Andy Lutomirski cc: Serge Hallyn , Andrew Morton , Jarkko Sakkinen , "Ted Ts'o" , "Andrew G. Morgan" , Linux API , Mimi Zohar , Michael Kerrisk , Austin S Hemmelgarn , linux-security-module , Aaron Jones , Serge Hallyn , LKML , Markku Savela , Kees Cook , Jonathan Corbet , Andy Lutomirski Subject: Re: [PATCH v2 1/2] capabilities: Ambient capabilities In-Reply-To: Message-ID: References: Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2195 Lines: 54 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? > 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. -- 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/