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