Introduction

As part of the efforts for achieving binary compatibility with Temurin builds, fferrari@redhat.com and I were exploring alternatives for handling RHEL crypto-policies alignment in OpenJDK. Our goal is to support crypto-policies without downstream changes to OpenJDK code, as we currently have. This support may be extended to other Linux distributions that ship crypto-policies and where Temurin can be deployed (e.g. Ubuntu), but is not under the scope of this task.

Crypto-policies is a package that brings security and cryptographic configurations for different libraries according to a system-wide security profile. Red Hat builds of OpenJDK must follow the global policy by default, while providing a mechanism to disable alignment. Most of the security properties currently contained in the crypto-policies for Java pertain to TLS (e.g. jdk.tls.disabledAlgorithms). In the future, we expect crypto-policies for Java to include a value for the Security Providers Filter.

Alternative #1 (preferred)

Extend the security properties capabilities so files such as java.security can include other files inline. A new include pseudo-property is introduced to this effect. Find more details about this proposal in JDK-8319332 and in PR openjdk/jdk#16483. Notice that this alternative is subject to OpenJDK acceptance.

What comes next is an explanation of how Red Hat builds of OpenJDK can leverage on the proposed mechanism to achieve crypto-policies alignment.

The java.security file in Red Hat builds of OpenJDK will have the following line at the end:

include useSystemCryptoPolicies=${jdk.security.useSystemCryptoPolicies}

Notice that the java.security file in OpenJDK vanilla will not have such line.

When Red Hat builds of OpenJDK are deployed (RPM installation), the following symbolic links structure is created:

${java.home}/conf/security/useSystemCryptoPolicies=      --> points to useSystemCryptoPolicies=true
${java.home}/conf/security/useSystemCryptoPolicies=true  --> points to /etc/crypto-policies/back-ends/java.config
${java.home}/conf/security/useSystemCryptoPolicies=false --> points to /dev/null

How crypto-policies alignment work?

Alignment to crypto-policies is enabled by default.

Disabling alignment

To disable crypto-policies alignment persistently, for all executions of a JDK deployment and in a way that cannot be re-enabled per-execution, the java.security file has to be edited and the "include" line commented. Privileges are required for this action.

To disable crypto-policies alignment persistently, for all executions of a JDK deployment but in a way that can be re-enabled (per execution), the ${java.home}/conf/security/useSystemCryptoPolicies= symbolic link has to be pointed to useSystemCryptoPolicies=false. Privileges are required for this action.

To disable crypto-policies alignment for a specific execution of the JVM, the -Djdk.security.useSystemCryptoPolicies=false argument has to be passed. Privileges are not required for this action.

Re-enabling alignment

If alignment to crypto-policies was disabled in a way that can be re-enabled for an specific execution of the JVM, the -Djdk.security.useSystemCryptoPolicies=true argument has to be passed for re-enabling.

Alternative #2

This alternative leverages on the existing java.security.properties System property (OpenJDK upstream API). If the User does not set a value for this property, we can transparently assign it to the crypto-policies configuration file for Java and accomplish our alignment goal (i.e.: -Djava.security.properties=/etc/crypto-policies/back-ends/java.config). If the User assigns a value, we have to merge the file pointed by the property with the crypto-policies configuration. This merge can take place on a new temporary file, and this is then passed as the property's value. Notice that any User value must override any previous value for the same property.

One option to implement the described behavior without modifying internal code is to develop an alternative Java launcher (bin/java). The scope can be extended to other launchers such as Keytool (bin/keytool). It is worth mentioning that launchers use a documented public API to spawn the JVM. The alternative launcher should check if the User set a value for java.security.properties and proceed either by making it point to the crypto-policy for Java or to a new temporary file that merges values.

It's key to the success of this approach to consider the following implementation aspects: 1) the temporary file must be automatically cleaned up once the JVM stops execution, even under abnormal circumstances; 2) the temporary file is security-sensitive so logical access permissions must be set accordingly; and 3) the launcher must ensure that any temporary file is created new, so it's not under control of a malicious actor.

Pros

• We leverage on an existing OpenJDK API that is multi-platform.
• Changes don't affect internal code: binary compatibility with Temurin is preserved at the libraries level.
• Code changes are small and limited in scope. This alternative is relatively easy to implement.
• The impact on performance is minimal. No additional processes are spawned and the temporary file, when needed, is created on the tmpfs file system.
• Disabling alignment with crypto-policies does not require passing any properties to a Java launcher, setting any configuration or taking any privileged actions: it's just a matter of choosing which launcher to use. The alternatives tool can be considered for permanently switching the default behavior.

Cons

• This alternative is RHEL or Linux-specific. Other operating systems such as Windows and macOS do not have —and are not expected to have— a similar crypto-policy for Java concept. Not suitable for an OpenJDK upstream proposal.
• The existence of multiple launchers can be confusing for users even when clear documentation is made available.
• Users that have their own Java launchers will not benefit from the crypto-policies alignment.

Timelines

• Alternative #1
  • Development phase finished. Ready for QA.
• Alternative #2
  • Proof-of-concept and OpenJDK upstream proposal for Q4 2023.