lkml.org 
[lkml]   [2003]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.021 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site