New candidate JEP: 415: Context-Specific Deserialization Filters

[Roger Riggs]

Hi Peter,

There is a set of properties who values are read at startup and cached
so changes later do not affect behavior.  The serial filter properties 
are cached.

For example, java.home, user.home, user.dir, user.name, 
java.library.path, java.io.tmpdir.

Regards, Roger


On 5/7/21 6:24 PM, Peter Firmstone wrote:
> 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.
>>>
>>