JEP 411 - use cases

[Sean Mullan]

Hi James,

On 9/1/21 11:48 AM, Doyle, James wrote:
> 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”?

This is based on various pieces of data accumulated over the years such 
as incoming bug reports, surveys, external papers/studies of the SM, 
source code repositories, product searches, difficulties using the SM, 
declining usage on the client, etc.

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

As described in the Futures section of the JEP, we are looking at some 
alternatives for certain use cases. One of those is to potentially add a 
mechanism that allows applications to monitor and optionally block 
certain operations. The common use case listed in the JEP is blocking 
System.exit, but some others have requested being able to monitor and/or 
block file/network access. These and other alternatives need more 
discussion, but this is the list where it will be discussed.

> 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?

This is probably a question that is best answered by those that work on 
or support WildFly.

--Sean