<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Alan,</p>
<p>Personally, I would hope that nothing happens until after Java
21, time is precious, we'll need all the time we can get.<br>
</p>
<p>I was hoping, that all privileged actions might be retained
indefinitely, so that we may instrument them. Perhaps in future
they may also have other uses with Subject.<br>
</p>
<p>I only ask that we be allowed the opportunity to build a better
authorization framework (we have to build one, but I'd like it to
be an improvement, rather than a compromise), there have been many
lessons learned from Li Gong's work. I think I've demonstrated
what's possible with JGDMS. Previously, I've only been able to
work around the problems in OpenJDK, as a downstream developer,
but within the JDK, there is so much more opportunity. Beyond
any doubt, concurrency was a far greater challenge than
authorization ever was and look how good concurrency is today. <br>
</p>
<p>The three design issues, fix these and maintenance is
significantly reduced (I couldn't solve these as a downstream
developer): <br>
</p>
<ol>
<li>Privileged calls need to be short and sweet, outside of
privileged calls, there should be zero privileges, this
addresses viral permissions.<br>
</li>
<li>The trusted computing base is far too large, it should be
limited to a small part of the Java platform.</li>
<li>Parsing of remote data required permission checks, to allow
decisions to parse based on trust with the remotely
authenticated subject, this could have prevented the much of the
de-serialization security debacle in server side programming,
similar to how Elasticsearch avoided the log2j problem.</li>
<li>Make it easy to set up and use (I was able to mostly solve
this with tooling).</li>
</ol>
<p>I certainly solved the performance issues and wrote tools to
generate policy files, which made life a lot easier.</p>
<p>Personally I'd like to replace all blocks with
System::getSecurityManager and permission checks, with
Guard::checkGuard, as it would allow us to instrument guards too,
while also allowing a level of indirection to simplify the removal
of SecurityManager as a no-op.<br>
</p>
<p>I've previously solved problems far more difficult than this.
For example, RMI has problems with class resolution, the original
designers tried to append codebase annotations within the
marshalled streams, performing class resolution during
deserialization using RMIClassLoader.
<a class="moz-txt-link-freetext" href="https://web.archive.org/web/20060514011913/http://research.sun.com/technical-reports/2006/smli_tr-2006-149.pdf">https://web.archive.org/web/20060514011913/http://research.sun.com/technical-reports/2006/smli_tr-2006-149.pdf</a></p>
<p>To solve this problem, instead of annotating streams with
codebase annotations (a poor design), each Endpoint is assigned a
ClassLoader, following authentication, the ClassLoader at each
endpoint is responsible for class resolution of all deserialized
classes of that stream, stream based annotations are not
required. Also separate streams are created for different
concerns, even when an object is marshalled within a stream it
doesn't belong to, a separate stream is created, authenticated and
established with appropriate ClassLoaders at the Endpoints.
RMIClassLoader was a design mistake, it wasn't needed, ClassLoader
already existed for class resolution, a duplicate class resolution
mechanism was never going to succeed. I also reimplemented a
subset of Java deserialization, using constructors with input
validation, it's immune to gadget attacks, it fails atomically
when input validation fails, no incomplete or partially
constructed objects are created, no need to create serial filters
or whitelists, I looked at de-serialization whitelists circa 2010,
I chose not to implement them, as it would have been brittle and
cumbersome to maintain.<br>
</p>
<p>There were many difficult technical problems that prevented Sun's
success with Jini, today, every single one has been solved. JERI
(Jini Extensible Remote Invocation) today is a far superior
framework than RMI could ever hope to be, and yet, RMI is still
used by Java, JERI could replace it, which would allow the
extensible replacement of Java Serialization, that's hardwired
into RMI. One day I would like to see Java serialization, not as
part of the base platform, but an add in module for compatibility,
that few need to use.<br>
</p>
<p>Not only did we solve technical issues with Jini, we made strides
in performance, Sun had a lot of DNS calls thanks to URL equals
and CodeSource implies methods, so Java was making lots of network
calls, OpenJDK still does, if you're using SecureClassLoader,
URLClassLoader and network URL's, performance is terrible.
Instead we're using RFC3986 and RFC5952 normalization, and we're
using bitshift operations for case conversion in URI, because we
had hotspots with string conversion during URI normalization.
We're going as fast as the hardware, network and JDK allows, we
only touch URL and DNS when we need to download something. This
is why sometimes we expose race conditions in Java's TLS
implementation, we made our software as concurrent and non
blocking as possible. We've also got global IPv6 multicast
discovery, we have end to end connectivity, we've got distributed
network events and distributed garbage collection, everything is
authenticated, validated and operating over secure network
connections, it's all easily configured and extensible. This
isn't your publish subscribe web service model. It turns out
everything they dreamed of was possible, it just required time to
sort it out.</p>
<p>Comparatively, problems with Authorization are small and simple,
easily solved.</p>
<p>Thank you for your time and responses, I hope what I've said will
be considered.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter </pre>
<div class="moz-cite-prefix">On 18/06/2023 6:21 pm, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f2465435-b296-9f06-2ff8-d0a16c3484b3@oracle.com">
<br>
On 18/06/2023 02:28, Peter Firmstone wrote:
<br>
<blockquote type="cite">Curious to know OpenJDK's plans for
removal of AccessController::doPrivileged calls?
<br>
</blockquote>
<br>
As JEP 411 alludes, the likely next step for this one is to
degrade it so that it just runs the action. This should be
transparent to most code, esp. library code that uses it so the
library works when the application is deployed with a security
manager. Not early to say which release a change like this might
be proposed for.
<br>
<br>
-Alan
<br>
</blockquote>
</body>
</html>