Newbie Joe-E questions
David Wagner <
daw@...>
2008-10-28 04:55:07 GMT
Jimmy Wylie writes:
>I've downloaded joe-e for the first time and tried to import a simple
>project assigned from one of my beginner java classes. After running
>the verifier, I've received 65 errors, but they all seem to be of the form:
> "Disabled field in from type System accessed: default deny"
> "Reference to disabled type Scanner: no policy specified for this class"
> "Disabled field out from type System accessed: default deny"
> "Method from disabled type PrintStream called: no policy specified for
>this class."
>
>Now this class is a User Interface class, and I want it to be able to
>take in input from an instance of Scanner, and also do output. How do I
>create a policy to allow these authorities for this class?
>I tried simply passing an instance of Scanner in the constructor,
>instead of creating a new one when the constructor is called, but the
>verifier still objects to the "import java.util.Scanner" declaration.
Thanks for giving Joe-E a whirl! The Joe-E verifier is telling you
that those fields/methods are tamed away and are not accessible from
Joe-E. The Joe-E verifier has a taming database that lists which fields
or methods in the Java libraries Joe-E code is allowed to access, and
System.in and System.out are purposefully excluded from that list.
There are two potential issues here:
1) Joe-E code is not supposed to be able to use the global variables
System.in and System.out, as those grant capabilities ambiently (i.e.,
they provide capabilities to all code by default, which is incompatible
with the principle of least privilege). In this case the Joe-E verifier
is doing the right thing. I think this is one issue you are hitting
(at least it is the one suggested by the "Disabled field" warning
messages you mention).
2) Currently, the Joe-E taming database is very minimalistic. The policy
is "deny-by-default", meaning that if we haven't gotten around to taming
a particular portion of the Java library, then that portion of the
library will be inaccessible to Joe-E code by default -- and we haven't
gotten around to taming more than a tiny fraction of the Java library.
You might encounter this in other cases, where Joe-E code would like to
access some field/method of the Java libraries and where providing
access to that field/method would be OK (it wouldn't contradict any
capability principles) but because we haven't provided a taming database
for that portion of the Java libraries, you can't. In those cases, the
only way to proceed would be to extend the taming database yourself.
You may be hitting this issue as well (e.g., in the warnings regarding
Scanner and PrintStream, which indeed have no taming policy specified
for them yet).
Let me comment on 1) above some more. The obvious question is:
If Joe-E code is never allowed to gain any capabilities on its own
(only to receive capabilities passed to it), where does Joe-E code
get interesting capabilities from in the first place? This is the
bootstrapping problem. The canonical way to deal with this right
now is probably to build your application as a combination of Java and
Joe-E code. The startup code (e.g., the implementation of main()) might
be written in Java. Java code is unconstrained by the Joe-E verifier,
so it can directly access System.in and System.out. The startup code
would then instantiate some Joe-E classes and invoke them, passing them
any capabilities they need to do their job. Thus you might write the
bulk of your application in Joe-E. Those Joe-E application classes
might expect you to pass them an InputStream and an OutputStream.
Your Java startup code could then just instantiate those classes and
pass System.in/System.out as an argument to their constructors.
I realize this may be a bit confusing; I'm not sure if that made
sense. Sorry about that.
>Also, on sort of a separate note, could someone clarify exactly what a
>joe-e Token is?
You can ignore Tokens for now. They're an advanced feature that
aren't needed for most purposes -- just pretend they don't exist.
Oh, you want to know why they exist? A Token is an object that
exists solely for its unique object identity. If you do
Token t = new Token();
Token u = new Token();
then you are guaranteed that t!=u, and in particular no two Token
objects will have the same object identity. There are some cases
where it's useful to have a bunch of "key" objects that exist solely
for their object identity (e.g., when building sealer/unsealers), and
then the idiomatic way to implement that in Joe-E is to use Tokens.
The recommended Joe-E idiom is that you normally shouldn't use object
identity (the "address" of an object) as a way to escalate privileges;
in those cases where you do want to do that, use a Token, not any
old object. e.g.,
public class Lockbox {
private final Token key;
private final Object contents;
public Lockbox(Token k, Object o) {
key = k; contents = o;
}
public Object unlock(Token k) {
if (k == key)
return contents;
else
throw new SecurityException("wrong key");
}
}
Here I can create a Lockbox using a new Token t, then hand Alice
the Lockbox and hand Bob the Token; now Alice and Bob can only retrieve
the contents of the Lockbox if they both cooperate.
http://www.cs.berkeley.edu/~daw/joe-e/api/org/joe_e/Token.html
If that didn't make sense, just ignore Tokens for now.
>I read the Joe-E spec doc, and from what I can tell, it
>seems to be like a basic Joe-E type or a Joe-E "Object" class.
Nope.
>If I was
>writing a joe-e program, should all objects not declared to be powerless
>or immutable, be a Token instead?
Nope. Just write your mutable classes like normal (ignore Token,
and don't do anything special -- you don't have to subclass any
preexisting special class or anythign like that).
RSS Feed