Goal and scope

The goal of this enhancement is to extend security properties capabilities so files containing properties definitions can include other files inline. When a file is included, all its security properties are added as if defined at that point. The master properties file located at ${java.home}/conf/security/java.security, as well as any file pointed by the "java.security.properties" system property, can benefit from this mechanism. Included files can also include others recursively, as long as this does not lead to a cycle.

Motivation

The motivation for this enhancement is to facilitate a centralized management of security properties that affect multiple JDK releases deployed in a system. This centralized management is also an enabler for establishing security profiles across multiple JDKs. Each profile consists of a set of security properties definitions that may lean more towards interoperability or, on the contrary, to a strict security hardening.

A concrete application of centralized management and profiles can be found in mainstream Linux distributions, where the crypto-policies package defines sets of security properties that apply to all JDKs installed on a system. Based on a system-wide configuration, security profiles such as LEGACY, DEFAULT, FUTURE or FIPS can be enforced and define security property values for OpenJDK. Examples of security properties defined for each profile are "jdk.certpath.disabledAlgorithms", "jdk.tls.disabledAlgorithms" and "jdk.tls.legacyAlgorithms".

In addition to the previous, this enhancement allows more flexibility for JDK packagers and users to organize security properties in separated files, grouping by subsystem, override priority or any other criteria. For example, TLS-related security properties and security providers may be grouped into their own files. Overridable properties may be included first from a separated file, whereas non-overridable ones may be applied later on top of the former.

Security considerations

Security properties have a direct impact on the security of a JDK deployment. The proposed mechanism is based on the principle of requiring explicit indication of which files are included, and throws a fatal error if any of the files does not exist or cannot be included for some reason. This principle minimizes the risk of inadvertently failing to apply otherwise expected security properties, or having a dangling pointer to a non-existent file that may be created at a later time with untrusted content. However, as it is the case for any file included by means of "java.security.properties", users and packagers must ensure that included files are assigned appropriate OS permissions.

Find more information about the problem, solution and specification in the CSR JDK-8319333.