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

Marc Stiegler marcs@skyhunter.com
Tue, 2 Jan 2001 13:02:34 -0700

Once again commenting without reading the full context, privileges that last
till a stack frame pops are pretty easy in E, probably easier to implement
than they are useful in practical applications:

def [revokablePower,revoker] := revokablePowerMaker new(powerfulObject)
objectThatNeedsPowerTemporarily usePower(revokablePower)
revoker revoke

The generic revokablePowerMaker in the above example is 5 lines of E code:

def revokablePowerMaker new(power) :any {
    def revoker revoke {power := null}
    def revocable {delegate {power}}

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

Actually, come to think of it, I am almost sure that E, with its
smalltalk-like ability to allow developers to construct new control
structures, allows you to create a structure that would automatically create
and revoke the power, leaving no risk that the developer might forget the
critical "revoker revoke" message (correct, markm? I don't know how to do
this myself, far too lambda-esque :-).


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

> Scott Smith wrote:
> > Getting back to your question above of what is not subsumed by
> > capabilities: one of the properties of the Java security model is the
> > ability to temporarily raise a privilege so a more sensitive operation
> > can be performed.  A flag is put on the stack (i.e. in the messaging
> > wait-for chain) which signifies the point at which a privilege is
> > raised, and the privilege is raised until that frame is popped (there
> > are various other aspects of the model I am skipping).  To get this
> > effect in a capability system you need to explicitly pass to each method
> > call below the point where the privilege was temporarily raised the fact
> > that this privelege was raised.  Otherwise the information that a
> > privilege is temporarily raised won't reach the target.  (This explicit
> > passing of raised capabilities is how we in fact encode Java stack
> > inspection in one of our papers on the topic).  If you wanted to
> > directly program with this kind of security, it would mean every method
> > for which you wished to support this kind of security would need an
> > additional argument which was the current security context.  Java
> > security architecture can be viewed as a system which does all this
> > bookkeeping for free for you and saves your code from going ugly.
> Speaking strictly as a capabilities-programmer-in-training, it seems to
> me that, firstly, you have to have "additional arguments" for everything
> you want to do (i.e. the capabilities that permit you to do it) in a
> capabilities system, so there's no overhead caused by having to pass
> down a temporary one - you'd've had to have done that with the permanent
> one anyway - and you'd grant a temporary capability by creating a proxy
> to the real capability that you destroy when the thing you call with it
> returns.
> The experts may disagree with me.
> 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