[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaand ScottSmith of Johns Hopkins)

Ben Laurie ben@algroup.co.uk
Tue, 23 Jan 2001 17:02:17 +0000


"Jonathan S. Shapiro" wrote:
> 
> Ben Laurie wrote:
> >
> > "Jonathan S. Shapiro" wrote:
> > > Defense in depth also becomes appropriate for "second chance" security.
> > > A major problem with capability systems is: "What do I do *after* I make
> > > a mistake?" In the real world, we often know that the recipient does not
> > > act immediately. It is desirable to be able to undo an erroneous
> > > transmission. This, by the way, is where ACLs come in to play.
> >
> > Isn't this trivially solved with revocable capabilities?
> 
> No it isn't. The problem is that I have some object A. I give cap(A) to
> you intentionally and correctly. I give cap(A) to Fred by accident. If I
> revoke A, then the copies of cap(A) that I gave to you get lost too.

Well, the answer is, presumably, that you should give different
revocable capabilities to each recipient. I agree that this could become
horrible, but not in all cases.

> Unfortunately, the feasible recovery strategies introduce some very
> serious security issues.
> 
> There really is a valid argument for some form of ACL here.

For example, I make it so that I give each possible recipient of a
capability another capability (or perhaps just a token of some kind) and
I gate the capability with a list of tokens that are permitted to invoke
the capability? If you go down _this_ route, then one could, presumably,
do away with the capability altogether and just use the list of tokens.
I find this thought distressing.

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