Nice, we still get to use Java 23 ;) I listened to one of Brian's
talks recently, it sounds like you're solving some long term structural
issues with Java.
Looking forward to a Jep for removal of Java serialization. Note we use
constructor based deserialization, with a single common defined
annotated signature and a subset of the Java serialization wire
protocol, extensible to other protocols. We didn't implement
deserialization of circular object graphs (it's a security risk),
however this wasn't a major issue, we found other ways to do what we
needed without that functionality. While we don't use Java
serialization, we do perform lots of serialization with remote method
call parameter objects, using our service based architecture. I guess
I'm trying to say, if we don't need to deserialize circular object
graphs, then anyone that does, they have a rare corner case. Throwable
is an example of a serialized circular object graph, there aren't many
in the wild.
For serialization of java collections we have immutable containers that
implement collections interfaces, developers are expected to validate
the collection contents before creating a new collection to hold the
values. If input validation fails during construction, then no object
is created and cannot be reached by a finalizer for gadget attacks.
Additionally, we utilise periodical stream resets (clearing the object
cache) that allow control to return to the caller, if not received. We
validate class types in the stream prior to deserializing object state,
we also limit permission, based on the identity of the authenticated
data source / network connection and code signer, or a hash of the jar
file to ensure it hasn't been tampered with. Our framework works in a
way that doesn't break encapsulation, like serialization whitelists
do. Although SecurityManager and Policy et al, are technically white
lists, we have tools to generate policy files, grant permissions
dynamically, and declare required permissions in jar files similar to
how OSGi does and a lot of these things are automated, such as
dynamically granting permissions to download code (preserving
encapsulation) after authentication.
It was nice to have had the opportunity to provide a working
implementation that addressed major issues listed in JEP411, implemented
in a way that scaled, didn't impact performance and simplified what was
a well designed but poorly maintained authorization framework, from an
ever increasingly bloated trusted platform (hint this should always be
minimized). I would like to thank Li Gong if he ever reads this email,
he allowed us to push the boundaries of what is possible with POLP based
authorization for more than twenty years. I'm quite confident there is
no other authorization framework on God's green Earth that enables
limited access to networks, file systems, properties, deserialization,
etc, limiting privileges to a combination of both principal's and code,
so we are able to ensure that not only is the remote user trusted, to a
certain degree with authentication and encrypted connections, but also
only grant them certain privileges when using the code we intended them
to use, no principal can attain privileges when executing with code we
didn't intend them to use. Note we didn't utilise the so called
sandbox, just authorization, we realised early (well before 2010), that
untrusted code couldn't run securely on Java's virtual machine. We
supported it with tooling that makes POLP authorization relatively easy
and simple to develop and deploy.
https://github.com/pfirmstone/JGDMS/wiki
Regards,
Peter.
On 4/10/2024 12:32 am, Sean Mullan wrote:
We are aiming to do this in 24, but nothing is official until the JEP
is targeted to a specific release.
--Sean
On 10/3/24 6:28 AM, Peter Firmstone wrote:
Which release does this target?
I've been waiting to learn the affected Java release, so we can
document which versions of Java our software can and cannot support.
We'll continue to use Java beyond this release, but will need to
maintain our own fork, as it's not possible to build an Authorization
layer on top of Java without low level hooks, this is built into our
software at a foundational level and cannot be removed.
Thank you.
Peter.
On 26/09/2024 9:55 pm, Mark Reinhold wrote:
// Correcting Sean’s e-mail address
https://openjdk.org/jeps/486
Summary: The Security Manager has not been the primary means of
securing client-side Java code for many years, it has rarely been
used
to secure server-side code, and it is costly to maintain. We
therefore
deprecated it for removal in Java 17 via JEP 411 (2021). As the next
step toward removing the Security Manager, we will revise the Java
Platform specification so that developers cannot enable it and other
Platform classes do not refer to it. This change will have no
impact
on the vast majority of applications, libraries, and tools. We will
remove the Security Manager API in a future release.
- Mark
