New candidate JEP: 415: Context-Specific Deserialization Filters

[Peter Firmstone]

Thanks Roger,

That's good to know.

Currently we do allow some serialization, but only over authenticated 
(client and server) encrypted connections, I'll be looking to eliminate 
serialization altogether in preparation for JEP 411.

It would have been easier to have a Permission that determined whether a 
library was permitted to perform de-serialization, but I realize this 
isn't the direction that Java's is going in.

Regards,

Peter.

On 11/05/2021 3:36 am, Roger Riggs wrote:
> 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.
>>>>
>>>
>