Linda Walsh wrote:
> > -----Original Message-----
> > From: parsley@roanoke.edu [mailto:parsley@roanoke.edu]
> >
> > After following this thread for a bit, I've got one burning question:
> > What are the formulas for computing the capability sets of a new process
> > in Trusted IRIX? I've also got a copy of Draft 17 (thanks, Casey!), and
> > I'm quite pleased with:
> >
> > pI' = pI (& fM (*)) ; pP' = fP | (fI & pI) ; pE' = pP' & fE
> ---
> So why is fM not fI?
Because they have different purposes; fI determines which bits in the
original pI can be inherited in pP', fM limits pI' to prevent unwanted
inheritance effects in children.
> The formula Trusted IRIX uses (see it online at
> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat4/capabilities.z )
Thanks! Very interesting.
> pI' = pI & fI ; this allows a file to restrict capabilities passed on as
> well as the original process. [Desired]
Ok, and in the model I outlined a cap-aware parent process could drop
it's own pI bits to restrict inheritance in the child.
> according to the wording in section 25.1.1.2:
> "Each capability marked as _permitted_ [pP'] may have
> been forced to be set by the program file [pF] or inherited
> from the previous image [pI] (if the capability attributes
> of the program file allow the inheritance [pI]."
>
> pP' = fP | (pI' & pP); this limits inheritance of previous process Permitted
> capabilities by the "Inheritable masks" of *both*
> the file & the previous process's
>
> pE' = pP' & fE ; limits effective by permitted at exec time
Ok, with pP' = fP | (pI' & pP), this means that for a child process to
have some bit in pP', that bit must have been either raised in the
parent, or the bit must be explicitly raised in fP (similar in concept
to being setuid root); i.e., in the absence of fP<>0 the parent must
have a capability which it itself doesn't need, though it's child does.
I thought it was clever, and even pleasant, that the child could inherit
a pP bit that wasn't present in the original process. In fact, my first
example scenario demonstrates this idea, and the parent process doesn't
have capB which is required by the child.
It's feasible to imagine a parent process which utilizes the services of
a variety of helper programs to accomplish it's job; say four programs,
which require capA, capB, capC and capD, respectively. Now, with the
model shown above (IRIX), these programs must either have these bits
explicitly raised in fP (which to me is essentially 'setuid root'), or
they must have been raised in the parent, which itself didn't need
them. So a buffer overflow in the parent process could execute syscalls
that take direct advantage of capA, capB, capC & capD, or could exec a
binary which would 'legitimately' inherit them.
In the model I proposed (draft17 + f/pM), only the second applies; i.e.,
exec'ing a binary with 'legitimate' inheritance. And, if fM -> pM',
(such pM' & pP make an upward limit on pI), then the parent could have
pP bits which it itself needs but can't get passed to children.
<me takes a long break and does some searching> OK, I found the quote I
wanted describing this behavior of the inheritable set. From Andrew G.
Morgan's 'Linux-Privs' document
(http://www.mirror.ac.uk/sites/ftp.kernel.org/pub/linux/libs/security/linux-privs/doc/linux-privs.html/linux-privs.html):
<quote>Turning off a capability set in the Permitted set does not affect
its status in the Inheritable set. The following is apparently a quote:
(draft 13 of POSIX .1e) POSIX B.15.1.9
"The corresponding inheritable flag is not affected, so that privileges
can be conditionally transmitted along a process chain whose
intermediate processes <em>may themselves have no privileges</em>"
(N.B. At this stage in the development of the POSIX standard,
capabilities were termed privileges.) So if you want to turn off the
capabilities in the Inheritable set, you should explicitly turn it off,
not just turn it off in the Permitted set.</quote>
<em> added by me. I thought this was a cool concept, but I couldn't
find this in my copy of draft 17. Still, when I read the 'Examples' in
section B.25.7 of draft 17, it clearly showed this idea.
Sigh. This stuff reads like a bad physics text. This discussion would
REALLY benefit from all of us being in the same room together with a
good chalkboard and some good beer. I've tried discussing capabilities
via e-mail before, but it just stinks.
regards,
David
-- David L. Parsley Network Administrator Roanoke College- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:25 EST