<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I've added the following method to the Authorization class:</p>
<p>/**<br>
* This method allows a developer to register the domain of a<br>
* dependency which doesn't utilize this Authorization layer,
to be<br>
* considered as a trusted platform layer, in doing so
however,<br>
* the dependency should be audited for vulnerabilities and
instrumented<br>
* with guards if necessary.<br>
* <br>
* The intent of this method, is to allow guards to check the
domains<br>
* on a thread call stack which hasn't originated from a
privileged call,<br>
* the privileges of the domain are still checked, however it
is preferable<br>
* for privileged calls to wrap and encapsulate dependency
code if possible. <br>
* In the event that dependency code creates its own worker
threads internally<br>
* which require privileges, this method allows those
privileges to be checked, <br>
* rather than immediately rejected.<br>
* <br>
* However dependency code is unlikely to discriminate between
calling code<br>
* and as such may allow other code to call it also, which may
open<br>
* authorization security vulnerabilities. In this case, the
developer<br>
* may request the dependency code developers to add support,
or may instrument the<br>
* dependency code with guard checks using the Attach API. <br>
* Alternatively a developer may wish to use module or
ClassLoader visibility, <br>
* to isolate the dependency code.<br>
* <br>
* @param cl a class belonging to the privileged domain.<br>
*/<br>
public static void registerPrivileged(Class cl){<br>
GUARD_PRIVILEGED_CHECK.checkGuard(cl);<br>
Authorization authorization = INHERITED_CONTEXT.get();<br>
try {<br>
INHERITED_CONTEXT.set(PRIVILEGED);<br>
PRIVILEGED_DOMAINS.add(cl.getProtectionDomain());<br>
} finally {<br>
INHERITED_CONTEXT.set(authorization);<br>
}<br>
}<br>
</p>
<div class="moz-cite-prefix">On 16/07/2021 2:20 pm, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:70930b67-e03c-3421-bb7e-f5e70c2667b8@zeus.net.au">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>I'm currently experimenting with a new authorization layer for
java, post JEP 411.</p>
<p>I would like your thoughts around threads.</p>
<p>This is intended to be simpler than Java's existing
authorization layer, support user Subjects and code based
authorization.</p>
<p>Concepts:</p>
<ol>
<li>Application code has no privileges, unless a privileged call
is made (implements Callable), the privileges are only in
force during execution of the Callable and are not
transferable to other threads.</li>
<li>A Thread with a stack that only contains code visible to the
platform ClassLoader is considered privileged.</li>
<li>Privileged means it has defined privileges, it doesn't mean
AllPermission.<br>
</li>
</ol>
<p>Agents will be used to instrument the Java API for guard checks
(would be nice if OpenJDK can annotate these methods or do
something to help us identify these locations).</p>
<p>Clearly, this will break a lot of existing code, many
applications simply won't run, because they don't utilise the
API. It would work fine for new applications.<br>
</p>
<p>In Java's existing authorization layer implementation (designed
prior to the introduction of Executor frameworks), a thread
inherits the stack context of the thread which created it, with
executors, tasks don't inherit the context of the thread which
places the task. The new framework isn't able to capture the
creating threads context, so it makes more sense to treat
anything outside a privileged call, or system thread as
unprivileged, it does however capture the caller when creating a
privileged task, this is a Task that has privileged access, so
it's important that it is not allowed to escape.<br>
</p>
<p>I am thinking about allowing privileged domains, such that if a
library (which doesn't implement privileged calls), may be
thought of as a system domain, should it create threads, then
provided those threads only have privileged domains on the
stack, guard checks may proceed. For unprivileged application
code, all guard checks fail.</p>
<p>Any thoughts or questions?<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.</pre>
</body>
</html>