[E-Lang] Re: Java 2 "Security"

Marc Stiegler marcs@skyhunter.com
Tue, 2 Jan 2001 16:14:11 -0700


True enough. Preventing data leak seems far more difficult than preventing
capability leak, every time I look at it. Have any of the people who've done
capabilities for decades noticed this?

--marcs

----- Original Message -----
From: Bill Frantz <frantz@communities.com>
To: Marc Stiegler <marcs@skyhunter.com>; Ben Laurie <ben@algroup.co.uk>;
Scott Smith <scott@cs.jhu.edu>
Cc: Mark S. Miller <markm@caplet.com>; <e-lang@mail.eros-os.org>
Sent: Tuesday, January 02, 2001 4:00 PM
Subject: Re: [E-Lang] Re: Java 2 "Security"


> At 01:02 PM 1/2/01 -0700, Marc Stiegler wrote:
> >In my admittedly limited practical experiences, I actually haven't found
> >much need for stack-frame-based revocation. Once you've given an object a
> >power, there is generally no new security issue raised in allowing the
> >object to keep the power--not until you are about to grant the object
> >yet-another-power: you may not trust the object with both powers at the
same
> >time even though you trust it with either one by itself (the ability to
read
> >confidential data and the ability to connect to the Internet, for
example).
> >So the E machinery allows the following pattern, which stack frame
control
> >does not:
> >
> >powerUser setPower1(revokable1)
> >powerUser setPower2(revokable2)
> >powerUser usePowers
> >revokable1 revoke
> >revokable2 revoke
> >powerUser setPower3(revokable3)
> >#and so on
>
> You do have to worry about:
>
> powerUser setPower1(revokable1)
> powerUser setPower2(revokable2)
> powerUser usePowers
>   [poweruser saves confidential data]
> revokable1 revoke
> revokable2 revoke
> powerUser setPower3(revokable3)
>   [poweruser passes confidential data to revokable3]
> #and so on
>
> >From a security prospective, it is better not to reuse objects this way.
>
>