javax.scripting, Rhino, and creating sandboxes...

[Daniel Pitts]

I'd like to be able to control the interaction between my script and
the host Java environment. Most specifically, if I don't explicitly
allow something, it shouldn't be available to the script context.

Is there an easy-and-sure way to do that? Do I need to go through the
trouble of setting up a SecurityManager? Can I get away with a
"clever" Bindings implementation? I'm mostly interested in Rhino,
which comes shipped with the JDK 1.6, but if there is a general
approach, that'd be great too.

Thanks,
Daniel.

 

[Tom Hawtin]

I'd like to be able to control the interaction between my script and
the host Java environment. Most specifically, if I don't explicitly
allow something, it shouldn't be available to the script context.

Is there an easy-and-sure way to do that? Do I need to go through the
trouble of setting up a SecurityManager? Can I get away with a
"clever" Bindings implementation? I'm mostly interested in Rhino,
which comes shipped with the JDK 1.6, but if there is a general
approach, that'd be great too.

I believe (use at your own risk) that for the Java SE 1.6 adaptation of
Rhino supplied in the Sun implementation (it's not a required part, and
may be implemented differently), you can get away with calling the
scripting API with lowered permissions. You will, of course, need a
SecurityManager. Remember JavaScript is still code. Running untrusted
code safely is difficult.

Where ever you use the API, surround the code with the usual two
argument java.security.AccessController.doPrivileged. Supply an acc with
the required (lack of) permissions (not null!). The Sun Rhino JavaScript
implementation will capture and then reapply those permission for
callback interfaces.

You will need to keep scripts away from code that is not secure. That
means, for instance, using a completely separate class loader (and set
something as thread context class loader). If you use AWT, you will need
to set up a separate AppContext (which you can't do portably).

Actually, it's a bit of a nightmare. I wouldn't bother.

Rhino itself is a different kettle of fish, and not for the better. I
think you should be able to get away with applying the permissions to
the Rhino classes. Not entirely sure it will run like that - certainly
the optimiser wont work.

Tom Hawtin

[Cross-posted and followup-to: comp.lang.java.security]