New candidate JEP: 486: Permanently Disable the Security Manager & Java Serialization.

[Peter Firmstone]

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
>