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.
