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

[Jed Donnelley]

At 05:05 PM 1/16/2007, Karp, Alan H wrote:
>RBAC ...introduces problems
>
>... role mismatch...
>
>... role explosion...

Yep.  There's no free lunch.  Bottom line (from below, read more for
thought process and details): I think I won't mention RBAC when
describing Horton.

>The nice thing about capabilities is that they can be combined
>dynamically to solve the problem that RBAC was supposed to solve but
>doesn't.  I don't see a lot of value (other than political) in trying to
>build RBAC mechanisms in a capability system.  Simply construct a bundle
>of capabilities given to whomever is supposed to do a particular job,
>and revoke them when that person changes jobs.  You can call the
>revoking forwarder a role if your customer insists on roles.  I believe
>that's what people on this list mean, but it's not RBAC in the sense
>that the rest of the world understands it.

How does it differ?  In more than conspiring communicators (i.e.
delegation where communication)?

When I suggested that Horton could do RBAC as well as IBAC over
capabilities, what I was really saying is that for it a label is a label
(though the binding to an identity has some functionality to it).  It
doesn't really matter (once the binding is done) what the purpose is
of the "managed" access - whether managing for an identity or managing
for a role.

As far as role mismatch goes, the access granted to the role could
change when a new person assumes a role through something
like Horton.  <However, I think that would be awkward> in that the upstream
management would then have to get into the business of recognizing
individual permissions.  That's probably a bad idea.

Regarding role explosion: There's certainly no suggestion that
people should be limited to a single role or that they shouldn't
have individual capabilities granted outside any role control.

If you're going to grant capabilities to a person and you want to
be able to revoke them selectively then there's going to be a cost
for such selective revocation regardless of whether they're bundled
together into a "role" or whether they're considered on the basis
of the person's identity and organizational relationship.

Wholesale denial of access is easy if there's an easily recognized
label to identify (e.g. like cutting off access to "Bob").

As we are considering Horton for "IBAC" (or something similar
to it using a pure capability infrastructure) the mechanism that
we imagined was independent of specific permissions.  If Alice
delegated to Bob who delegated to Carol (responsibly for control
by identity), then Bob's access could be cut off without cutting
off the access that Bob had delegated to Carol.  Nothing was said
in that facility about Alice (or any sysadmin upstream) managing
individual permissions (capabilities) supported by the membrane.
One difficulty in trying to do so would be in even just determining
what the capabilities do to try to make decisions about whether
to remove them individually or not.  Many of the capabilities in such
a support list could have been derived from (fetched through) an
initial set.  Even if one was removed, it might be possible to
fetch it again through the membrane.  Messy.

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.

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