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.
The authorization layer doesn't define the granularity of Guard checks,
that is up to the implementations.
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.
Latest update, more documentation:
https://github.com/pfirmstone/HighPerformanceSecurity/blob/main/HPS/src/main/java/au/net/zeus/auth/Authorization.java
Note this authorization layer also provides a way to preserve a user
Subject across threads for authentication of TLS and Kerberos connections.
Peter.
On 17/07/2021 5:40 pm, Peter Firmstone wrote:
I've added the following method to the Authorization class:
/**
* This method allows a developer to register the domain of a
* dependency which doesn't utilize this Authorization layer, to be
* considered as a trusted platform layer, in doing so however,
* the dependency should be audited for vulnerabilities and
instrumented
* with guards if necessary.
*
* The intent of this method, is to allow guards to check the domains
* on a thread call stack which hasn't originated from a
privileged call,
* the privileges of the domain are still checked, however it is
preferable
* for privileged calls to wrap and encapsulate dependency code if
possible.
* In the event that dependency code creates its own worker
threads internally
* which require privileges, this method allows those privileges
to be checked,
* rather than immediately rejected.
*
* However dependency code is unlikely to discriminate between
calling code
* and as such may allow other code to call it also, which may open
* authorization security vulnerabilities. In this case, the
developer
* may request the dependency code developers to add support, or
may instrument the
* dependency code with guard checks using the Attach API.
* Alternatively a developer may wish to use module or ClassLoader
visibility,
* to isolate the dependency code.
*
* @param cl a class belonging to the privileged domain.
*/
public static void registerPrivileged(Class cl){
GUARD_PRIVILEGED_CHECK.checkGuard(cl);
Authorization authorization = INHERITED_CONTEXT.get();
try {
INHERITED_CONTEXT.set(PRIVILEGED);
PRIVILEGED_DOMAINS.add(cl.getProtectionDomain());
} finally {
INHERITED_CONTEXT.set(authorization);
}
}
On 16/07/2021 2:20 pm, Peter Firmstone wrote:
I'm currently experimenting with a new authorization layer for java,
post JEP 411.
I would like your thoughts around threads.
This is intended to be simpler than Java's existing authorization
layer, support user Subjects and code based authorization.
Concepts:
1. 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.
2. A Thread with a stack that only contains code visible to the
platform ClassLoader is considered privileged.
3. Privileged means it has defined privileges, it doesn't mean
AllPermission.
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).
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.
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.
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.
Any thoughts or questions?
