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

[Karp, Alan H]

Jed wrote:

> >Simply construct a bundle
> >of capabilities given to whomever is supposed to do a particular job,
> >and revoke them when that person changes jobs.  ...
> 
> How does it differ?  In more than conspiring communicators (i.e.
> delegation where communication)?

The difference is that the "role" only appears at configuration time,
not at access time.  That small difference leads to dramatic
simplification in the enforcement mechanisms.
> 
> 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.
> 
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.  If it's controlling
access you're after, there are simpler approaches.  From
> 
> 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.
> 
> 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.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070117/0a1db898/attachment.vcf