JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Hello Andrew,

Loss of SM is a significant threat to my software, if left unresolved.

Your interpretations are your own, I make no apologies for your 
interpretation.  I am describing the difficulties that I am experiencing 
with JEP 411 migration and how it applies to my situation, it appears 
that others are having difficulties that they have also expressed on 
OpenJDK lists, please understand that it is not a trouble free 
experience, and as such some of my frustrations may leak through into my 
writing.  In my world, more developers are affected, than are 
unaffected, but those are my associations, not yours, your experiences 
may differ from mine.

What I have stated, is that existing deployed software that uses SM for 
authorization access controls, has been designed around SM and will 
become insecure if SM is removed.   I refer you to the following book, 
which our software security architecture is designed around, I have not 
done research on the number of developers or projects affected (I do not 
have the time or resources).  I do see quite a number of developers from 
various projects have stated they will be affected in some way or 
another on OpenJDK lists, have you followed any up off list, to 
understand how they're impacted?   Or have you written them off as 
/special case/ /special loss/ ?

https://www.oracle.com/java/technologies/javaee/api-design-implementation.html

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).
 2. All remote connections are authorized to load classes.
 3. All remote connections are authorized to perform deserialization.

This doesn't take into account user authorization, with SM gone, it also 
means that all users and services now have all privileges.  I'm only 
documenting the major ones here.

With SM all the above require authorization and authentication, such 
that all remote connections are trusted and without malicious intent.

I have also presented a number of different compromises, that I thought 
might address some of the maintenance cost burdens around SM OpenJDK 
has, so that we might retain the most expensive components to replace.

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.

I have previously offered to donate code to OpenJDK, but I was unable to 
get clarification on whether I could include AL2.0 licensed code from 
other authors, as my code is not my sole works, two of whom have since 
passed away (only one at the time).  The remaining authors, I can still 
get in touch with and request them to sign a contributor agreement, 
which I myself have signed.   I can separate out the parts which I am 
the sole author.  For example my RFC 3986 & RFC 5952 URI implementation 
is derived from Apache Harmony under AL2.0.   This work has been in 
production for many years, and had no issues with the modules added in 
Java 9, which allowed me to use common policy files in my tests for all 
supported Java versions.  It's used in both a ClassLoader and a Policy 
implementation to avoid unnecessary DNS calls.  I have noticed that 
OpenJDK contains code under the AL2.0 license.

This has been a very frustrating experience, I'd suggest, if you haven't 
got anything of value to add, or cannot be part of the solution, please 
don't become part of the problem.  I'm doing the best I can to work 
within constraints to find a solution and am trying not to be part of 
the problem by allowing my frustration leak through, I've deleted more 
than I've posted, I suggest you do the same and direct your attack onto 
problems, rather than people.

Thank you.

Peter.

On 2/08/2021 11:07 pm, Andrew Dinn wrote:
> On 02/08/2021 11:33, Peter Firmstone wrote:
>> I think you may be misinterpreting my comment, let me clarify:
>
> Really? I'd suggest only if you stretch the meaning of your words 
> beyond their elastic limit.
>
>> I'm assuming that during the process of removal of security manager, 
>> any external ports or process hooks that we can only turn off now by 
>> not granting a permission will be replaced by a command line property 
>> or something similar? Eg, Agents, Management, etc. If this is the 
>> case, it would be nice if they were set to off by default, such that 
>> they needed to be enabled from the command line.  It's a suggestion. 
>> . . .
> They might be or they might not be replaced -- and, indeed, you are 
> welcome to help the project to make that a possibility. However, even 
> if they were not replaced or enabled as default behaviours the 
> platform would not fail to be 'secure by default'. At worst, it might 
> be lacking belt and braces when it comes to available means for 
> enforcing some specific forms of control over execution -- controls 
> that can be used to resolve some security problems, but not 
> exclusively. Yet, you keep using language that implies the loss of the 
> security manager is a significant threat to the security of OpenJDK/Java.
>
> Claiming now that all you meant was that you would like to have APIs 
> that give you similar mechanisms to what is being removed does not was 
> and will not validate the use of such exaggerated language. Nor do 
> such statements give anyone confidence that you are able to identify 
> clear and compelling requirements and assess the effort that might be 
> needed to satisfy them and maintain an implementation.
>
> So, maybe you should just stop making out that your concerns are a 
> major problem to most developers and that they threaten the integrity 
> of the platform and instead concentrate on identifying simple and 
> maintainable APIs that we can feasibly add to OpenJDK without 
> incurring an unjustifiable maintenance burden.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>