JEP 411 - use cases

Doyle, James jdoyle at iso-ne.com
Wed Sep 1 15:48:47 UTC 2021


Hi,

Earlier this summer, our organization became aware of JEP-411 and the plan to remove Security Manager in the future, and I'd like to add our perspective to the use case / adoption aspect.

We deploy and manage a number of server-side Java applications, both developed in-house and from vendors, and currently use Java Security Manager to provide an extra layer of security around the server application code.  Enabling Security Manager in the server application JVM provides an additional means to defend against malicious users/clients exploiting vulnerabilities (in our application code or third-party code) to access the host OS in ways the individual JVM and application are not intended to act.  The fine-grained permission model is very useful for giving the application code the least privilege needed for its specific function.  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.  Our organization operates under compliance oversight, and the Security Manager policy for our applications provides one of the controls we use to insure a secure environment.  We're worried about the impact to these controls should Security Manager be removed.

Is the low adoption rate cited in the JEP ("After decades of maintaining the Security Manager but seeing very little usage...") anecdotal, or has it been measured somehow as part of proposing and implementing the JEP?  What qualifies as "low" or "little"?

Is the use case above one that the OpenJDK team is considering, to make sure workable alternatives are available before removing Security Manager?

Some of our Security Manager usage is via Java EE / Jakarta EE Security Manager permissions, and within that set, some apps specifically use WildFly Security Manager.  Will the removal of Security Manager from OpenJDK make related implementations like WildFly Security Manager impossible to maintain as-is?  Will the removal of Security Manager make users dependent on vendor-specific implementations like WildFly Security Manager and unable to freely move between Java EE / Jakarta EE implementations?

Thanks for your time.

Sincerely,
Jim Doyle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210901/cd58d4f1/attachment.htm>


More information about the security-dev mailing list