Best approach to sandboxing Nashorn
sundararajan.athijegannathan at oracle.com
Mon Sep 16 21:10:16 PDT 2013
* Nashorn already filters classes - only public classes of non-sensitive
packages (packages listed in package.access security property aka
'sensitive'). Package access check is done from a no-permissions
context. i.e., whatever package that can be accessed from a
no-permissions class are only allowed.
* Nashorn filters Java reflective and jsr292 access - unless script has
RuntimePermission("nashorn.JavaReflection"), the script wont be able to
* The above two require running with SecurityManager enabled. Under no
security manager, the above filtering won't apply.
* You could remove global Java.type function and Packages object (+
com,edu,java,javafx,javax,org,JavaImporter) in global scope and/or
replace those with whatever filtering functions that you implement.
Because, these are the only entry points to Java access from script,
customizing these functions => filtering Java access from scripts.
* There is an undocumented option (right now used only to run test262
tests) "--no-java" of nashorn shell that does the above for you. i.e.,
Nashorn won't initialize Java hooks in global scope.
* JSR223 does not provide any standards based hook to pass a custom
class loader. This may have to be addressed in a (possible) future
update of jsr223.
Hope this helps,
On Tuesday 17 September 2013 09:17 AM, Rod Nim wrote:
> Hi Nashorn team!
> Are there any recommendations for the best way to restrict the classes that Nashorn scripts can create to a whitelist? Or is the approach the same as any JSR223 engine (custom classloader on the ScriptEngineManager constructor)?
> I'm also wondering if you have any tips on managing script .js dependencies; like RequireJS, npm etc?
> Thanks in advance!
More information about the nashorn-dev