On Fri, Dec 7, 2012 at 10:39 AM, Andy Lutomirski <l...@amacapital.net> wrote: > 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.
Yes. > This is doable but annoying -- every program that a privileged program > runs needs to be authorized by the administrator. Yes. > 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.) True. But what about protecting the system from privileges they didn't expect to have? > 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. Are you saying that setuid-root is required for a program like sendmail to work? Forever? > - 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. See below. It's key to see that it is not people, but programs that require privilege. > - 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. I think you have correctly determined a key difference (a fundamental feature!) of the model. For an explanation, please search for "key insight" in the OLS paper: http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf Also, see p310+ of the first document linked to on the page Casey pointed to: http://wt.tuxomania.net/publications/posix.1e/download.html which has quite an elaborate explanation of how this model was designed, and what the authors were trying to achieve. Cheers Andrew > > --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/
