From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC] capabilities: Ambient capabilities Date: Sat, 14 Mar 2015 15:53:27 -0700 Message-ID: References: <933931146caf5dac58379f50c017bff9f6c47661.1426183417.git.luto@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Andrew G. Morgan" Cc: Jarkko Sakkinen , Ted Ts'o , Andrew Lutomirski , Andrew Morton , Michael Kerrisk , Mimi Zohar , Linux API , Austin S Hemmelgarn , linux-security-module , Aaron Jones , Christoph Lameter , LKML , Serge Hallyn , Markku Savela , Kees Cook , Jonathan Corbet List-Id: linux-api@vger.kernel.org On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan wrote: > On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski wrote: >> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan wrote: >>> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski wrote: >>>> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" wrote: >>>>> >>>>> > It's to preserve the invariant that pA is always a subset of pI. >>>>> >>>>> But since a user can always raise a bit in pI if it is present in pP, >>>>> what does this invariant add to your model other than inconvenience? >>>> >>>> The useful part is that dropping a bit from pI also drops it from pA. >>>> To keep the model consistent, I also require that you add the bit to >>>> pI before adding it to pA. >>> >>> So you are saying that pA is always a strict subset of pI (and pP)? >>> Then why not explicitly implement it as: >>> >>> pA' = (file caps or setuid or setgid ? 0 : pA) >>> pP' = (fP & X) | (pI & [fI | (pA' & pP)] ) >>> >>> As it is you have so distributed these constraints that it is hard to >>> be sure it will remain that way. >> >> That would be insecure. If an attacker had pA = CAP_SYS_ADMIN, pI = >> 0, pP = 0 (i.e. no privs but pA is set somehow) then, unless that's >> there's some other protection implemented, they could run some setuid >> program, and that program could switch back to non-root, set pI = 0, >> and call execve. Unexpectedly, CAP_SYS_ADMIN would be inherited. > > Forgive me, but which bit of > > pI & [fI | (pA' & pP)] > > with pI = 0 makes that so? Oh, I misread that. I think it's already unnecessarily confusing that you can inherit nonzero pI without inheriting the corresponding bits in pP, and I don't want to add yet more degrees of freedom in non-permitted caps. >>>> >>>> I don't know what you mean here by naive privilege inheritance. The >>>> examples you're taking about aren't inheritance at all; they're >>>> exploring privilege *grants* during execve. My patch deliberately >>>> leaves grants like that alone. >>> >>> The pI set is inherited through this exec unmolested. >> >> This is flat-out useless. Having pI = CAP_NET_BIND_SERVICE doesn't >> let me bind low-numbered ports, full stop. > > Even in your proposed model, neither pI nor pA does this. It is what > is in pE that counts. Let me state it more precisely. If your parent puts CAP_NET_BIND_SERVICE in pI and execs you, you can't bind low-numbered ports. If your parent puts CAP_NET_BIND_SERVICE in pA, you can. > >>> My Nack remains that you are eliminating the explicit enforcement of >>> selective inheritance. A lockable secure bit protecting access to your >>> prctl() function would address this concern. >> >> Would a sysctl or securebit that *optionally* allows pA to be disabled >> satisfy you? >> >> I don't understand why lockable is at all useful. You'd need >> CAP_SETPCAP to flip it regardless. > > Because it means one can create process trees in which this behavior > is guaranteed to be allowed and/or disallowed. > I don't see why guaranteeing that it's allowed is particularly useful. I also don't see why any of the securebits lock bits are useful. I don't specifically object; I just don't see the point. If you give a subtree CAP_SETPCAP but you don't trust them enough to leave securebits unlocked, then I think your threat model is confused. --Andy