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

[Jed Donnelley]

(It seems to me that this discussion has diverged enough that an
interactive discussion would be the best thing to clarify our
positions.  Feel free to give me a call (phone number under
separate cover) if you'd like to discuss this stuff interactively
Jonathan.  I expect our positions are more similar than they "sound"
in this email discussion.)  Still, I continue:

At 06:54 PM 8/30/2008, Jonathan S. Shapiro wrote:
>On Sat, 2008-08-30 at 18:37 -0700, Jed Donnelley wrote:
> > Sorry, but I don't understand what you mean when you suggest that
> > "it is very difficult to transfer a subset of authority represented
> > by a capability system."  Of course with capability systems
> > (even if implemented using an underlying ACL mechanism), it
> > is always easy to transfer a subset of the authority - simply
> > by transferring only the capabilities desired (even if this is
> > done by changing ACLs).
>
>It is very easy in a capability system to transfer O(1) authorities. But
>once you get much above that you find that you need to introduce some
>form of namespace for the capabilities being transferred. This is, in
>essence, a file system.

Hmmm.  So saying suggests to me that you have a much more restrictive
notion of what you mean by a "capability system" than I do.  Consider
the E language for example - or any OO language for that matter.
There what consists of a "capability" is essentially a pointer
that can be named as with any other language object.  Such objects
as parameters occur quite frequently in numbers other than
0 or 1.

In many other systems that I consider capability systems (e.g.
all the "password" capability systems - Amoeba, NLTSS, Monash,
etc.) capabilities are just blocks of data and so can appear
in messages in any number and named in any way convenient.

I believe the sorts of capability systems in which it is
only possible to easily transfer 0 or 1 authorities are
relatively rare - though the family that traces through
the PDP-1 system, RATS, GNosis, KeyKOS, etc. seems to fall
into that category.  For those systems I've always thought
the most convenient way to communicate n for n > 1 capabilities
was to put them into a directory (c-list) and communicate
a capability to the c-list.

>If you want to transfer the entire file system
>then we are back to the O(1) simple case. Unfortunately, if you want to
>transfer some subset of a large collection, you are forced to
>dynamically build a large collection.

For that particular family of systems it seems so.  That seems
to me more a criticism of that family of systems rather than
capability systems in general.

>This is, in effect, the construction of a dynamically created principal
>id, and it is hard regardless of which representation you decide to use.

Perhaps I'm not fully following your terminology, but I don't
believe I agree with the above statement.  It seems that you're
suggesting that any bundling of objects (e.g. into a directory,
c-list, array, linked list, or any other form of records)
constitutes the use of a "principal id".  The essence of the
"principle id" notion to me is that the object references
can be communicated independently of the principal id but
are only valid in the presence of the principal id.  That
is a separation of designation and authorization.  When
communicating a bundle of capabilities in a directory or
c-list or ... there is no such separation.  The directory
is one capability, the capabilities in the directory are
others, but in all cases designation and authorization come
together.

>This is why filtering emerges as a preferred solution.

I don't understand why.  To me 'filtering' (as with the
power box) is an independent mechanism that occurs at the
user interface.  It doesn't even apply in the normal
function/module call interface.

> > While it may be convenient in the sort of "principle"
> > based systems to communicate a principle by default when something
> > a fork/exec is done, the real problem is that there are only two
> > alternatives:
> >
> > 1.  Communicate the whole principle, or
> > 2.  Communicate only individual authorities/capabilities.
>
>Because of the construction costs that I outline above, I claim that
>precisely the same issue arises in capability systems.

And I hope my discussion above clarifies why I disagree with
that position.

> > Whether propagated by default or not it seems to me that any
> > propagation of "namespace capabilities" (principles) is
> > 'damaging'.
>
>Perhaps. Yet it is necessary.

