Messages in this thread | | | Date | Wed, 22 Oct 2003 18:57:36 -0700 | From | Andy Lutomirski <> | Subject | Re: posix capabilities inheritance |
| |
Michael Glasgow wrote: > Andy Lutomirski wrote: > >>Maybe I misread the spec, but I thought it explicitly stated >>pP' = (fP & X) | (fI & pI) >>(I can't find it right now, though...) > > > I don't see *any* rules for capabilities evolution explicitly > defined. There are some limitations and some mandatory characteristics > that any rules of evolution must possess, and these seem to make > sense to me as far as they go. But there's no explicit "pP' = blah"; > perhaps there needs to be.
Section 3, line 36 or so of my copy of POSIX draft 1003.1e gives:
I1 = I0 P1 = (Pf && X) || (If && I0) E1 = Ef && P1 [where P0 is pP and p1 is pP']
Not sure how relevant this is, though.
>>I would hope that, on a system that supports file capabilities, a >>file w/o capabilities set and w/o setuid would behave exactly like >>a file with some "default" capabilities. In my patch, these >>capabilities are (=ei). In mainline Linux, there is no such >>capability set (witness the logic in cap_binprm_set_security). > > > I agree for the most part, but why would you choose (=ei) rather > than just (=i)?
I don't really see the point of fE in any case, but, since traditional POSIX apps have no concept of disables capabilities, I figured that all capabilities enabled should be the default.
In any case, it could be useful to use (=i) to mean "this process shouldn't use capabilities by default" or (=ip) to mean "this process is privileged, but it shouldn't use those privileges without knowing what it's doing". Neither version seems to offer any real security benefit, but if (=i) were the default, then I don't see the benefit of (=ei).
> [...] Also, what in your opinion should be the meaning > of (fE != 0 && fP=0) versus (fE != 0 && fP = fE)?
fP (in my mind) means "this file gets these capabilities always" while fE means "if this file has these capabilities after exec evolution rules, then they should be enabled _unless they were already disabled." I could easily be convinced that I'm wrong, though.
>>With the (POSIX) rule pE' = pP' & fE, the dumpcap process would >>have been uid=0, euid=500, and all caps effective, which is >>inconsistant with traditional semantics. Linux currently works >>correctly because fE and fP are dependent on initial uid and euid. > > > I do not think that rule is specified by the POSIX 1003.1e draft > either, although it is compliant. Necessary distinction because > I believe we can change the rules in various ways and still be > compliant, if that is important.
I don't think it really matters, but I changed my patch to be closer to the rules quoted above. Remember that this draft is withdrawn.
> Also, it is clear that the inconsistency you point out is due to > your assumption that a file with no capabilities is (=ei) by default. > If it were (=i), then this problem goes away, right?
I think this just changes the problem. The POSIX rule (assuming my copy isn't bogus) gives pE = pP' & fE, which means that (if fE==0) any program that root wants to run with caps (most often CAP_DAC_OVERRIDE I presume) needs to either have fE explicitly set to full or be rewritten to enable its capabilities. This breaks userspace.
Andy
- 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/
| |