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