Nashorn, Security manager and custom policy

Thu Apr 10 09:40:00 UTC 2014

As I said earlier, with jdk7 jrunscript + security manager mode never 
worked - which is what you confirmed. jrunscript's initial script 
"init.js" itself throws security exception - i.e., you may have to give 
lot more permissions as you found out.

As for particular release in which nashorn's fix for null URL will make 
it in, I can't say for sure - most likely 8u20. Please watch out 
jdk8u-dev alias and/or release notes of jdk8 update releases.

Thanks
-Sundar

On Thursday 10 April 2014 01:57 PM, Youri Bonnaffé wrote:
> Thanks for you answer.
>
> Unfortunately our use case uses the ScriptEngine from Java code to run JS
> scripts (I was using jrunscript here for testing purpose), so jjs is not an
> option for us.
>
> I double checked with JDK7:
>
> $> jrunscript -J-Djava.security.manager test.js
> script error in file <system-init> :
> sun.org.mozilla.javascript.internal.WrappedException: Wrapped
> java.security.AccessControlException: access denied
> ("java.util.PropertyPermission" "*" "read,write") (<system-init>#194) in
> <system-init> at line number 194
>
> It seems the security manager is enabled but raises an exception even
> before the script is executed. I tested something else. Here is the policy
> used:
>
> *grant {*
> *    permission java.io.FilePermission "test.js", "read";*
> *    permission java.io.FilePermission "foo", "read";*
> *    permission java.util.PropertyPermission "*", "read,write";*
> *};*
>
> and the script:
>
> *println(java.lang.System.getProperty("os.name <http://os.name>"))*
> *new java.io.File("titi").exists()*
>
> if I run
>
>
> *$> jrunscript -J-Djava.security.manager
> -J-Djava.security.policy=test.policy test.js*
>
> it works. Now if I comment out the line with the file permission on "foo",
> it will produce:
>
> *$> jrunscript -J-Djava.security.manager
> -J-Djava.security.policy=test.policy test.js*
> *Linux*
> *script error in file test.js :
> sun.org.mozilla.javascript.internal.WrappedException: Wrapped
> java.security.AccessControlException: access denied
> ("java.io.FilePermission" "foo" "read") (test.js#2) in test.js at line
> number 2*
>
> It seems that the security manager is taken into account. It it quite an
> issue for us as we run our application with security manager enabled and
> allow JS scripts to be executed through the ScriptEngine. The scripts can
> be String or Reader and they can be provided by the end user (so setting
> codeBase values is not an option).
> Do you have any idea on when the fix will be released?
>
> Thanks,
>
> Youri,
>
>
> On 9 April 2014 17:58, A. Sundararajan <
> sundararajan.athijegannathan at oracle.com> wrote:
>
>> Hi,
>>
>> There are two shell tools in JDK8. "jjs", "jrunscript".
>>
>> jjs uses direct Nashorn (internal) classes and associates script URL to
>> source files (and therefore permission etc.) Your example works fine with
>> jjs with println replaced as "print".
>>
>>      jjs -J-Djava.security.manager -J-Djava.security.policy=test.policy
>> test.js
>>
>> is fine. Prints OS name with the modified policy and throws security
>> exception without that policy.
>>
>> jrunscript uses javax.script API and evaluates scripts by
>> ScriptEngine.eval methods (passing "string" code or Reader made out of
>> test.js). javax.script API has no way to associate a source URL to a script
>> (either String or Reader). So, "test.js" is loaded as script without
>> "origin" (i.e., origin unknown). Such scripts are given only minimal
>> permissions (url being null). But, then your policy gives AllPermission to
>> any code regardless code origin and so it can be expected to have
>> AllPermission (even when url is null). That issue - of only giving minimal
>> permissions to null url scripts - has been fixed in update release. It'll
>> appear in an 8 update release. For the interim, please use jjs for this
>> case. Note that specific URL permission should work now as expected.
>>
>> PS. BTW, AFAIK, jrunscript in jdk7 uses Rhino and does not work with
>> security manager enabled. Are you sure it worked for you? you may want to
>> double check.
>>
>> Hope this helps,
>> -Sundar
>>
>>
>> On Wednesday 09 April 2014 08:53 PM, Youri Bonnaffé wrote:
>>
>>> Hi,
>>>
>>> I'm trying to run this very sample JS file:
>>>
>>>       println(java.lang.System.getProperty("os.name"))
>>>
>>> using jrunscript.
>>>
>>> $> jrunscript test.js
>>> Linux
>>>
>>> Now when I set a Security Manager:
>>>
>>> $> jrunscript -J-Djava.security.manager test.js
>>> Exception in thread "main" java.security.AccessControlException: access
>>> denied ("java.io.FilePermission" "test.js" "read")
>>> at
>>> java.security.AccessControlContext.checkPermission(
>>> AccessControlContext.java:457)
>>> at java.security.AccessController.checkPermission(
>>> AccessController.java:884)
>>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
>>> at java.io.FileInputStream.<init>(FileInputStream.java:121)
>>> at java.io.FileInputStream.<init>(FileInputStream.java:87)
>>> at com.sun.tools.script.shell.Main.processSource(Main.java:279)
>>> at com.sun.tools.script.shell.Main.access$100(Main.java:37)
>>> at com.sun.tools.script.shell.Main$2.run(Main.java:200)
>>> at com.sun.tools.script.shell.Main.main(Main.java:48)
>>>
>>> which is expected.
>>>
>>> Now when I set a custom policy such as:
>>>
>>> grant {
>>>       permission java.security.AllPermission;
>>> };
>>>
>>> $> jrunscript -J-Djava.security.manager
>>> -J-Djava.security.policy=test.policy test.js
>>> java.security.AccessControlException: access denied
>>> ("java.util.PropertyPermission" "os.name" "read")
>>> at
>>> java.security.AccessControlContext.checkPermission(
>>> AccessControlContext.java:457)
>>> at java.security.AccessController.checkPermission(
>>> AccessController.java:884)
>>> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>> at java.lang.SecurityManager.checkPropertyAccess(
>>> SecurityManager.java:1294)
>>> at java.lang.System.getProperty(System.java:714)
>>> at jdk.nashorn.internal.scripts.Script$test.runScript(test.js:1)
>>> at
>>> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(
>>> ScriptFunctionData.java:498)
>>> at
>>> jdk.nashorn.internal.runtime.ScriptFunction.invoke(
>>> ScriptFunction.java:206)
>>> at jdk.nashorn.internal.runtime.ScriptRuntime.apply(
>>> ScriptRuntime.java:378)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(
>>> NashornScriptEngine.java:546)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(
>>> NashornScriptEngine.java:528)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(
>>> NashornScriptEngine.java:524)
>>> at
>>> jdk.nashorn.api.scripting.NashornScriptEngine.eval(
>>> NashornScriptEngine.java:189)
>>> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249)
>>> at com.sun.tools.script.shell.Main.evaluateReader(Main.java:332)
>>> at com.sun.tools.script.shell.Main.evaluateStream(Main.java:368)
>>> at com.sun.tools.script.shell.Main.processSource(Main.java:285)
>>> at com.sun.tools.script.shell.Main.access$100(Main.java:37)
>>> at com.sun.tools.script.shell.Main$2.run(Main.java:200)
>>> at com.sun.tools.script.shell.Main.main(Main.java:48)
>>>
>>> This happens only with a JDK8/Nashorn, if I do the same with JDK7, the
>>> last
>>> command will succeed. I failed to find information elsewhere so that's why
>>> I asking for help here. Do you understand what might happen? And what
>>> changed around security manager with JDK8/Nashorn?
>>>
>>> Thanks,
>>>
>>>     Youri
>>>
>>