New candidate JEP: 411: Deprecate the Security Manager for Removal

[Sean Mullan]

On 4/29/21 1:37 AM, Peter Firmstone wrote:
> Which version of Java is this planned for?   Will the last version 
> supporting the security manager be a long term support version, eg back 
> ports of security patches and TLS technologies?

The JEP has not been targeted to a release yet, but the Security Manager 
(SM) will continue to be supported in current/previous releases, and its 
full functionality will be supported in the release it is targeted to 
(if approved). So, if it goes in 17, the SM will be deprecated but it 
will still be fully functional, although you may have to enable it on 
the command-line with the system property 
"-Djava.security.manager=allow". See the warnings section in the JEP for 
more details [1].

Subsequent releases may degrade the Security Manager APIs such that it 
is not fully supported but the intent is to try to preserve 
compatibility such that libraries that are coded with doPrivileged 
blocks continue to work without re-compilation for a number of releases 
before the APIs are actually removed. See the 2nd bullet of [2] in the JEP.

> We have our own security manager implementation and policy provider 
> implementations.  Both of these are high performance and non-blocking 
> and we are able to dynamically grant and revoke some permissions. While 
> I acknowledge the Java policy implementation has a significant 
> performance impact, due to blocking permission checks, ours is less than 
> 1%.  Our software doesn't share PermissionCollection instances among 
> threads, or even have a Permissions cache, PermissionCollection's are 
> generated for each permission check and discarded for garbage 
> collection, the Permission object themselves are cached (after 
> initialization and safe publication), as are the results of repeated 
> permission checks.  We also have our own Permission implementations.

Yes, you and I had discussions about this several years ago and I 
believe I asked if you would be willing to donate these performance 
improvements. I can't remember but I think you had interest in doing 
that but couldn't make it happen for some reason.

> We have tools that generate policy files with least privilege, although 
> we will manually alter them with wildcards, for network connections for 
> instance.
> 
> In our software, dynamic permissions are granted after authentication of 
> TLS connections.
> 
> It is too early for me to tell if there are suitable replacement 
> technologies available.  I can understand the motivation for reducing 
> Java's software development burden, but I think this version of Java 
> might be the last for us, it would certainly be good if a long term 
> support version was available, perhaps indefinitely lol.

Well, indefinitely is a strong word :), and this is really based on 
vendor's support models, but I think it is safe to say the SM will be 
supported for at least 5-10 years into the future on 17 or previous JDK 
releases.

Thanks,
Sean

[1] https://openjdk.java.net/jeps/411#Issue-warnings
[2] https://openjdk.java.net/jeps/411#Risks-and-Assumptions

> Regards,
> 
> Peter Firmstone
> Zeus Project Services Pty Ltd.
> 
> 
> On 16/04/2021 4:05 am, mark.reinhold at oracle.com wrote:
>> https://openjdk.java.net/jeps/411
>>
>>    Summary: Deprecate the Security Manager for removal in a future
>>    release. The Security Manager dates from Java 1.0. It has not been the
>>    primary means of securing client-side Java code for many years, and it
>>    has rarely been used to secure server-side code. To move Java forward,
>>    we intend to deprecate the Security Manager for removal in concert 
>> with
>>    the legacy Applet API (JEP 398).
>>
>> - Mark
>