[cap-talk] RE: OS security discussion, restricted access proc esses, etc. - back to basics

[Norman Hardy]

On May 4, 2004, at 2:24 PM, Karp, Alan wrote:

> Norm Hardy wrote:
>
>> My contorted note at
>> <http://cap-lore.com/CapTheory/Dist/Which.html> is
>> where I convince myself that they are equivalent.
>> I shall try to clarify that note.
>
> What you described under the local name space case is almost the 
> Client Utility (CU) introduction mechanism.  The only difference is 
> that the introduction from Sa doesn't go via Sb.
>
> Here's how it works in CU.  A is currently proxying a capability on C 
> for B.  Say that A wants to introduce B to C so that requests from B 
> go directly to C.  A sends a message to C containing the capability 
> and a nonce saying "Here's what I'll proxy for the party who knows 
> this nonce.  You might as well provide it directly."  A sends B the 
> nonce and instructions for contacting C.  B contacts C and presents 
> the nonce.  C sets up a remote capability for B to use on that wire.  
> There is still a secret, the nonce, but it can be a public key.  If 
> that's the case, B authenticates itself to C by proving knowledge of 
> the corresponding private key.  In this case, there is no secret, and 
> local name spaces are different from the global name space.

This is fine and perhaps simpler. One difference between the direct 
introduction message from A to C and the indirect message thru B is 
system lifetimes. In  the scheme I describe A may be dead when B 
eventually needs C.
In any case I still think that the local (link) names and sparse global 
names have no important ultimate differences. I think your scheme has 
some complementary advantages. This all impacts distributed garbage 
collection in ways that hurt my head.

> There's one bit of magic here.  How does A tell B to connect to C?  We 
> assumed that each machine has a "Connection Object" that gives 
> instructions for finding it.  This piece of data might specify a URL, 
> a phone number, or even a locator service.  Since A is talking to C, 
> it must know C's connection object.  If B can't make a connection to 
> C, say because they don't support a common protocol, then A will have 
> to continue proxying requests.
>
> ________________________
> Alan Karp
> Principal Scientist
> Technical Computing Research Group
> 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
>
>
>> -----Original Message-----
>> From: cap-talk-bounces at mail.eros-os.org
>> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Norman Hardy
>> Sent: Tuesday, May 04, 2004 1:03 PM
>> To: General discussions concerning capability systems.
>> Subject: Re: [cap-talk] RE: OS security discussion,
>> restricted access processes, etc. - back to basics
>>
>>
>>
>> On May 3, 2004, at 2:25 PM, Jed Donnelley wrote:
>>
>>> Alan,
>>>
>>> This thread it a bit stale at this point.  Many of the topics have
>>> been discussed and transferred over to the Capability Talk list.
>>
>> As a matter of fact this pause has allowed me to gather my
>> thoughts and
>> think hard about the problem after several years.
>> I am 24 hours behind this stream but it is coming faster than I can
>> digest it.
>> I hope I am not redundant.
>> I have changed my mind about one fundamental thing.
>> I once thought that local wire names and (global) Swiss numbers were
>> fundamentally different.
>> I now see them as optimizations of each other.
>> My contorted note at
>> <http://cap-lore.com/CapTheory/Dist/Which.html> is
>> where I convince myself that they are equivalent.
>> I shall try to clarify that note.
>>
>> ......
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>
> <Alan H Karp.vcf>_______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk