Authorization layer - threads and privileged calls

[Peter Firmstone]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210716/c3447909/attachment.htm>