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
