Authorization layer - threads and privileged calls

[Peter Firmstone]

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?
>>

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