RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Sean Mullan]

Hello,

Thanks for all the comments so far, and the interesting discussions 
about the future of the SecurityManager. We will definitely return to 
those discussions in the near future, but for now I have a second webrev 
ready for review for this enhancement:

http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/

The main changes since the initial revision are:

1. System.setSecurityManager is no longer deprecated. This type of 
change clearly needs more discussion and is not an essential part of 
this RFE.

2. After further thought, I took Bernd's suggestion [1] and instead of 
adding a new property to disallow the setting of a SecurityManager at 
runtime, have added new tokens to the existing "java.security.manager" 
system property, named "=disallow", and "=allow" to toggle this 
behavior. The "=" is to avoid any potential clashes with custom SM 
classes with those names. I think this is a cleaner approach. There are 
a couple of new paragraphs in the SecurityManager class description 
describing the "java.security.manager" property and how the new tokens work.

3. I also added a comment that Bernd had requested [2] on why 
System.setSecurityManager calls checkPackageAccess("java.lang").

Also, the CSR has been updated: 
https://bugs.openjdk.java.net/browse/JDK-8203316

Thanks,
Sean

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html

On 9/13/18 4:02 PM, Sean Mullan wrote:
> This is a SecurityManager related change which warrants some additional 
> details for its motivation.
> 
> The current System.setSecurityManager() API allows a SecurityManager to 
> be set at run-time. However, because of this mutability, it incurs a 
> performance overhead even for applications that never call it and do not 
> enable a SecurityManager dynamically, which is probably the majority of 
> applications.
> 
> For example, there are lots of "SecurityManager sm = 
> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If 
> it was known that a SecurityManager could never be set at run-time, 
> these checks could be optimized using constant-folding.
> 
> There are essentially two main parts to this change:
> 
> 1. Deprecation of System.securityManager()
> 
> Going forward, we want to discourage applications from calling 
> System.setSecurityManager(). Instead they should enable a 
> SecurityManager using the java.security.manager system property on the 
> command-line.
> 
> 2. A new JDK-specific system property to disallow the setting of the 
> security manager at run-time: jdk.allowSecurityManager
> 
> If set to false, it allows the run-time to optimize the code and improve 
> performance when it is known that an application will never run with a 
> SecurityManager. To support this behavior, the 
> System.setSecurityManager() API has been updated such that it can throw 
> an UnsupportedOperationException if it does not allow a security manager 
> to be set dynamically.
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053
> 
> (I will likely also send this to core-libs for additional review later)
> 
> --Sean