[cap-talk] Limiting case considered (was: Re: Selling capabilities programming)
capability at webstart.com
Mon Jul 16 01:39:59 EDT 2007
At 09:32 PM 7/15/2007, Karp, Alan H wrote:
> > For this extreme example, consider the case where all
> > capability communication (permission communication) is
> > done by proxy. As I recall, Alan Karp indicated that
> > CapDesk only used proxies for capability communication?
>Not CapDesk. Maybe you're thinking of Client Utility,
Ah yes, there we go. Thanks for setting me straight
on that Alan. It's been a while.
>but there we only used proxies for remote accesses.
Important distinction. I had forgotten that. Perhaps
I was too focused on the remote case. I guess that
amounts to the serialization situation (e.g. DCCS, Mach
net, vat) - except that I guess you didn't collapse
multiple forwardings (as DCCS did, I guess the others
>However, we did provide for the kind
>of control you talk about with our support for Voluntary Oblivious
>Compliance. An administrator could configure a Protection Domain with a
>negative permission, a capability that made some resources invisible.
Hmmm. I don't understand the above "negative permission". Do you
think it's relevant to this considered "limiting case" - i.e.
the case where all communication of permissions is done via
At this point I'm mostly interested in probing the concerns
among the dominant computer security community (disputes
about dominance also entertained) about the looseness
(inadequate control - always free to share across existing
communication channels enabled via capability) of object
The direction I'm heading in is to see whether one can argue
that you can't do any better than such an always proxy
object/capability mechanism - even if you implement any
sort of user/ACL mechanism, MAC, etc. All you can do is
to add additional (i.e. more loose, less controlled)
mechanisms for permissions to be distributed. In that
case, why not stick to the simplest mechanism with the
most control/constraints - namely the equivalent of the
always proxy object/capability mechanism? Then if we
can make the functionality of that mechanism more efficient
(e.g. with TCB support) and adequately efficient with
workable APIs, then we'd be on our way to an "ideal"
system (very blue sky I need not remind...). This
is where Horton (with controls - currently unexplained
in the paper) comes in - to supply meaningful controls
(responsibility delegation) associated with identities.
More information about the cap-talk