Implementing an Authorization framework on Java.

[Peter Firmstone]

I don't think I'm really asking for much here.   JEP411's plan will 
destroy our ability to manage user and service authorization in our 
existing software, at least cut us a little slack.  I wish we built our 
software on some other authorization API, unfortunately we didn't.

We're just trying to migrate as best we can to future versions of Java.

-- 
Regards,
  
Peter Firmstone

On 7/02/2023 12:53 pm, Peter Firmstone wrote:
>
> Hello OpenJDK folk,
>
> SecurityManager, AccessController and AccessControlContext will be 
> removed in a future version of Java.
>
> Just briefly: Our software is heavily dependant on Java's 
> Authorization framework, we use ProtectionDomain's to represent remote 
> services for authorization decisions.  We are working out how to 
> implement a new authorization framework after SecurityManager's removal.
>
> Many libraries call AccessController#doPrivileged methods, when these 
> methods are removed, we're going to have a big problem with viral 
> permissions.   Restricted authorization will become meaningless if it 
> has to be granted to all domains on a call stack.
>
> https://github.com/opensearch-project/OpenSearch/issues/1687
>
> Retaining methods in the platform that developers can instrument will 
> provide a common frame of reference for authorization decisions, 
> that's runtime backward non-breaking, without burdening OpenJDK with 
> maintenance.
>
> I'm requesting retaining the DomainController interface, 
> AccessController, AccessControlContext and Subject methods as no-op's 
> for instrumentation?    Please leave them deprecated as no-op's, but 
> not "deprecated for removal".
>
> https://github.com/pfirmstone/HighPerformanceSecurity
>
> Some thoughts:
>
>  1. Ability to disable finalizers in Java 18 onwards is important to
>     prevent finalizer attacks when instrumenting constructors to throw
>     a RuntimeException.
>  2. Guard#check methods can be no-op's for instrumentation.   If I can
>     replace all instances of SecurityManager#checkPermission in
>     OpenJDK with Guard#check, I can contribute the patches, this will
>     assist greatly in the transition process of retaining existing
>     hooks, while developing replacements.
>  3. Reduce the size of the Java Platform's trusted computing base by
>     giving all system ProtectionDomain's a CodeSource with a non-null
>     meaningful URL.   Unfortunately Java Serialization is in the base
>     module, so we cannot authorize it's use with a permission check,
>     as the base module needs AllPermission, it has to be managed with
>     serial filters
>     (https://dzone.com/articles/a-first-look-into-javas-new-serialization-filterin
>     - perhaps someone will write a serialfilter generation tool that
>     works similarly to our POLP policy generation tool?). Privileges
>     cannot be elevated by an authenticated Subject, when all domains
>     on the call stack are already privileged.  If Serialization was in
>     a different ProtectionDomain, then we could prevent
>     de-serialization for unauthenticated Subject's.   Perhaps OpenJDK
>     might consider moving Serialization into a different module in
>     future before it's eventual removal?
>  4. Instrument all data parsing methods with guard checks, eg XML.  
>     This allows authorization decisions to parse remote data based on
>     the Principal's of the remotely authenticated Subject, to prevent
>     injection attacks.
>  5. We already have principle of least privilege policy generation
>     tools and efficient policy checking tools for authorization in
>     place.   These allow for simple policy file generation, auditing,
>     editing and deployment.
>
> -- 
> Regards,
>   
> Peter Firmstone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230209/5a398c1d/attachment.htm>