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
