<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>People believed Java Serialization was secure for a long time, I
had arguments about that too, long before it was public knowledge,
until it wasn't, then it couldn't be fixed fast enough to keep up
with vulnerabilities.</p>
<p>You nonchalantly plan to remove the SM infrastructure while
blocking us from developing a new Authorization framework. It's
vandalism.<br>
</p>
<p>So after 20 years of developing Java, it's come to this. <br>
</p>
<p>It leaves a bad taste in my mouth.<br>
</p>
<p>Old man yells at cloud!</p>
<div class="moz-cite-prefix">On 10/02/2023 9:21 am, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ebfeb6da-9ddd-bbd7-2527-d4da6df906fb@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Please undeprecate DomainController interface,
AccessController, AccessControlContext and Subject methods,
while removing the remaining methods in JEP411.</p>
<p>Just document that these methods don't do anything by default,
and use the null object pattern where appropriate.<br>
</p>
<p>Deprecation is causing developers to remove code that we need,
this is undoing years of hard work, I'm appealing to you to
minimise harm where possible.<br>
</p>
<p>eg: <a class="moz-txt-link-freetext"
href="https://github.com/apache/lucene/issues/11801"
moz-do-not-send="true">https://github.com/apache/lucene/issues/11801</a><br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter </pre>
<div class="moz-cite-prefix">On 10/02/2023 9:03 am, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:50be4e5e-7150-0a0b-6612-9fe5c70f02fe@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Maybe I had the wrong Subject?</p>
<p>I'm still trying to figure out how to migrate before removal
of deprecated API's.</p>
<ol>
<li>Our software architecture is designed and currently relies
on classes in JEP411 for authorisation decisions.</li>
<li>It's not possible for our software to have security bolted
on as an afterthought, following removal of authorization.</li>
<li>Without authorization, we cannot allow the JVM to have
access to sensitive information.<br>
</li>
<li>We could place the JVM inside an isolated VM as suggested
by JEP411 proponents, but we can no longer allow the JVM to
have access to sensitive information. It is technically
possible to do this, provided we accept we could no longer
use encryption or authentication, as we cannot introduce
sensitive information into the JVM, then we could use
observability tools as a watchdog, to shutdown and restart
the VM if it becomes compromised. However, that leaves us
with very limited functionality.<br>
</li>
</ol>
<p>I realise that OpenJDK likely thinks this is BS, we can just
safely remove SM, it's obsolete now right?<br>
</p>
<p>The problem is, we don't fit the standard category of server
programming, eg: once the JVM's warmed up, it no longer
dynamically loads classes, hotspot has compiled them to native
binary code; a server that fits the publish subscribe model,
where it only need parse and validate incoming data from
clients, and publish responses. Server programming is
OpenJDK's target market, we get that. Anything in the client
space is frowned upon, we get that too, but we're not in the
client space. Our clients are also servers.<br>
</p>
<p>Our distributed service architecture provides dynamic
discovery of services (globally over IPv6). We rely on
Authentication, Encryption (Privacy) and Authorization.
Clients of services are often required to download code
dynamically, clients and services first discover and
authenticate available service registrar's using an X500 IPv6
multicast discovery process, with checksums to validate
details required to establish a unicast connection. Unicast
IPv6 TCP with Encryption is used to ensure that communications
are private between authenticated connections while
establishing connections to service registrar's.<br>
</p>
<p>Nodes in the distributed network, aren't distinguished as
servers and clients, a node that acts as a client will also
provide services, even if it's just listening to an event
service. All threads are run with authenticated client
endpoint Subject's, and service responses with server
Subject's, to allow the use of authenticated TLS connections.<br>
</p>
<p>After nodes have discovered each other, the connection is
established like so:</p>
<ol>
<li>Authentication & Establish an Encrypted connection.</li>
<li>The service provides the client with; code signer
certificates, if the service requires codebase download, or
it may provide a security hash, used to validate files, it
will also communicate a string that represents URL's from
which code can be downloaded. It will also communicate any
permissions it requires. The client Subject is allowed to
grant a restricted set of permissions. The client may
elect to grant the requested permissions, if it has the
privileges to do so.</li>
<li>The client provisions a ClassLoader, that's a child of the
ClassLoader that contains the Service's public API, the
identity of this ClassLoader is determined by the CodeSource
URI's as well as the Authenticated identity of the
Service. The ClassLoader of the service proxy represents
it's identity in authorization decisions at the client.
Other service proxy's may use the same codebase URL's, but
unless they have identical identity, cannot load their
classes into another service proxy's ClassLoader.</li>
<li>At this point, the client unmarshal's the service proxy's
Object state into the ClassLoader, it doesn't use Java
de-serialization to do this, just in case anyone is curious.</li>
<li>Only ClassLoaders are responsible for Class resolution,
codebase annotations are not used, neither is RMIClassLoader
used to resolve classes.<br>
</li>
<li>Now the client (and server) applies constraints to their
service endpoints, placing restrictions on the level of
encryption the service can use for network communications,
or the Principal's the Subject that invokes the service must
have.<br>
</li>
<li>The client can now use the service, by passing parameters
to the proxy's methods and accepting returns. The service
proxy may accept or return other services, these services
will have the same constraints applied, unless clients or
services, apply new constraints.</li>
<li>A JVM node may have any number of services proxy's while
also providing services to other nodes, of many different
identities, numerous services may participate in
transactions, each one with it's own identity.<br>
</li>
</ol>
<p>During this process permissions are granted as they are
required, once a service is no longer used, its ClassLoader
becomes unreachable, permissions granted dynamically are
removed. The client environment is otherwise locked down
with least privilege policy files, that were generated and
audited during deployment.<br>
</p>
<p>We would like to continue to invest in the development of
this software, it's performant, it scales, encryption is very
fast, thanks to recent developments in Java session tickets.
We've eliminated unnecessary DNS calls (the JVM makes many of
these, eg URL, SecureClassLoader, CodeSource), and cleared out
synchronized and blocking code, replaced it with concurrent
non blocking code where possible. It's well tested, much
time has been invested into static analysis and cleaning up
and modernizing code. All our hotspots are native JVM
methods. I suspect this is why we are finding bugs in your
TLS code, it isn't thread safe ;)</p>
<p>Hopefully there is a future for this software, however it
will depend our ability to migrate to new versions of Java as
they're released.</p>
<p>At least allow us just these few classes to remain
(un-deprecated please, so developers aren't motivated to
remove their privileged calls), even if they contain no
implementation, so that we may instrument them, as we attempt
to stay current with OpenJDK.</p>
<p>We are not asking OpenJDK to maintain OpenJDK security using
an authorization framework, we are just asking you to make it
possible for us to maintain our software's security ourselves
while running on your platform. It's not really possible for
us to run on anything else.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter.</pre>
<div class="moz-cite-prefix">On 9/02/2023 10:20 am, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6ff1e3d1-d55f-5d19-954e-4849981064ae@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>I don't think I'm really asking for much here. JEP411's
plan will destroy our ability to manage user and service
authorization in our existing software, at least cut us a
little slack. I wish we built our software on some other
authorization API, unfortunately we didn't.</p>
<p>We're just trying to migrate as best we can to future
versions of Java.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone</pre>
<div class="moz-cite-prefix">On 7/02/2023 12:53 pm, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bd165423-b6cc-65f8-ddf3-b9e05f099a83@zeus.net.au">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<p>Hello OpenJDK folk,</p>
<p>SecurityManager, AccessController and
AccessControlContext will be removed in a future version
of Java.</p>
<p>Just briefly: Our software is heavily dependant on Java's
Authorization framework, we use ProtectionDomain's to
represent remote services for authorization decisions. We
are working out how to implement a new authorization
framework after SecurityManager's removal.<br>
</p>
<p>Many libraries call AccessController#doPrivileged
methods, when these methods are removed, we're going to
have a big problem with viral permissions. Restricted
authorization will become meaningless if it has to be
granted to all domains on a call stack.<br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://github.com/opensearch-project/OpenSearch/issues/1687"
moz-do-not-send="true">https://github.com/opensearch-project/OpenSearch/issues/1687</a></p>
<p>Retaining methods in the platform that developers can
instrument will provide a common frame of reference for
authorization decisions, that's runtime backward
non-breaking, without burdening OpenJDK with maintenance.<br>
</p>
<p>I'm requesting retaining the DomainController interface,
AccessController, AccessControlContext and Subject methods
as no-op's for instrumentation? Please leave them
deprecated as no-op's, but not "deprecated for removal".<br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://github.com/pfirmstone/HighPerformanceSecurity"
moz-do-not-send="true">https://github.com/pfirmstone/HighPerformanceSecurity</a></p>
<p>Some thoughts:</p>
<ol>
<li>Ability to disable finalizers in Java 18 onwards is
important to prevent finalizer attacks when
instrumenting constructors to throw a RuntimeException.<br>
</li>
<li>Guard#check methods can be no-op's for
instrumentation. If I can replace all instances of
SecurityManager#checkPermission in OpenJDK with
Guard#check, I can contribute the patches, this will
assist greatly in the transition process of retaining
existing hooks, while developing replacements.<br>
</li>
<li>Reduce the size of the Java Platform's trusted
computing base by giving all system ProtectionDomain's a
CodeSource with a non-null meaningful URL.
Unfortunately Java Serialization is in the base module,
so we cannot authorize it's use with a permission check,
as the base module needs AllPermission, it has to be
managed with serial filters (<a
class="moz-txt-link-freetext"
href="https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin"
moz-do-not-send="true">https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin</a>
- perhaps someone will write a serialfilter generation
tool that works similarly to our POLP policy generation
tool?). Privileges cannot be elevated by an
authenticated Subject, when all domains on the call
stack are already privileged. If Serialization was in a
different ProtectionDomain, then we could prevent
de-serialization for unauthenticated Subject's.
Perhaps OpenJDK might consider moving Serialization into
a different module in future before it's eventual
removal?<br>
</li>
<li>Instrument all data parsing methods with guard checks,
eg XML. This allows authorization decisions to parse
remote data based on the Principal's of the remotely
authenticated Subject, to prevent injection attacks.</li>
<li>We already have principle of least privilege policy
generation tools and efficient policy checking tools for
authorization in place. These allow for simple policy
file generation, auditing, editing and deployment.<br>
</li>
</ol>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>