JEP 411 Deprecate the Security Manager for Removal

[pfirmstone]

OpenJDK is planning to remove the SecurityManager in a future version of Java.

The ability to have different permissions for ProtectionDomain's in a Java Process will no longer exist. The OpenJDK project appears to be planning new api's for JAAS.

At this time, it is not clear what the new API's will be, however this will break both existing implementations that utilize JAAS as well.

It seems likely that there will be a large amount of existing deployed code, that will not run on later versions of Java. It is unlikely to impact this project for at least 8 years. After which it seems likely that there will be a large enough community to support a version of Java that includes back-ports from later versions for useful features.

Perhaps signer certificates will allow an organization to have it's own system, to use smart proxy's without inviting others in, but it seems that they will be unable to limit the permissions of third party library code. No doubt, hardening up serialization and other existing attack vectors, while removing controls over third party library code, will invite attackers to contribute to and plant vulnerabilities into library code.

JGDMS makes it practical to deploy the principle of least privilege, as proxy code contains the permissions required, dynamic permissions are granted after authentication, UmbrellaPermissionGrant and the policy auditing tool that's used to create policy files for editing:
-Djava.security.manager=org.apache.river.tool.SecurityPolicyWriter

[pfirmstone]

It looks like Java 17 will remain compatible, this is an LTS release, so we currently support Java 8 to 17.

This project won't be upgrading beyond Java 17 LTS, until new Security API's are developed that are at least as secure as existing API's. All developers are encouraged to use the SecurePolicyWriter tool to apply the principle of least privilege to policy files.

[pfirmstone]

As of JEP 411, there is no standard way to obtain credentials for TLS and Kerberos connections without using "deprecated for removal" API. Until OpenJDK develops new API's for obtaining credentials, and allows preservation of the user Subject between threads, similar to AccessController.doPrivileged methods, that are used now, it will not be possible to make callbacks using user credentials over TLS or Kerberos connections in future versions of Java.

For this reason, I advise against the use of Java 17+ until OpenJDK develops new API's.

[pfirmstone]

OpenJDK has been receptive to assigning CodeSource's with JRT URI's to ProtectionDomain's of JDK implementation code. This will significantly reduce the size of the trusted computing base, reducing the size of the task to plug authorization security holes in the JVM. Note that the JVM will never be suitable for running completely untrusted code, some level of trust will be required as denial of service will always be possible.

[pfirmstone]

My current thoughts are:

1. Application code should be required to make a privileged call.
2. Application code should have no permission at all if it hasn't made a privileged call, this eliminates viral permissions.
3. If library code requires privileges, the application code should call it with a privileged call. We will need to instrument Runnable or Callable tasks to preserve call contexts in executor tasks, in case of libraries using executors. As for supporting preservation of call contexts in new threads, I'm not sure this is a good idea.
4. If only JDK code is on a call stack, then it should be considered equivalent to a privileged call, it will only have the privileges granted in policy files.

[pfirmstone]

Can we decorate Runnable or Callable tasks? Perhaps instead of decorating the Runnable or Callable, we should decorate Executors and wrap the Runnable or Callable tasks with context, if the Executor has been called with a privileged call.

[pfirmstone]

JEP 421 added a "--finalization=disabled" option to JDK 18:

https://openjdk.java.net/jeps/421#Command-line-option-to-disable-finalization

It will be a requirement to disable finalization for security reasons, as some constructors will need to be instrumented, if they throw a SecurityException, it would potentially allow a partially constructed object to be accessed during finalization.

[pfirmstone]

Jini Security class that has equivalent methods to replace AccessController methods, all code that currently uses AccessController should be changed to use net.jini.security.Security methods.

https://pfirmstone.github.io/JGDMS/jgdms-platform/apidocs/net/jini/security/Security.html

OpenJDK progress on replacement JAAS methods:
https://bugs.openjdk.org/browse/JDK-8296244
https://bugs.openjdk.org/browse/JDK-8276807

[pfirmstone]

When OpenJDK disables the use of SecurityManager, we will look to cooperate maintaining a long term support version of Java which does.

Eventually we may bundle a version of OpenJDK with JGDMS and call it something other than Java.

[pfirmstone]

The discussion on Opensearch is worth a read.

opensearch-project/OpenSearch#1687

[pfirmstone]

Removal of SecurityManager will introduce a significant number of security holes, that attackers will be able to take advantage of, as such running without it is not recommended.

We will update this issue when we know which versions of OpenJDK cannot be supported.

For now I'm closing this issue, as there is nothing more we can do, the problem is caused by OpenJDK and can only be solved by OpenJDK, they have no plans to provide any API, that would enable us to implement a replacement Authentication framework.

[pfirmstone]

A brief update:

1. SecurityManager is deprecated but still functional in OpenJDK
2. The Java 2 security model is deeply entangled with the JVM and cannot be implemented separately.
3. Once SecurityManager is deprecated for removal:
4. I will maintain a fork of OpenJDK that retains the removed functionality
5. Replace the old poor performing implementation code, with high performance code from JGDMS.
6. At that time, I will also fix issues with Permission implementations, eg, allow grants to subnet masks and IP address ranges and add permission checks to data parsing (deserialization), to allow permissions to be granted to authenticating users, instead of trusted code, the data must also be trusted.