Rudder

It seems that with recent JVM, we get:

java.lang.SecurityException: access denied to: ("java.security.SecurityPermission" "getProperty.crypto.policy")
    at com.normation.rudder.services.policies.JsEngine$SandboxSecurityManager.checkPermission(JavascriptEngine.scala:687)
    at java.security.Security.getProperty(Security.java:793)
    at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:272)
    at javax.crypto.JceSecurity.access$000(JceSecurity.java:50)
    at javax.crypto.JceSecurity$1.run(JceSecurity.java:85)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:82)
    at javax.crypto.SecretKeyFactory.nextSpi(SecretKeyFactory.java:295)
    at javax.crypto.SecretKeyFactory.<init>(SecretKeyFactory.java:121)
    at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:160)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.getSecretKeFactory(AixPasswordHashAlgo.scala:185)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha256impl$lzycompute(AixPasswordHashAlgo.scala:214)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha256impl(AixPasswordHashAlgo.scala:214)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha256(AixPasswordHashAlgo.scala:161)
    at com.normation.rudder.services.policies.JsLibPassword.aixSha256(JavascriptEngine.scala:123)
    at com.normation.rudder.services.policies.JsLibPassword.aixSha256$(JavascriptEngine.scala:123)
    at com.normation.rudder.services.policies.JsRudderLibImpl$$anon$2.sha256(JavascriptEngine.scala:268)
    at jdk.nashorn.internal.scripts.Script$11$\^eval\_.:program(<eval>:1)
    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
    at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
    at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine.$anonfun$singleEval$1(JavascriptEngine.scala:548)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine$$anon$3.call(JavascriptEngine.scala:572)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine$$anon$3.call(JavascriptEngine.scala:569)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
    at com.normation.rudder.services.policies.JsEngine$RudderJsEngineThreadFactory$SandboxedThread.run(JavascriptEngine.scala:710)
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity
    at javax.crypto.SecretKeyFactory.nextSpi(SecretKeyFactory.java:295)
    at javax.crypto.SecretKeyFactory.<init>(SecretKeyFactory.java:121)
    at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:160)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.getSecretKeFactory(AixPasswordHashAlgo.scala:185)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha512impl$lzycompute(AixPasswordHashAlgo.scala:227)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha512impl(AixPasswordHashAlgo.scala:227)
    at com.normation.cfclerk.domain.AixPasswordHashAlgo$.ssha512(AixPasswordHashAlgo.scala:173)
    at com.normation.rudder.services.policies.JsLibPassword.aixSha512(JavascriptEngine.scala:128)
    at com.normation.rudder.services.policies.JsLibPassword.aixSha512$(JavascriptEngine.scala:128)
    at com.normation.rudder.services.policies.JsRudderLibImpl$$anon$2.sha512(JavascriptEngine.scala:273)
    at jdk.nashorn.internal.scripts.Script$13$\^eval\_.:program(<eval>:1)
    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
    at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
    at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
    at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:233)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine.$anonfun$singleEval$1(JavascriptEngine.scala:548)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine$$anon$3.call(JavascriptEngine.scala:572)
    at com.normation.rudder.services.policies.JsEngine$SandboxedJsEngine$$anon$3.call(JavascriptEngine.scala:569)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
    at com.normation.rudder.services.policies.JsEngine$RudderJsEngineThreadFactory$SandboxedThread.run(JavascriptEngine.scala:710)

This seems to be due to an update on Java policy security that added a new check on property: "getProperty.crypto.policy". That check is not explicitly authorized from our JS environment.

It does not seems linked to https://www.rudder-project.org/redmine/issues/12447.

The reference documentation is in JDK ticket https://bugs.openjdk.java.net/browse/JDK-8170157 and in files $JRE_HOME/lib/security/java.security:

# Cryptographic Jurisdiction Policy defaults
#
# Import and export control rules on cryptographic software vary from
# country to country.  By default, the JDK provides two different sets of
# cryptographic policy files:
#
#     unlimited:  These policy files contain no restrictions on cryptographic
#                 strengths or algorithms.
#
#     limited:    These policy files contain more restricted cryptographic
#                 strengths, and are still available if your country or
#                 usage requires the traditional restrictive policy.
#
# The JDK JCE framework uses the unlimited policy files by default.
# However the user may explicitly choose a set either by defining the
# "crypto.policy" Security property or by installing valid JCE policy
# jar files into the traditional JDK installation location.  To better
# support older JDK Update releases, the "crypto.policy" property is not
# defined by default.  See below for more information.
#
# The following logic determines which policy files are used:
#
#         <java-home> refers to the directory where the JRE was
#         installed and may be determined using the "java.home" 
#         System property.
#
# 1.  If the Security property "crypto.policy" has been defined,
#     then the following mechanism is used:
#
#     The policy files are stored as jar files in subdirectories of
# <java-home>/lib/security/policy.  Each directory contains a complete
# set of policy files.
#
#     The "crypto.policy" Security property controls the directory
#     selection, and thus the effective cryptographic policy.
#
# The default set of directories is:
#
#     limited | unlimited
#
# 2.  If the "crypto.policy" property is not set and the traditional
#     US_export_policy.jar and local_policy.jar files
#     (e.g. limited/unlimited) are found in the legacy
#     <java-home>/lib/security directory, then the rules embedded within
#     those jar files will be used. This helps preserve compatibility
# for users upgrading from an older installation.
#
# 3.  If the jar files are not present in the legacy location
#     and the "crypto.policy" Security property is not defined,
#     then the JDK will use the unlimited settings (equivalent to
#     crypto.policy=unlimited)