Best approach to sandboxing Nashorn

[A. Sundararajan]

Hi,

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

* 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,
-Sundar

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!
> Rod