Explicit Serialization API and Security

[Peter Firmstone]

Thank you all for participating in this discussion.

Initially a constructor signature for deserialization was proposed to 
enforce invariants and encapsulation, however there appears to be 
interest in using alternative methods, although they appear to be 
improvements over the status quo, I'm having trouble working out how to:

    * Enforce intra class invariants with alternate proposals without
      breaking encapsulation.
    * How the static method proposal can be used to replace final fields
      referents without needing to implement readObject().
    * And how the alternative GetFields readObject() implementation can
      enforce invariants and prevent finalizer attack, while also
      allowing subclassing?

What started me down this path, is our project (Apache River) is heavily 
dependant on Serialization, I wanted to create a secure 
ObjectInputStream subclass that restricted deserialized classes to those 
I had audited.  My aim was to allow deserialization to enforce security 
using verification, similar to how an http server verifies its input.

Unfortunately before I can achieve the goal of secure deserialization, 
there's a denial of service issue in ObjectInputStream: I'd also like to 
propose a system property, to allow limiting the size of arrays, created 
during deserialization.   Presently I can craft an inputstream to take 
down the JVM, if I can do it, so can an attacker, I'd like to get that 
fixed if possible.

I've attached a text file that contains three classes using the original 
proposed serial constructor, A, B and C which have intra class 
invariants that must be satiisfied.  C also contains a circular link and 
implements an interface called Circular, the Serialization framework 
calls it after construction to provide access to fields with circular 
links.  Can the other proposals provide similar safety?

Notes:

   1. The class with the circular link is final and every method checks
      if invariants are satisfied.
   2. The method with @SerialConstructor annotation, is the only
      constructor called by the serialization frame work, other than the
      Circular interface method, there are no other methods that need to
      be implemented.
   3. Encapsulation is preserved, classes have full control over their
      invariants, their internal implementation and what's serialized.

Regards,

Peter.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Explicit serialization.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20150108/a4469589/Explicitserialization.txt>