Nashorn, Security manager and custom policy

[Youri Bonnaffé]

>From my tests above and my understanding of Java security it seems that the
security manager with jrunscript and JDK7 works (the file permission on
"foo" is taken into account).


On 10 April 2014 11:40, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

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