On Wed, 17 Apr 2024 14:28:58 GMT, Weijun Wang <[email protected]> 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
