[cap-talk] Abstractions that subsume capabilities (was: Re: What sparked interest in capabilities)

[Jed Donnelley]

At 01:40 PM 3/7/2008, Karp, Alan H wrote:
>...
>You got my definitions of ZBAC and NBAC backwards...

Whew.  I sure messed that up.  Let me at least restate what I
was trying to say with the definitions as you want them.
The main point I was trying to make is that once one
accepts per subject access control (fine grained, POLA),
there is a naturalness/inevitability to the capability
paradigm that results from the Communicating Conspirators
"problem" (which I see in a positive light as the
"Inalienable Right" to communicate capabilities with data):

<First the correction and introduction:>

It seems to me that the relevant assumption for NBAC
(autheNtication based access control) is that all
active entities must be associated with an identity
whose roles or attributes can be used to make access control
decisions.  In a typical market leading OS (e.g. Windows or
Unix) processes maintain their association with an identity
by the rule that forks retain the same identity.  This of
course doesn't work across a network which acts more like
sending data through a pipe or TCP to a process with a
possible different identity.

What you refer to as ZBAC (authoriZation based access control) seems
to me an entirely different approach that goes off in another direction.
It still requires an *autheNtication* to start things off - so I really
don't see that distinction.  The key difference to me seems the way
authorizations are controlled for which subjects (active entities that
can make requests).  With capabilities (ZBAC) it is running programs
(with whatever "identity" or no identity) that are authorized or
not - depending on whether they have the required capability
(authoriZation) token.

<then to my main point, which sadly takes a bit to develop:>

With capabilities (ZBAC) authorization decisions are divorced
from identities are instead based on capabilities that can
be independently associated with subjects (active
objects/processes).  With ZBAC an *authentication* still provides
a bootstrap access to a collection of capabilities.  After that
there is some mechanism for transferring capabilities.  I could imagine
such a mechanism to be independent of the means for transferring data
(communicating messages).  One could even imagine 'simple' ACLs
on a per process basis.

In principle it seems possible to me to do such fine grained
access control, even including the notion of "ownership" (the
authority to make access right changes).  One could 'transfer'
access rights, including "ownership" or not, independently
of the ability to communicate.  This could get complex (as
Lampson argues), but in principle one could imagine something
like a shell or power box with ownership rights to all an identities
access rights somehow dealing them out to other processes, some of
which might get ownership access (the ability to manage the right
itself for other processes) or not.  This "dealing out" of access
rights would not (necessarily) happen as we think of them with
capabilities as essentially tokens in messages, but completely
independently as with entries in an access list mechanism - on
a per "process" (active entity/domain) basis (e.g. Lampson's
columns and rows discussion).

To me what gives discipline/strength to the capability paradigm
is exactly the communicating conspirators problem (my "inalienable
right").  Namely that if one subject is able to communicate to
another (OK, bidirectionally - lest we forget), then it can
proxy access in any case.  Because of this there is no (significant)
loss of generality in providing the ability to communicate an
access right exactly where data can be communicated.  This hugely
simplifies the number of options and variations for access
control management between processes.  So much so that our simple
"token" for access control that can be communicated is all that
is needed for full flexibility.  That such a paradigm also matches
up perfectly with the object oriented programming notions of an
object reference just adds that much more to the clarity of
the paradigm.

Sorry for butchering your definitions Alan.  I still think
the above point is worth noting.  This other point (below)
I believe to be an independent value of capabilities in
the network context where there may be no standards
for identities (beyond something introduction based
like Horton):

Of course the capability paradigm can also be used to
communicate access across the network between "identities"
rather than an identity based mechanism simply because all
identities in computer systems must have programs act
on their behalf, so capability tokens can be carriers of
access rights even between identities (read people) on
networks and even without any agreed upon standard of
identities.

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