On Fri, Dec 7, 2012 at 9:07 AM, Andrew G. Morgan <mor...@kernel.org> wrote: > I'm still missing something with the problem definition. > > So far if I follow the discussion we have determined that inheritance > as implemented is OK except for the fact that giving user an > inheritable pI bit which gives them default permission to use all > binaries endowed with the corresponding file fI bit.
This is IMO part of the problem but not the entire problem. > > Is this the problem a different inheritance model is supposed to > address? Serge suggested that the binary could authenticate the > user... This seems like its putting the protection in the best > place... Each app can control its sub functions with the richest > semantics. > > That being said... > > To me this looks like it's an access control problem... Namely use > acls to limit which users (groups) can execute each privileged binary. > Serge's option 2 seems like a similar approach. > The issue is (as I see it) with non-privileged binaries. If a given program (correctly) has a permitted capability and is not root, then the only way that it can pass that capability on to children (e.g. helper programs) is to set it into pI. This only works if the child has the same bit set in fI. This is doable but annoying -- every program that a privileged program runs needs to be authorized by the administrator. It breaks down because, currently, users with nonzero pI have no direct ability to wield the capabilities. That means that every single binary with fI bits set needs to be as careful as a setuid-root binary to avoid leaking privilege to the caller. (Obviously, binaries with fP set need to be careful. IMO binaries with only fI set should not need to exercise any particular care to defend themselves from their callers.) I'm obviously missing some fundamental (and probably historical) issue here, so let me ask the following straw-man question. Suppose capabilities worked like this on exec: pP' = pI | (fP & pB) (i.e. the current way, except that fI always has all bits set for every binary on the system) pI' = pI (unless !SECURE_NOROOT and uid == 0 or euid == 0, in which case pI' = pP') with the added restriction that pI is always a subset of pP (i.e. dropping a bit from pP (on exec or otherwise) drops that bit from pI). What would be wrong with this model? (Let's pretend for now that capabilities had always worked this way, so there's no change of behavior to worry about.) - The sendmail capability bug wouldn't happen: pI has no effect on setuid-root binaries. - There would be no difference between a user being trusted with a capability and being inh-trusted with that capability, since the latter concept wouldn't really exist. - Totally unprivileged users couldn't engage in any funny business. Their pI masks would be zero, and they would have no way of changing that. - Partially privileged users would work just fine. They could wield their capabilities (subject to some possible fiddling with pE) from bash or from anything else. They could also freely drop those capabilities. - Privileged programs would require less thought: to grant a program, you set its privilege in fP. There is no fI, so there's nothing special to think about. NB: This is not a real proposal because there *are* capability-aware programs out there. I want to understand why the current system is so different. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
