JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

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.

>
>>   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?

We currently do have a hierarchy of custom ClassLoaders, however its 
concern is class resolution at client endpoints (Warning this isn't 
simple and may be confusing if you're not familiar with Jini and I may 
not be able to explain it sufficiently for it to be simply understood).

We have solved some extremely difficult software design problems that 
Sun Microsystems left unresolved with Jini.

https://dl.acm.org/doi/epdf/10.5555/1698139

Our software architecture is designed for separation of concerns.  
Grafting authorization onto ClassLoader's doesn't sound like a good 
design decision, however I'm listening.

Our current ClassLoader inheritance hierarchy:

SecureClassLoader -> URLClassLoader -> RFC3986URLClassLoader -> 
PreferredClassLoader

The reason I highlight SecureClassLoader is, we override 
SecureClassLoader methods to replace CodeSource, with a CodeSource that 
uses RFC3986 and RFC5952 normalization for identity in 
SecureClassLoader, to avoid DNS calls and to normalize IPv6 addresses 
where DNS isn't used and endpoints contact each other directly and their 
identity needs to be defined by their normalized address.

However, PreferredClassLoader, modifies class resolution, allowing the 
authenticated service to resolve classes that it prefers, from it's own 
CodeSource, before they are loaded from the parent ClassLoader, that it 
lists as preferred, allowing the service to have a weak form of 
Isolation (we didn't design this, inherited from Sun).

In our JERI (Jini Extensible Remote Invocation) Endpoints, ClassLoader's 
are assigned at both Client and Server Endpoint's, for class resolution 
(we designed this), and at the client endpoint, each ClassLoader is 
unique to the identity of the Service, the authenticated Subject of the 
Service, is part of the Service identity.  Only the Service can 
deserialize (not Java serialization) into this ClassLoader, but only 
after authenticating.

Unlike Java RMI, we don't annotate codebases in the stream (a mistake 
that duplicates the ClassLoader class resolution mechanism), instead we 
assign ClassLoaders for class resolution at both endpoints when the 
streams are created, the ClassLoader is provisioned with the correct 
codebase for the service, after authentication.

A user is assigned GrantPermission( Insert Java permission here) in 
policy files, users can dynamically grant permissions to a Service, 
after it has authenticated, the service, advises the client of 
Permissions it needs, the permissions granted are the intersection of 
the sets of what the client is willing and authorized to grant, and the 
permissions requested by the Service.

This might highlight why the simplest option at this time is to 
re-implement an authorization layer.

The resulting capability and power of these features are not widely 
understood or known.   Think of a service, that can be advertised on any 
IPv6 network, anywhere in the world, and be discovered by a user on an 
IPv6 anywhere else in the world, without an intermediary.  Over secure 
sockets.  Provided the user and the service have common trust 
certificates, they could be from the same company, or part of a club or 
organization.

For example multiple parties can participate in a transaction globally.

>
>>   3. All remote connections are authorized to perform deserialization.
>
> Depending on serialization long-term seems somewhat dubious.

Agreed, in many of my previous emails I've added brackets after 
serialization that state (not Java serialization), perhaps I should just 
start calling it not Java serialization, this was written prior to the 
introduction of serialization filters, to address the shortcomings of 
Java Serialization, it's a subset of Java serialization re-implemented 
to use constructors and parameter type checking.   We've had 10 years to 
prepare for Java Serialization's removal, which seems overdue now.  I 
was currently working on a public Serialization API that would allow 
JERI to have an extensible serialization layer, to allow the use of 
various protocols, however that is on hold, until (assuming) I can 
resolve JEP 411.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicMarshalInputStream.java

>
>> 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.

Some of these problems solved today, that JEP 411 is undoing, took years 
to solve the first time around.   Don't expect it to be easy to understand.

Thanks,

Peter.