posix capabilities inheritance
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Andy Lutomirski
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.
Quoted 5 lines
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)? Also, what in your opinion should be the meaning of (fE != 0 && fP=0) versus (fE != 0 && fP = fE)?
Quoted 4 lines
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.
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?
--
Michael Glasgow < glasgow at beer dot net >
Quoted 7 lines · Michael Glasgow
Quoted 3 lines · Andy Lutomirski
Maybe I misread the spec, but I thought it explicitly stated pP' = (fP & X) | (fI & pI)
(I can't find it right now, though...)
Quoted 5 lines
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.
Quoted 9 lines
Quoted 5 lines
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).
Quoted 2 lines
[...] 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.
Quoted 10 lines
Quoted 4 lines
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.
Quoted 3 lines
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