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

[Jed Donnelley]

At 02:10 PM 3/6/2008, Karp, Alan H wrote:
>Jed wrote:
> >
> > Hmmm.  I spent a bit of time looking around on the Web and
> > didn't find anything that I would consider a 'taxonomy' for
> > access control schemes.
>
>I'm working on a study group for the Navy chartered with creating a 
>position paper on SOA IA Security.  (Services Orientented 
>Architecture Information Assurance, for you non-military types.  I 
>usually apologize for the lack of acronyms in my notes to that 
>group.)  They use DAC/MAC to describe who determines access and IBAC 
>(identification), RBAC (role), ABAC (attributes) to define the 
>authentication used to make an authorization decision.  Because of 
>the acronym collision, we use NBAC (autheNtication) for the those 
>three and ZBAC (authoriZation) for what I'm pushing.  That's sort of 
>a 2-dimensional taxonomy.

Am I wrong in considering RBAC and ABAC really just forms of IBAC?
That is, they are all properties of an identity -> an 'authentication'.
If access is controlled for a "role" it is controlled for identities
that (who?) have that role.  If access is controlled for an "attribute",
it is controlled for identities with that attribute.  As you say it
is really controlled for anybody/thing that can authenticate to
an identity - and then for roles or attributes associated with the
identity.

It seems to me that the relevant assumption for ZBAC 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 NBAC (autheNtication 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 (NBAC) it is running programs
(with whatever "identity" or no identity) that are authorized or
not - depending on whether they have the required capability token.

With capabilities (NBAC?) authorization decisions are divorced
from identities are instead based on capability (authorization?)
that can be independently associated with subjects (active
objects/processes).  With NBAC an authentication still provides
a bootstrap access to a collection of capabilities (authorizations sound
too much more like actions rather than like tokens to me).  After that
there is some mechanism for transferring capabilities.  I could imagine
such a mechanism to be independent of the means for transferring data.

In principle it seems possible to me to do fine grained access control
on a per process (I'm going to stick with that term - it can be
resolved to any active subject at will) basis - even with such
notions as "ownership".  One could 'transfer' access rights,
including "ownership" (the authority to make access right changes)
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.

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