New candidate JEP: 415: Context-Specific Deserialization Filters

[Peter Firmstone]

Roger,

Can we make properties specified from the command line immutable?

So code can't switch it back on again.  It's not much good if code can 
change a property, there will be no SecurityManager to prevent it from 
doing so in future.

Not trying to sandbox, just want to keep the security holes closed.

Thanks,

Peter.

On 8/05/2021 7:30 am, Roger Riggs wrote:
> Hi Peter,
>
> Point noted, but does not address existing production apps dependent 
> on serialization.
> We've been encouraging developers to use other serialization 
> mechanisms for years.
>
> As of JDK 9, JEP 290 can specify a filter on the command line to 
> reject all classes.
>
>  ...  "-Djdk.serialFilter=!*" ...
>
> Regards, Roger
>
>
> On 5/6/21 8:44 PM, Peter Firmstone wrote:
>> While I'm not against such a thing, it indicates increasing 
>> complexity in the game of de-serialization whack-a-mole.
>>
>> It also suggests people are using Java Serialization to process 
>> un-trusted data.
>>
>> I think that Serialization Filter's are a design mistake, we should 
>> just enable the existing Java Serialization to be turned off 
>> completely.  The time spent writing these things should be spent 
>> implementing new Serialization API's.
>>
>> A property or command line argument that cannot be changed at runtime 
>> to switch off Java Serialization would be appreciated.
>>
>> A new public API for Serialization which includes Object level input 
>> validation and failure atomicity needs to be designed that is 
>> suitable for use with many Serialization protocols.
>>
>> Serialization is a public interface, we should start declaring it as 
>> such.
>>
>