[e-lang] Powerless MUST NOT access package scope member on another object

Adrian Mettler amettler at cs.berkeley.edu
Tue Jan 15 02:21:46 EST 2008


It is not the case that a Powerless object can't be used for privilege 
escalation, as data can unlock behavior just as well as tokens (e.g. 
passwords, crypto keys).  The guarantee for Powerless objects is that 
they provide no authority under a particular model, in which it is 
assumed that Tokens are the only immutable objects used for privilege 
escalation.  Package scoping is something different, and so far we 
haven't given much thought to supporting it in Joe-E, as it does not 
follow the capability model as closely: the ability to invoke a package 
scope method is, in general, not governed by a capability.  There is 
nothing stopping the ability to invoke a package-scope method from being 
ambient, let alone obtainable by virtue of an object that implements 
Powerless.  (Consider a BoxOpener class in the same package as Box that 
has a public constructor.  Regardless of whether the Opener is 
Powerless, one can get one starting with no capabilities.)

It is a different kind of task to audit that no one gets access to code 
living in the same package as Box then it is to, say, ensure that one 
does not get a reference to an inner class of a particular instance of 
Box.

Also, the motivation for such a prohibition depends on the reason for 
making a particular method package-scope instead of public.  If the 
reason is to ensure internal consistency of a data structure rather than 
to encapsulate priviliged state, one may want to make the invoking class 
Powerless even though it calls a package-scope method.  The code of such 
a class being trusted does not mean that holders of its instances need 
to be trusted.

I'd be interested in hearing others' ideas on the issue.
-A

Tyler Close wrote:
> Currently, the difference between a Powerless and an Immutable is the
> absence of any Token which is supposed to mean that the Powerless
> object is unable to perform any rights amplification. But the most
> common form of rights amplification in Java is access to the package
> scope interface of another object. Consequently, a Powerless object
> can actually represent non-trivial authority. For example,
> 
> public final class
> Box {
>     final Object secret;
> 
>     Box(final Object secret) {
>         this.secret = secret;
>     }
> }
> 
> public final class
> Unsealer implements Powerless {
>     Unsealer() {}
> 
>     public Object
>     unseal(Box box) { return box.secret; }
> }
> 
> public final class
> Sealer implements Powerless {
>     Sealer() {}
> 
>     public Box
>     seal(final Object secret) { return new Box(secret); }
> }
> 
> The Sealer and Unsealer types in the above code represent real
> authority. They should not be Powerless, yet the current Joe-E
> verifier allows them to be marked so.
> 
> --Tyler
> 



More information about the e-lang mailing list