JEP 411, removal of finalizers, a path forward.

[Sean Mullan]

On 8/3/21 8:10 PM, Peter Firmstone wrote:
> On 4/08/2021 2:40 am, Sean Mullan wrote:
> 
>>
>>
>> On 8/2/21 8:28 PM, Peter Firmstone wrote:
>>> In JGDMS without SM, at least the following must be addressed to
>>> maintain security:
>>>
>>>    1. TLS and Kerberos connections cannot be established.  (My
>>> software is
>>>       littered with doPrivileged calls that preserve the Subject, we
>>> don't
>>>       have anon TLS connections, we require client certificates).
>>
>> As mentioned several times, this use case will be preserved and is
>> already covered in JEP 411:
>> https://openjdk.java.net/jeps/411#subject-doas
> 
> Yes, that's true, a secondary consideration is the amount of work that
> will be required to support different versions of Java, no doubt
> reflection will be helpful, to check for the existence of the new
> methods.   Last time I checked, I have around 1,000 locations in the
> code that will require changes.   My motivation for mentioning it was to
> highlight the benefit of reusing existing methods, which currently
> provide this functionality.

This is a case similar to AccessController.doPrivileged where we could 
potentially keep the existing APIs in place for a longer time period 
until such time the compatibility risk is low and applications/libraries 
have had ample time to convert to the new APIs. See the paragraph about 
degrading APIs in JEP 411: https://openjdk.java.net/jeps/411#Description

As an interim step, the existing APIs could be adapted such that they 
simply call the new APIs which will likely use a different mechanism to 
transfer the Subject across API boundaries (ThreadLocals or eventually 
Scope Locals, when they arrive).

>>>    2. All remote connections are authorized to load classes.
>>
>> Not sure why you can't do something with a custom ClassLoader that
>> only loads classes for authorized users.
> 
> Interesting, what do you have in mind?

I don't know, it was mostly just an idea I am throwing out based on your 
#2 statement above. I don't have the time to fully understand your 
model, but more simply if you know who is authorized and who isn't, it 
seems like you would have direct control over what the users are 
authorized to do and instead of relying on the Security Manager to catch 
operations already in motion, you could prevent them before they even 
occur. This seemed like one of those cases.

>>> Having established that OpenJDK is not yet willing to compromise, I have
>>> been attempting to create an authorization layer using Agents, so that I
>>> can restore perimeter security following the removal of SM and support
>>> future versions of Java.   It is my hope that either I will be
>>> successful in recreating an authorization layer, or that enough people
>>> come forward and OpenJDK decides there are enough affected developers to
>>> find a compromise that either makes migration practical, or less
>>> expensive.
>>
>> You may have some interesting ideas, but in my opinion you have not
>> presented them in a clear and easily digestible manner, and your long
>> emails are time consuming to read, repetitive and often diverge into
>> rants. (Keep in mind there are many people on the jdk-dev alias, and a
>> lot of them may not care about this topic). It is to the point where I
>> only skim your emails quickly. I would take the time to write up your
>> ideas in an external place. It may not go anywhere, but at least you
>> would have a single place where your proposal, experiments, etc are
>> documented.
> 
> It's a two way street, I'm currently penetration testing OpenJDK dev's
> to discover their pain points with SM architecture, as they haven't
> documented them in JEP411.  When I am sure I have discovered your pain
> points, I plan to document a proposal. There's no point writing
> something up that address the wrong pain points.
> 
> On that topic, I think for historical purposes, JEP 411's wording could
> more accurately reflect the experiences of developers who overcame the
> shortcomings that beginners experience with SM.   JEP 411 does well to
> document beginners experiences when first attempting to use SM, however
> I think this unfairly penalizes the original authors, history should
> look more kindly on their achievements.  SM is a great achievement that
> stood the test of time for over 20 years, and no one else has succeeded
> at this task, it's not perfect, but it works well for those who are
> using it to it's full potential.  It's association with Applets and
> their use of ClassLoaders as a weak form of isolation, and the resulting
> permission sprawl that eventuated as band-aids to each vulnerability, is
> unfortunate.

I don't disagree that the SecurityManager was a significant achievement. 
But I think JEP 411 presents a fair picture of how it played out over 
the years, and captures the main issues that most users and developers 
faced when trying to use or deploy it.

--Sean