nashorn security

[A. Sundararajan]

Hi,

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 
scripts.

* 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.

-Sundar

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:
>
>> Greets-
>>
>>
>> 1) Since people probably are going to be running a variety of
>> dynamically-generated code within nashorn, what is done to allow the
>> javascript code to be sandboxed?
>>
>>
>> 2) Is something like
>>
>>
>>      engine.put("java", null);
>>
>>      engine.put("Java", null);
>>
>>      engine.put("Packages", null);
>>
>>      etc.
>>
>>
>> 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
>> security.
>>
>>
>> 3) Is there any other way to reach outside of the nashorn environment, even
>> if sandboxed?  For example are there properties available on any javascript
>> objects (or java objects that are passed in) that would allow the dynamic
>> execution of code on the java side of things.
>>
>>
>> Thanks,
>>
>> Nate
>>
>
>
> --
> *greg brail* | *apigee <https://apigee.com/>* | twitter
> @gbrail<http://twitter.com/gbrail>