<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello OpenJDK folk,</p>
<p>Just thought I'd mention our use of Virtual Threads and replacing
the usage of ThreadLocal with ScopedValue.</p>
<p>I've been hacking a fork of OpenJDK on github, <a
href="https://github.com/pfirmstone/jdk-with-authorization">pfirmstone/jdk-with-authorization:
JDK main-line development</a></p>
<p>It uses a heavily modified Authorization implementation to lock
down the vm and replace vintage SM implementation code that has
either been removed or is scheduled for future removal, it also
supports permission checks on virtual threads. The
implementation focuses on scalability with immutability with non
blocking weak caches. AccessControlContext uses a factory cache
to minimise the number of immutable AccessControlContext
instances, for example, many virtual threads will share context.
The cache implementation is injected to avoid dependencies during
jvm bootstrap.</p>
<p>Virtual threads are used in the SM implementation to execute
permission checks in parallel, and avoid blocking native threads,
such as SocketPermission etc.</p>
<p><a
href="https://github.com/pfirmstone/jdk-with-authorization/blob/trunk/src/java.base/share/classes/au/zeus/jdk/authorization/sm/CombinerSecurityManager.java">jdk-with-authorization/src/java.base/share/classes/au/zeus/jdk/authorization/sm/CombinerSecurityManager.java
at trunk · pfirmstone/jdk-with-authorization</a></p>
<p>Basically ScopedValue is used to detect and limit recursion,
which can occur when a permission check requires other permission
checks to complete. The implementation is relatively basic, but
it works well, eg, for more info see the link above.</p>
<p>@Override<br>
public void checkPermission(Permission perm) throws
SecurityException {<br>
Integer call = TRUSTED_RECURSIVE_CALL.isBound() ?
TRUSTED_RECURSIVE_CALL.get() : null;<br>
if (call != null && call > 7) {<br>
/* This is a recursive permission check, there's a
permission on<br>
* the stack that requires privilege to determine
whether it is implied.<br>
* We can't continue indefinitely, as it will cause a
stack overflow,<br>
* however we can allow a limited number of nested
permission checks,<br>
* the same permission check may be repeated numerous
times, in recursion.<br>
*/<br>
throw new AccessControlException("Too many recursive
permission checks", perm);<br>
}<br>
Object context = getSecurityContext();<br>
checkPermission(perm, context);<br>
}</p>
<p>For the curious, the trusted platform has been reduced to only
the java.base module, furthermore modifications have been made to
limit trust of certain classes within the trusted platform domain,
to allow JAAS Subject policy based authorization to take priority.</p>
<p>There's a tool to generate policy files at deployment, only the
permissions needed to perform required functionality and execution
paths are generated. Additional execution paths that are not
exercised that require privileges will not have permission to
execute.</p>
<p>Static permissions, such as URLPermission granted by
URLClassLoader have been removed, to prevent URL injection attacks
and allow policy to determine allowed URL's.</p>
<p>There are additional permission's such as LoadClassPermission,
NativeAccessPermission, SerialObjectPermission and additional
ManagementPermission checks in native code.</p>
<p>No effort will be made to sandbox untrusted code, instead the
focus is on preventing the VM from executing untrusted code by
requiring authentication and authorization.</p>
<p>StackWalker with ScopedValue was tested to replace the native
stack walk, however this lead to difficulties in early loading of
java class dependencies and memory stability issues. The native
stack walk itself is a relatively small section of code and has
been retained, as have permission check hooks.</p>
<p>AccessControlContext's implementation has been simplified and
made immutable for virtual thread support.</p>
<p>Permission implementations are no longer Serializable, some minor
breaking changes have been made that OpenJDK dev's wouldn't have
been permitted to make. Needless to say the implementation is
modern and easier to maintain.</p>
<p>My reason for hacking OpenJDK:</p>
<p><a href="https://github.com/pfirmstone/JGDMS">pfirmstone/JGDMS:
Infrastructure for providing secured micro services, that are
dynamically discoverable and searchable over ipv6 networks</a></p>
<pre class="moz-signature" cols="72">--
Regards,
Peter</pre>
</body>
</html>