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
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.
3. All remote connections are authorized to perform deserialization.
Depending on serialization long-term seems somewhat dubious.
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.
--Sean
