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?
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
