Summary

Remove "OVERRIDE" special handling of jdk.serialFilterFactory in JEP 415: Context-specific Deserialization Filters.

Problem

The restriction on replacing a filter factory using the <code class="prettyprint" data-shared-secret="1741934077695-0.14695631365125572">Config.setSerialFilterFactory</code> makes it harder to use and only marginally safer.

 * <p> If only `jdk.serialFilter` is set and not `jdk.serialFilterFactory` the builtin
 * filter factory, compatible with previous versions, is set and can not be replaced,
 * use "OVERRIDE" to override the builtin filter factory.

The problematic part of this is the coupling between the jdk.serialFilter property and using the <code class="prettyprint" data-shared-secret="1741934077695-0.14695631365125572">Config.setSerialFilterFactory</code> method. In that case, the method cannot be used without including jdk.serialFilterFactory=OVERRIDE on the command line. The coupling is an attempt to prevent the application from disabling the command line supplied jdk.serialFilter by supplying a faulty or insecure filter factory, perhaps surreptitiously. The window of opportunity to install such a filter factory is very small because the filter factory can only be set before the first <code class="prettyprint" data-shared-secret="1741934077695-0.14695631365125572">ObjectInputStream</code> is created; after that it can not be changed so no amount of clever gadgetry could change it as the result of some deserialization. A filter factory defined on the command line with jdk.serialFilterFactory is not replaceable using the Config.setSerialFilterFactory method. Reviews of the application use of deserialization and filter factory should be able to assert correct use and behavior.

Past/Current Use of the JVM-wide Filter

The out-of-the-box behavior is compatible with the implementation of JEP 290 in JDK 9-16. However, that behavior is not robust to effectively protect complex applications. It utilizes an overly simplified model of a single reject and allow list and the filter can be overridden on a stream-by-stream basis, with no assurance that the JVM-wide filter defined by jdk.serialFilter is not ignored.

Expected Use of Filter Factory

It is expected that filter factories will be developed and deployed that assemble and incorporate reject and allow-lists for individual modules or jar files based on context-specific information to supply a filter for each deserialization stream. The allow and reject lists can be maintained in a database or web service and updated dynamically.

The jdk.serialFilter property on the command line will be used primarily as a stop-gap reject list for temporary or emergency use.

In this and similar use cases, the filter factory for the application would be built-in to the application initialization using the Config.setSerialFilterFactory and that factory would incorporate the filter supplied by jdk.serialFilter.

JEP 415 should promote use of richer protection mechanisms and not make them more difficult to use.

Specification

Remove descriptions of "OVERRIDE" in ObjectInputFilter, ObjectInputFilter.Config.

Specdiff attached in filterfactory-diffs-16_Jun_21.zip