On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote: > On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote: >>> On Fri, Mar 13, 2015 at 10:57 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>> On Mar 13, 2015 6:24 AM, "Andrew G. Morgan" <morgan@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
