[E-Lang] Java 2 "Security" (was: Re: Welcome ChrisSkalkaandS cottSmith of Johns Hopkins)

Karp, Alan alan_karp@hp.com
Wed, 24 Jan 2001 12:49:46 -0800


> -----Original Message-----
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> Sent: Tuesday, January 23, 2001 8:43 AM
> To: Jonathan S. Shapiro
> Cc: hibbert@netcom.com; Tyler Close; Scott Smith; E Language 
> Discussions
> Subject: Re: [E-Lang] Java 2 "Security" (was: Re: Welcome
> ChrisSkalkaandScottSmith of Johns Hopkins)
> 
> 
> "Jonathan S. Shapiro" wrote:
> > 
> > Ben Laurie wrote:
> > 
> > > Fair enough. Nevertheless, this is something you can't 
> defend against in
> > > a distributed capability system, which was my point. IIRC.
> > 
> > Yes you can. A distributed capability system can use an encrypted
> > transport to transmit capabilities between runtimes.
> 
> Yes, I am aware of that. That defends against theft in 
> transit, but not
> theft of the remote machine, or careless key security on the remote
> machine.
> 
> Hmmm. I'm not sure how valuable this point is, but since it 
> is not being
> understood at all, I'll try again.
> 
> If I have two pieces of code running on one machine, the OS can make
> guarantees about capabilities and their traceability to the two pieces
> of code. If they run on different machines, those guarantees cannot be
> made by the OS any longer: they also rely on things like a working
> secure transport, key security at both ends, and "capability security"
> at the remote end, _in addition to_ relying on the OS guarantees.
> 
> In other words, on a single system I can ask the OS "does 
> process X have
> capability Y?", and it can tell me (modulo me having authority to ask
> the question at all). On a distributed system, I cannot have that
> question answered (when process X is on a different machine) without
> making extra assumptions.
> 

I agree completely.  Unless you have a reason to trust the other machine,
perhaps because it's sitting on your desk, too, you have no guarantees.  In
e-speak Beta 2.2, we assumed that a remote request came from the machine,
not any particular user.  In fact, we required machine to machine
authentication on connection, but authenticating a user on a remote machine
was optional.  Of course, the user could present identification.  If we
thought that the other machine would at least enforce separation of address
spaces, perhaps because we had authenticated it as being owned by a
reputable company, we might believe the identity of the user.  However, we
assumed that any time a capability was sent to another machine, any user on
that machine could use it.  If the kernel of that machine might be corrupt,
that's the best you can do.  However, there are many situations where you
can tolerate the risk of making that assumption, so user authentication is
feasible.  

> This relates strongly to the whole discussion of "rely" in 
> the technical
> sense MarkM has used it.
> 
> Now, I realise you can argue that the entire distributed system should
> be appropriately engineered to make those extra assumption 
> non-onerous.
> There are, undoubtedly, many cases where this can be done. What is
> unclear to me is whether it can always be done, realistically. This is
> why I am unsure of the value of the point.
> 
> Is that any clearer?
> 
> Cheers,
> 
> Ben.
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/