nashorn security

[Rick Bullotta]

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>