Again I hope it's clear how our positions differ.  I have no
problem with communicating a set (n > 1) of needed
authorities as capabilities.  If this must be done in
a c-list or directory or array, fine.  However, separating
the designation ("name"?) from the authorization (a separate
"principal" - whether as a capability or not) seems to me
gives rise to all the problems (non POLA, confused deputies,
etc.) of typical ACL systems.

>The question becomes: how effectively can
>cacheing be exploited in the construction of name spaces.

You seem to be addressing performance issues.  I've not touched
on that topic and have only been addressing functionality.

> > >From a usability perspective, the best mechanism we have come up with
> > >for bulk propagation and protection of authorities has been the power
> > >box.
> >
> > Hmmm.  I thought the best mechanism for the bulk propagation and
> > protection of authorities was the "directory" (c-list, call it
> > what you will)....
>
>But a directory is just a name space!

Hmmm.  I think agree, but I'm not sure what you mean by "just".
If I send you a directory full of capabilities I am giving you
the right to access those capabilities in the directory.
To access any one you just fetch it from the directory by
name and then invoke it.  In the same sense an array or
a hash is "just a name space", but if it is an array or
hash of capabilities (think capabilities as data for a
moment) then the bundled structure conveys a bundle
of authorities (capabilities).

> >   I think of the "power box" mechanism as a
> > user interface mechanism that allows a user communicating to
> > a powerful process (e.g. a "shell") to communicate explicit
> > capabilities to another process (an "application" process)
> > under control of the user (person) communicating interactively
> > with the power box process.
>
>I claim that this is not so. I claim that in practice a powerbox is a
>mechanism for performing lazy namespace construction.

I've only been exposed to what I heard of as 'powerbox' implementations
in two instances, Capdesk and Plash.  In both cases I believe the
intent was to allow a user to selectively grant access to capabilities
to a running application.  To me this is quite different than
"lazy namespace" construction.  Perhaps you can describe instances
that have been described as 'powerbox's (e.g. the above two) and
in what sense they seem to you to constitute 'lazy namespace's.

> > I agree that ACLs can be used to implement capability
> > semantics that will address POLA and Confused Deputy
> > needs.  What is fundamentally needed is access control
> > based at the level of individual processes (active objects).
>
>This is precisely what Plan 9 did. In plan 9, there is no universal
>filesystem root. Namespaces can be constructed on a per-process basis,
>and can be mediated through user-level file systems.

The difficulty that I believe such systems face is in providing
effective (convenient, efficient, etc.) communication of
individual and/or small collections of authorities ("capabilities").
At some point there must be a mechanism to bind the principal
to the authority.  There must also be a means for altering that
binding.  In my experience such mechanisms quickly become
awkward.  We did such an implementation in NLTSS (one of our
means of avoiding the data theft concern for password
capabilities) and it proved so awkward that it was never
used in production systems.

> > ACL systems typically don't provide such a fine level of
> > control...
>
>I fully agree. The main pragmatic value of ACLs seems to be dealing with
>group sharing.

Hmmm.  To me group sharing is just as easy with capability systems.
Creating a "group" is as simple as creating a directory.  Just
share it with the "group".

I've always though the main reason people pushed for ACL systems
(e.g. P-1935 and all the security concerns) was to:

1.  Avoid the problems of "loose" capabilities - that is to
be able to give a process an authority without having to give
it the right to share that authority, and

2.  To be able to "easily" determine "who" has access to
an object by looking at the object itself (the ACL).

3.  Provide for revocation without having to support the sort
of active mechanism that we know capability systems depend on.

If you push ACL systems down to the process level (vs. staying
at the high level of a person = id) then I believe the above
advantages/motivations disappear.  That is why I've always
supported capability systems for POLA.

>My point in the preceding line of argument is that the
>presence of a principal based scheme need not be fatal in the presence
>of a per-process namespace mechanism and namespace mediation,

Not fatal perhaps, but to me unnecessarily complicated since I
see no added value - which brings us to:

>but the
>hybrid approach may offer application portability options that cannot
>otherwise be achieved.

I don't see any "application portability" added value.  Perhaps you can
explain what you mean there.

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