<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Note that the new authorization layer avoids "viral permissions"
by requiring a privileged call before privileges will be enabled.
Apart from privileged calls, only if a thread call stack contains
all privileged domains, will it proceed with a Guard check.</p>
<p>The authorization layer doesn't define the granularity of Guard
checks, that is up to the implementations.</p>
<p>This isn't working code yet, presently it's intended to
communicate authorization concepts. Hopefully OpenJDK will assist
by providing some hooks in OpenJDK code for guard checks.<br>
</p>
<p>Latest update, more documentation:<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java">https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java</a></p>
<p>Note this authorization layer also provides a way to preserve a
user Subject across threads for authentication of TLS and Kerberos
connections.</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 17/07/2021 5:40 pm, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:28577056-1e00-dc37-d45b-c0c48a9304fa@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>
</blockquote>
</blockquote>
<br>
</body>
</html>