Implementing an Authorization framework on Java.

[Peter Firmstone]

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/20230207/5982e87a/attachment.htm>