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]