<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
</body>
</html>