Authorization layer - threads and privileged calls

[Peter Firmstone]

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.

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