nashorn security

Greg Brail greg at apigee.com
Tue Mar 25 19:23:14 UTC 2014


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>


More information about the nashorn-dev mailing list