<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Noticing the updates made to JEP 411 Alternatives, I think I
might have a minimalist alternative, you may find interesting:</p>
<p>Remove:</p>
<ol>
<li>SecurityManager</li>
<li>Policy provider and implementation<br>
</li>
<li>Permission checks in JDK code addressed by improvements to
encapsulation, eg RuntimePermission "access class in package"
and ReflectPermission, these are no longer necessary, however I
would recommend retaining checks at System::getProperty and
setProperty, as these may contain security sensitive information
(eg keystore and truststore).<br>
</li>
<li>doPrivileged calls within the JVM other than those which
preserve context across threads, most permissions that "leak"
are addressed at #3 above, and POLP tooling can capture other
permissions. It would appear that doPrivileged is more
appropriate for application code, rather than JDK code. <br>
</li>
<li>I'm not sure about removing doPrivileged calls intended to
preserve context within OpenJDK.<br>
</li>
</ol>
<p>Changes (improvements):</p>
<ol>
<li>Make Guard::check a default method, that delegates to a
provider, with a single method (eg Authority::confirm(Guard))
that does nothing by default. Remove all implementing instances
of Permission::check. (this could be backported easily).
SecurityManager methods are just permission checks, existing use
cases of SecurityManager can be supported with this one
method. This could be back ported to Java 8, so libraries that
currently support all supported Java versions can continue to do
so. All calls to SecurityManager methods in JDK code can be
replaced by the corresponding permission check. <br>
</li>
<li>Add permission checks to data parsers (eg deserialization),
this allows implementations to grant these permissions only to
users, if there is not an authenticated user, then the data
received by the parser cannot be trusted.</li>
<li>"Modules that are mapped to the boot loader get a unique
ProtectionDomain that includes a useful code source rather than
using a "shared" PD." This allows permission to be granted to
users, (not code) so certain privileged operations, such as data
parsing cannot be performed without an authenticated user, eg
deserialization. When data can only be trusted from
authenticated users. <br>
</li>
</ol>
<p>Removal of AccessController and AccessControlContext have greater
impact. AccessController's stack walk is high scaling (I haven't
observed any contention, I assume it's non blocking and thread
confined?), it's certainly very performant, it could be replaced
internally by StackWalker to reduce OpenJDK's maintenance burden,
although it isn't clear what the performance impact might be, but
it will no doubt performance improvement is possible.</p>
<p>With SecurityManager gone, no implementation and no policy
provider, it simply provides the mechanics for an authorization
layer without all the baggage, allowing both simple and complex
implementations. It's not for sandboxing untrusted code.
Improvements will allow it to be utilised by developers, to
prevent consumption of untrusted code or data and to limit the
privileges of trusted code and users to principles of least
privilege.</p>
<p>It should also simplifies many tests, as JDK code only need
confirm Permission checks are made and functionality of the
AccessController and AccessControlContext methods if these are
retained (I would prefer to see that, at least for JAAS
compatibility).<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.</pre>
</body>
</html>