Request - Preparation for removal of SecurityManager

[Peter Firmstone]

Hi Sean,

I would be quite willing to undertake the work.

We have a decision to make based on when & how SM will be removed, for 
obvious reasons, this decision will be delayed as long as possible:

 1. Pull the plug on our existing Java software development efforts,
    currently our software depends on SM for authorization decisions and
    authentication of our secure endpoints.  Our software is built on SM
    and would require a complete architecture redesign, and we simply
    don't have the resources to replace decades of development effort.
 2. Implement a new authorization layer to replace SM functionality.

#2 is our preferred option.

We need to replace permission check hooks in the JDK by instrumenting 
it, as per OpenJDK advise.  I had identified that this wasn't possible 
to do so securely with finalizer's enabled, from JDK18 on we can disable 
finalizers, so it enables us to commence development.   OpenJDK has 
advised that all functionality of SM may be implemented independently by 
application developers and run on top of JDK.

Basically I'm requesting controlled dismantling of SecurityManager, as 
opposed to sudden destruction, to allow us time to develop and implement 
our migration strategy.

Using the existing permission check hooks in the JDK allows us to 
significantly speed up our development efforts.   Each time a permission 
check hook is removed, we will need to replace it with 
instrumentation.   I was hoping this could be done in a controlled manner.

The first step would be to instrument Permission#checkPermission, as 
this provides access to all the existing hooks within the JDK.

The API's changed to not throw SecurityException won't break backward 
compatibility and won't impact us.

We haven't yet tested how our software will behave without the 
PrivilegedAction's in JDK code, or preservation of AccessControlContext 
in executor threads etc, but we need to start exploring that to fully 
understand it before the SM removal JEP is created.

-- 
Regards,
  
Peter Firmstone


On 26/10/2022 5:55 am, Sean Mullan wrote:
> When support for the Security Manager is removed, there would be 
> little benefit to keeping the permission checks inside the JDK, since 
> it would no longer be possible to set a Security Manager. Also, many 
> APIs that perform permission checks will likely be modified to no 
> longer throw SecurityException.
>
> --Sean
>
> On 10/25/22 2:25 AM, Peter Firmstone wrote:
>> Would the OpenJDK team consider the following?
>>
>> Where SecurityManager is invoked directly now, such as:
>>
>>
>>           @SuppressWarnings("removal")
>>           SecurityManager sm = System.getSecurityManager();
>>           if (sm != null)
>>               sm.checkPermission(new RuntimePermission("setFactory"));
>>
>> Can we change these routines to the simpler form:
>>
>>           newRuntimePermission("setFactory").checkGuard(null);
>>
>> This will give us more time to transition to a replacement authorization
>> layer.
>>
>> We can instrument the Permission#checkGuard method, this will assist us
>> to utilise existing Permission check hooks after SecurityManager is
>> removed.    Longer term we will need to maintain our own instrumentation
>> hooks, but this will go a long way towards giving us a head start, by
>> leveraging the existing.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20221026/e510bc5c/attachment.htm>