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

Reply via email to