RFR: 8319332: Security properties files inclusion [v7]

[Martin Balao]

On Wed, 17 Apr 2024 14:28:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> "If a system property does not have a value, it expands to the empty string." What's the benefit? It will be nice if you can include an example on the CSR.

Expanding to the empty string has the advantage that we can parameterize part of the security configuration and switch between default (global) and alternative security profiles on a per-run basis. This switching can be done by means of an optional System property that can, in turn, be a Java launcher argument. This solution offers more flexibility by making the application of an alternative profile optional, by limiting the scope to a single execution and by allowing non-privileged users to benefit from it. This does not represent any additional risk than using the existing `java.security.properties` System property and pointing to any file. The assumption is that a malicious user will not control the JDK launch arguments to point to any file, and the rest is handled by local file system permissions. It also assumes that the system administrator allowed the optional switching between security profiles by adding a property-based include line to the _java.security_ file. 

For example, a _java.security_ file may have the following:

...
include /path/to/security/profiles/profile_${SecurityProfile}
...


The file _profile__ can be empty or contain default values. With a command such as `java -DSecurityProfile=FIPS` an alternative profile, available in the file _profile_FIPS_, can be applied for a specific execution.

This idea provides flexibility to system administrators and packagers as it does not prescribe the name of the System property or the list of available profiles.

Adding this to the CSR sounds like a good idea. I'm certain that @franferrax will agree.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2066004531