[cap-talk] A question on capabilities

[Karp, Alan H]

David Wagner wrote:
> 
> I gave a talk at PLAS06 yesterday on object capabilities and
> language-based capability systems.  My slides, if anyone is 
> interested,
> are here:
>   http://www.cs.berkeley.edu/~daw/talks/PLAS06.ps

Great talk.  I may steal parts of it.
> 
> I got one question afterwards that I didn't have a great answer to,
> and I'm curious what others response might be.  The question: Suppose
> Alice has a powerful capability, and Alice and Bob have a 
> communication
> channel over which they can talk to each other.  Ok, granted, we can't
> prevent Alice from sharing her authority with Bob, if she really wants
> to, since she can always proxy for Bob.  But what about the 
> risk of Alice
> unintentionally leaking her capability to Bob?  Do capability 
> systems have
> a good story about how to deal with that?  (And yes, we recognize that
> if Alice and Bob are completely isolated from each other, then that's
> one case where capability systems have a good story, but that case is
> too restrictive, and the questioner was really asking whether 
> there are
> any other cases where capability systems can help out with this risk).
> 
This question had an important influence on the e-speak architecture.
What concerned us was that passing a capability as an argument granted
the recipient the right to use it.  We were worried that an
administrator might inadvertently grant some powerful authority, such as
the right to update the system log file.  The solutions we came up with
were different in the Beta, which I call Client Utility (CU), and the
e-speak product, which I call e-speak.

CU used split capabilities, which were invented to address this problem.
A name binding to a resource let the holder send a message to the
resource, and the handler for the resouce could choose to respond to the
request.  In that case, the name binding was a classic capability.
However, that wasn't the way we normally did things.  Instead, the
requester also specified one or more "keys", a poor choice of words but
meant to call to mind a key that opens a lock.  I now call them CUkeys
to avoid confusion.  These CUkeys were used to extract one or more
specific rights from metadata associated with the resource.  The
designation of the right was transferred to the handler, but not the
CUkey.  Hence, the requester could prove a right without transferring
it.  For example, the name for a file, foo.txt, might be bound to
metadata containing the strings "R" and "W" having different locks.  A
request that contained a CUkey that opened the first lock would be able
to read the file but not write it.  A request that included Cukeys that
opened both locks could read and write.  Interpreting these strings was
up to the handler, which corresponds to my definition of discretionary
access control.  This approach addressed the problem because sending a
CUkey was an explicit action distinct from that involved in exercising a
right.

We soon realized that we needed something more.  We couldn't articulate
it at the time, but Ping, MarkM, and MarcS identified its importance,
and Ping gave it the name Voluntary Oblivious Compliance.  The problem
was that CUkeys could be passed as arguments, and it was hard to know
whether or not sending one would violate policy.  Of course, the problem
existed for all resources, but that wasn't our main concern.  We found a
way to use CUKeys to make certain name bindings unusable.  Since these
settings were external to the resource handlers, they fit my definition
of mandatory access control.

E-speak used SPKI attribute certificates as capabilities.  They weren't
really capabilities, but they were close enough.  Each delegation of
such a certificate was tied to a specific private key.  The important
point for the present discussion is that delegation was an explicit
action rather than the implicit one of using a capability as an
argument.  Hence, you could prove you had a right without transferring
it.  Although e-speak supported the Do-Not-Delegate bit, it was pretty
useless.  Most certs were delegated to a one-off private key used only
for that capability.  Hence, you could always delegate by sharing this
private key.

________________________
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: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060613/c5409f6f/attachment.vcf