JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

I'm grateful for everyone's ideas and feedback, in the coming days & 
weeks I'll put together some documentation to summarize and put some 
time into some proposals, I have a lot of experience with the SM 
infrastructure and its inner workings, having had to work around it's 
pitfalls.

Watch this space, I'll post a link when ready.

Regards,

Peter.


On 5/08/2021 7:27 am, Sean Mullan wrote:
>
> 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
>