New candidate JEP: 415: Context-Specific Deserialization Filters
roger.riggs at oracle.com
Mon May 10 17:36:08 UTC 2021
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
For example, java.home, user.home, user.dir, user.name,
On 5/7/21 6:24 PM, Peter Firmstone wrote:
> 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.
> 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
More information about the jdk-dev