[cap-talk] Capabilities and RBAC (was Comprehensive Security Policies ...)

[Jed Donnelley]

At 08:52 AM 1/17/2007, Karp, Alan H wrote:
>Jed wrote:
>...
>In an IBAC system a role is just another identity as far as the access
>control mechanism is concerned.  Horton, on the other hand, is about
>assigning responsibility.  Since it's hard to send a role to jail, I
>don't see the value of using Horton to track roles.

> > This is an area where we can easily demonstrate that
> > capabilities are flexible, but of course with such flexibility comes
> > the responsibility not to tie yourself into knots.  I can see how
> > getting into the business of managing individual permissions on
> > a "role" basis would get messy.  I think I won't mention RBAC
> > while describing Horton ;-)  Thanks for helping to clarify the issues.
>
>I see that you agree.

I do.  However, I hope we also still agree that Horton can be used
to "manage" bundles of permissions by identity.  Horton is indeed
concerned with assigning responsibility, but it can also be used
to permit or deny the access that has been delegated with such
responsibility tracking.

That was what the whole discussion about

Admin -> Alice -> Bob -> Carol
(where -> denotes delegation with responsibility tracking via Horton)

and then access by Bob is revoked.  Since the capabilities with
responsibility tracking (Horton) are labeled, all those as labeled
for use by Bob can be revoked and become invalid.  However, as
we discussed previously, if Alice or Admin choose to do so, those
capabilities delegated via Horton to Carol can be enabled (or
re enabled) despite Bob's being revoked.

I believe there is administrative value in such a mechanism that
may well appeal to some people who think in terms of identities
for access control.  I also believe a mechanism like this suggests
a sort of flexibility to capabilities that most people are completely
unaware of.

Just to again be clear, however, the Horton mechanism is pure
capability.  That is, there is no sense of identity that comes with
an invocation from any active object (process) or same that's run
by a "user" (ambient authority).  All the identities that show up
above are bound to capabilities through the Horton protocol
when a "responsibility" delegation happens (by pure capability
means) and then those labeled capabilities continue to be
delegated by normal capability message communication.

> > Wholesale denial of access is easy if there's an easily recognized
> > label to identify (e.g. like cutting off access to "Bob").
>
>This problem motivated the keys and locks approach of Client Utility,
>which did not depend on identity.  We didn't understand membranes at the
>time, but I now believe that they can be used to manage bundles of
>capabilities without the need for identities.

Horton uses the membrane mechanism and binds it to a capability
based "identity" notion (that can be associated with people) to allow
responsibility logging and the limited sort of identity based access
control that's possible with capabilities (namely recognizing
and even facilitating "communicating conspirators" for the modular
decomposition value - POLA - that doing so provides).

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