JEP411: Missing use-case: Monitoring / restricting libraries

[Alan Bateman]

On 06/05/2021 11:26, Peter Firmstone wrote:
>
> OpenJDK seems to have assumed that no one was using SecurityManager 
> based on one research report.
>
I don't think this is right. Instead I would say that many of us have 
rarely encountered deployments on the server-side that are using a 
SecurityManager to enforce security as envisaged by the Java security 
model. I've been at Java conferences where the sessions on this topic 
had less than 10 people in the room. Most of the actual usages that I've 
come across have been more like using the security manager as a 
convenient way to intercept network and file access for the purposes of 
logging or blocking. These usages may not have a need for protection 
domains, stack walks, policy files and the other complexity that comes 
with the security model.

One thing that is missing from the discussions here is the cost and tax 
that supporting the SM "operating mode" brings. Many of the big features 
and all changes to security sensitive code must pay this tax. If there 
is a bug, a missing checkPermission for example, then it gets treated as 
security vulnerability at massive cost. Everything asynchronous brings 
more complexity and effort to figure out where the checks should be and 
whether an AccessControlContext needs to be carried around. I look 
forward to the day where we can be like other languages and runtimes 
that don't have to be concerned with this complexity and optional way of 
running.

Finally, just to point out again that this JEP is about deprecating for 
removal in the future, it doesn't propose to remove the security manager 
now. If it moves forward then it will probably be several releases of 
degradation before it is removed. That gives time to properly consider 
the use cases where the security manager is useful today. Also if it is 
eventually removed, then anyone that really depends on this world can 
continue to use supported releases for years to come.

-Alan