Create a statement for EE10 and beyond regarding deprecation of SE SecurityManager

[starksm64]

With the upcoming deprecation and ultimate remove of the java.lang.SecurityManager and most related APIs as described in: https://openjdk.java.net/jeps/411, we need a direction statement to guide specification teams.

Deprecation in EE10 with removal in EE11 would be one obvious choice. Removing TCK tests related to the SecurityManager would be another level.

[arjantijms]

Example of problematic usage in an API (Jakarta REST as an example here) that will prevent the API to be consumable on the JDK where the Security Manager is removed. The below already causes many warnings on JDK 17:

jakartaee/rest@08e4014#diff-57262a7b10c15465abcec01c609351e87fab25a4cbd548305df98416a5860133R189

cc @spericas

[mnriem]

As this breaks customers running with a new version of Java I disagree with deprecation and removal route mentioned above. It should be handled as TCK challenges against EE 8 and EE 9 and those tests should be excluded for those versions. And for EE 10+ those tests should immediately be removed. And for EE 8 and EE 9 errata statements should be made so a vendor is free to remove the functionality in their implementations. And for EE 10+ this functionality should not exist.

[starksm64]

@mnriem I am implying removal of the SecurityManager related TCK tests in EE10 by the statement that "Removing TCK tests related to the SecurityManager would be another level.", meaning, another level of action to take in EE10.

[mnriem]

@starksm64 Thanks for the clarification. Note I have filed separate TCK challenges for EE 8 and EE 9 as this goes beyond the scope of just EE 10+.

[ivargrimstad]

Here is a shared document for the statement: https://docs.google.com/document/d/1rZqimXJvkfFMxx_nxJ61buiTMcwhsWVVpXT65pjZzgI/edit?usp=sharing

[starksm64]

A WildFly user had created a thread in the OpenJDK security-dev list asking about what support the JVM would be providing for the removed features:
https://mail.openjdk.java.net/pipermail/security-dev/2021-September/027279.html

It seems that the platform team needs to evaluate what are user usecases that would require some support at the JVM level because they could not easily be replaced. The concern is that Jakarta EE has users making use of the security manager, and the platform team needs to provide feedback to the OpenJDK team with regard to uses they may not have awareness of.

[arjantijms]

@starksm64

The permissions give us a way to use a deny-by-default model and require a whitelist of the files, directories, hosts, ports, URLs, etc. that each application actually needs.

Perhaps this needs to be looked at, and investigated why exactly a minimal OS in a virtual server, running the AS with a user with minimal privileges, and a restricted number of outgoing ports and hosts (outgoing firewall) can not do this.

The concerns themselves as reported seem absolutely valid, there's no question about that. But just anecdotal in my own experience for the my own use cases I've always been able to mitigate those concerns using the above strategy.

[starksm64]

I'm sure that could be a way to mitigate the loss of the SecurityManager, but the problem is that Java EE/Jakarta EE have advocated the SecurityManager for decades and, the deployment environment and its configuration have never been part of EE. Users are rightly thinking WTF, you said the SecurityManager was a way to achieve more security, and now your expecting me to have non-portable cloud/OS configuration take care of this? This is definitely a rug pull move.

The other mismatch in expectations that I feel EE still promotes is the notion of layers of trusted code where you have an application server that is trusted, and user code that has less trust. It is coming from the now outdated multi-tenancy notions of running an app server. AC.doPriviledged(...) is at the heart of this.

[dmatej]

In my opinion - I would kill it soon, because years ago I had to edit the policy file of SGES/SJAS9/GF even to make it work without exceptions (we used cluster, huge system); later we just disabled it, there was always 'yet something'.

If we want a better security, we should at least use more QA checks (any usable, SpotBugs, SonarQube, PMD, basic Checkstyle ...) and fix all issues. Improve test coverage, etc. It is a huge amount of work, but I believe with much better effect on security (and everything) than maintaining SecurityManager forever.

[starksm64]

Candidate statement on deprecation of the SM for removal post EE10:
https://docs.google.com/document/d/1fOxfL3AUj_wr29kW3fwvUUloGxHhpoAXEW_x-fkyfFs/edit?usp=sharing

[starksm64]

This statement will incorporate #460

[starksm64]

We have added a statement that the SecurityManager is deprecated for removal as of EE10.