Project

General

Profile

Bug #12448

Failed generation with "Could not initialize class javax.crypto.JceSecurity"

Added by François ARMAND 8 months ago. Updated 8 months ago.

Status:
Released
Priority:
N/A
Category:
Security
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
84
Tags:

Description

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)


Related issues

Related to Rudder - Bug #12450: JS sandbox permission must be defined in a fileReleased
Related to Rudder - Bug #12548: Java 9 / Java 10 compatibility: security exception for JS VMReleased
Related to Rudder - Bug #13014: StackOverflowError during policy generation in JavascriptEngine - debian 9.5 with jdk 1.8.0_181Released
Has duplicate Rudder - Bug #12447: java.lang.NoClassDefFoundError: Could not initialize class sun.security.pkcs.SignerInfoRejected

Associated revisions

Revision 623736ae (diff)
Added by François ARMAND 8 months ago

Fixes #12448: java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity

History

#1 Updated by François ARMAND 8 months ago

  • Related to Bug #12447: java.lang.NoClassDefFoundError: Could not initialize class sun.security.pkcs.SignerInfo added

#2 Updated by François ARMAND 8 months ago

  • Related to deleted (Bug #12447: java.lang.NoClassDefFoundError: Could not initialize class sun.security.pkcs.SignerInfo)

#3 Updated by François ARMAND 8 months ago

  • Has duplicate Bug #12447: java.lang.NoClassDefFoundError: Could not initialize class sun.security.pkcs.SignerInfo added

#4 Updated by François ARMAND 8 months ago

So, the problem is really that we now have several new properties used by the JRE. We need to give access to them.

#5 Updated by François ARMAND 8 months ago

  • Status changed from New to In progress

#6 Updated by François ARMAND 8 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/1908

#7 Updated by François ARMAND 8 months ago

  • Related to Bug #12450: JS sandbox permission must be defined in a file added

#8 Updated by François ARMAND 8 months ago

  • Status changed from Pending technical review to Pending release

#9 Updated by Alexis MOUSSET 8 months ago

  • Subject changed from java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity to Failed generation with "Could not initialize class javax.crypto.JceSecurity"

#10 Updated by Alexis MOUSSET 8 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.1.11, 4.2.5 and 4.3.0~rc3 which were released today.

#11 Updated by François ARMAND 7 months ago

  • Related to Bug #12548: Java 9 / Java 10 compatibility: security exception for JS VM added

#12 Updated by François ARMAND 2 months ago

  • Related to Bug #13014: StackOverflowError during policy generation in JavascriptEngine - debian 9.5 with jdk 1.8.0_181 added

Also available in: Atom PDF