Explicit Serialization API and Security

[Peter Firmstone]

Is there any interest in developing an explicit API for Serialization?:

   1. Use a public constructor signature with a single argument,
      ReadSerialParameters (read only, writable only by the
      serialization framework) to recreate objects, subclasses (when
      permitted) call this first from their own constructor, they have
      an identical constructor signature.  ReadSerialParameters that are
      null may contain a circular reference and will be available after
      construction, see #3 below.
   2. Use a factory method (defined by an interface) with one parameter,
      WriteSerialParameters (write only, readable only by the
      serialization framework), this method can be overridden by
      subclasses (when permitted)
   3. For circular links, a public method (defined by an interface) that
      accepts one argument, ReadSerialParameters, this method is called
      after the constructor completes, subclasses overriding this should
      call the superclass method.  If this method is not called, an
      implementation, if known to possibly contain circular links,
      should check it has been fully initialized in each object method
      called.
   4. Retains compatibility with current serialization stream format.
   5. Each serial field has a name, calling class and object reference,
      similar to explicitly declaring "private static final
      ObjectStreamField[] serialPersistentFields ".

Benefits:

   1. An object's internal form is not publicised.
   2. Each class in an object's heirarchy can use a static method to
      check invarients and throw an exception, prior to
      java.lang.Object's constructor being called, preventing
      construction and avoiding finalizer attacks.
   3. Final field friendly.
   4. Compatible with existing serial form.
   5. Flexible serial form evolution.
   6. All methods are public and explicitly defined.
   7. All class ProtectionDomain's exist in the current execution
      context, allowing an object to throw a SecurityException before
      construction.
   8. Less susceptible to deserialization attacks.

Problems:

   1. Implementations cannot be package private or private.  Implicit
      serialization publicises internal form, any thoughts?

Recommendations:

   1. Create a security check in the serialization framework for
      implicit serialization, allowing administrators to reduce their
      deserialization attack surface.
   2. For improved security, disallow classes implementing explicit
      serialization from having static state and static initializer
      blocks, only allow static methods, this would require complier and
      verifier changes.
   3. Alternative to #2, allow final static fields, but don't allow
      static initializer blocks or mutable static fields, similar to
      interfaces.

Penny for your thoughts?

Regards,

Peter Firmstone.