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
