[cap-talk] disputing the slam against networkcapabilities, esp. confinement/auditing

Karp, Alan H alan.karp at hp.com
Tue Oct 26 14:36:13 EDT 2004


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Tuesday, October 26, 2004 10:52 AM
> To: General discussions concerning capability systems.
> Subject: RE: [cap-talk] disputing the slam against 
> networkcapabilities, esp. confinement/auditing
> 
> 
> At 08:16 AM 10/26/2004, Karp, Alan H wrote:
> >Jed Donnelley wrote:
> > >
> > > Of course if Alice wishes to proxy all the rights that 
> she passes to
> > > Bob (whether Bob is local or remote) that is her choice.  She may
> > > also audit any such capabilities.  This is true whether 
> she is using
> > > a capabilities as descriptors model (where did the 
> "designators" term
> > > come from?) or capabilities as data, whether the capabilities are
> > > communicated locally or across a network.
> > >
> > > Perhaps I've lost the focus of this thread?  Is there a
> > > difference of opinion somewhere that I'm missing?
> >
> >If Alice sets up a separate proxy for each recipient of her
> >capabilities, you've got path based capabilities built out of clists.
> 
> Let me see if I understand this.  Certainly Alice can set up a proxy
> capability for one of her "base" capabilities.  She can (hopefully)
> decide to pass either a "base" capability (just to distinguish it
> from one of its proxies) or a proxy to Bob.  If Bob received a
> proxy he could pass that capability directly (or by again proxying
> it, but let's consider the direct case) to David.
 
Sorry, we're using different meanings of the word proxy.  By proxy, you
appear to mean a transparent forwarder, as in the caretaker pattern used
for revocation.  By proxy, I mean a separate process on Alice's machine
that forwards all requests on a particular connection.  This CUproxy
(for Client Utility, the prototype that became the Beta release of
e-speak) had its own clist.  A remote request carried a CUname that was
used to index into that clist.  If there was no mapping, the request
failed, as it should.  Say that Bob got a capability from Alice that had
a CUname "foo".  When Bob invoked "foo", the request would go to the
CUproxy on Alice's machine that took requests on the Alice-Bob
connection.  If Bob told David about "foo", and David presented that
CUname on the Alice-David connection, the clist for that CUproxy would
use whatever mapping was in its clist.  That might map to the same
capability Bob used, a different one, or no capability at all. 
 
> 
> Now David has the capability that Alice proxied for sending to
> Bob.  When you use the term "path based" for this case (if you
> do) are you doing so to refer to the fact that the capability that
> Bob and David now have (that was initially proxied by Alice)
> can now be distinguished as the right that Alice gave to Bob -
> as opposed, say, to another capability that Alice gave to Edward
> as a separate proxy?
 
Did the above explanation answer your question?
 
> 
> >If David somehow learns the bits in Alice's capabilities 
> being held by
> >Bob, David can't use them unless Bob will proxy for him.  That's not
> >true with Swiss numbers in E.  If Alice sets up a proxy for the
> >capability she sends to Bob, and David learns the Swiss number, David
> >can invoke the proxy exactly as does Bob.
> 
> It sounds to me like you are saying that if one uses Swiss numbers
> to implement capability communication then the rights can be
> protected from data theft to some extent by proxying them.  That
> is, that Alice can at least tell that David is accessing the 
> capability
> that Alice proxied for Bob.  However, I don't see how one can 
> distinguish
> this case from the situation that would arise if Bob genuinely chose
> to share the capability he received from Alice with David.
> It seems to me that your underlying capability communication
> mechanism is either safe from data theft or it isn't.  A mechanism
> based on Swiss numbers (essentially what I refer to as a password
> mechanism: http://www.webstart.com/jed/papers/Managing-Domains/#s8
> ) isn't.
 
Correct.  To be precise, a Swiss number isn't a capability.  It's an
index into a table that maps it to an object reference, which is a
capability.  If there's only one mapping table per vat, then anyone who
learns the Swiss number by any means can use the capability.  If there
was one mapping table per CapTP connection or per authentication, then
that would not be the case.
> 
> --Jed http://www.webstart.com/jed/ 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 

________________________
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/20041026/0bd0c3a0/KarpAlanH-0001.vcf


More information about the cap-talk mailing list