[cap-talk] More Heresey: ACLs not inherently bad

[Jed Donnelley]

At 03:58 PM 9/10/2008, Charles Landau wrote:
>Jed Donnelley wrote:
> > At 08:30 PM 9/9/2008, Charles Landau wrote:
> >> Yes, the sub-directories must also be different, unless they happen to
> >> grant the same access...
> >> Each time you pass a different set of capabilities to a process, you
> >> construct a new directory-like object that will give access to that set.
> >> So in general, different processes will receive capabilities to
> >> different directory-like objects. It needn't use Horton.
> >
> > Unless I'm not understanding something, it seems to me that it
> > must be essentially Horton in that any capability fetched
> > through such a directory-like object given to "new process"
> > must inherit the "new-process"ness of the capability it was
> > given - so that future requests (e.g. more fetches) will return
> > "new process" labeled capabilities and so that in turn when
> > leaf node capabilities are finally returned they can have
> > the appropriately limited access (that which should be granted
> > to "new process" as opposed to "old process").
>
>This isn't Horton, because the "new process" is free to delegate its
>capability without any involvement of the directory-like object.

That depends on what capabilities the "new process" has.  If all of
it's capabilities pass through policy filters then it is 'confined'
to meet policy - as one might imagine with Horton.  Even with Horton
any process can communicate any capability that it has through any
other capability that it has - a fundamental capability property.
If a process can only communicate through a Horton tunnel, then
it's communicated capabilities will have their identity labels
transformed during the communication (through the id transforming
"tunnel":

http://www.usenix.org/event/hotsec07/tech/full_papers/miller/miller_html/#fig2

).  If not, then not.  It seems to me it's the same with the directory-like
object.  If a value being sought is to preserve the "new process"ness of
any fetched capabilities then such fetched capabilities should of course
inherit "new process"ness.  However, with such a scheme it seems clear
that at some point one will wish to communicate something with "new 
process"ness
to some other process and NOT have it inherit the "new process"ness.
That is when you want to communicate through a Horton id (-ness) transforming
tunnel.

>The directory-like object is just like a normal directory except that it
>is built on the fly. It's only purpose is to address Shap's concern that
>   building a complete directory at the time the new process starts is "a
>burden on program startup".

Except I thought I also heard you say that all fetched objects would
inherit the "new process"ness of the original directory-like object
given to new process - so "new process" related policies could be
enforced.  Of course new process can communicate directly if it has
unfiltered communication capabilities.  In that case any such
communicated capability will inherit the "new process"ness, even
if invoked by some other process.

It seems reasonable to me to assume that you don't wish the
whole world to act with "new process"ness.  If we agree on that,
then I think you are inevitably drawn into the issue of how to
communicate from one process to another when the -ness of the
sending process is not to be preserved.  Isn't that essentially
Horton?

--Jed  http://www.webstart.com/jed-signature.html