sundararajan.athijegannathan at oracle.com
Wed Mar 26 09:17:57 UTC 2014
If you run nashorn under a security manager, the following are not
allowed (among other things)
* No reflective Java access (java.lang.reflect, java.lang.invoke.*) from
* Script class is loaded only with the default permissions (which are
given to all untrusted code) and so script can not write to file, delete
a file, spawn a process or do similar bad stuff.
* No access to package.access prevented packages, classes. By default
security policy, this includes sun.*, jdk.internal.* etc.
* All sensitive operations will go through checkPermission of
SecurityManager. Unless you configure specific script URLs to have
enhanced permissions in your policy file (and load those scripts by
load(URL), all script compiled classes are loaded with least permissions.
* With --no-java nashorn option passed (for programs you can set
nashorn.args System property), top level Packages object, java, javax
etc. and Java object are all not initialized by nashorn. This is like
extreme class shutter that shuts everything. We use this option when
running test262 tests - to make sure we don't initialize unnecessary
stuff not expected by ECMAScript compliant code.
Rhino has interpreter (at least by default) and java access is by
reflection. Nashorn uses bytecode compilation - usual Class based
protection domain etc. are always applicable. The comparison here is not
exact one. Also, AFAIK ClassShutter alone is not enough in Rhino world,
you need to play with wrap factory as well. ClassShutter is only about
access to a class via Packages object. If script has got a java object
somehow (say exposed from Java embedding code), any public member can
still be accessed (please correct me if I am wrong on that). So, you
need to play with Rhino's WrapFactory as well (or don't expose any Java
object at all)!
Summary: run nashorn with security manager enabled.
On Wednesday 26 March 2014 01:02 AM, Rick Bullotta wrote:
> We use that capability extensively, Greg. Totally agree that it is easy to comprehend and apply.
> From: nashorn-dev <nashorn-dev-bounces at openjdk.java.net> on behalf of Greg Brail <greg at apigee.com>
> Sent: Tuesday, March 25, 2014 3:23 PM
> To: Nate Kidwell
> Cc: nashorn-dev at openjdk.java.net
> Subject: Re: nashorn security
> Great question -- Rhino had the "class shutter" which was (IMHO) a lot
> easier to understand than a proper Java security manager.
> On Tue, Mar 25, 2014 at 11:38 AM, Nate Kidwell <nate at slideseed.com> wrote:
>> 1) Since people probably are going to be running a variety of
>> dynamically-generated code within nashorn, what is done to allow the
>> 2) Is something like
>> engine.put("java", null);
>> engine.put("Java", null);
>> engine.put("Packages", null);
>> sufficiently secure sandboxing if it is run before a engine.eval(...). Or
>> at least if all the bindings are wiped out, would THAT then be sufficient
>> 3) Is there any other way to reach outside of the nashorn environment, even
>> objects (or java objects that are passed in) that would allow the dynamic
>> execution of code on the java side of things.
> *greg brail* | *apigee <https://apigee.com/>* | twitter
More information about the nashorn-dev