Explicit Serialization API and Security

[Brian Goetz]

So, if I understand this correctly, the way this would get used is:

class BaseFoo implements Serializable {
     private final int x;

     public BaseFoo(ReadSerial rs) {
         this(rs.getInt("x"));
     }

     public BaseFoo(int x) {
         this.x = x;
     }
}

Right?

What happens with subclasses?  I think then I need an extra RS arg in my 
constructors:

class SubFoo extends BaseFoo {
     private final int y;

     public SubFoo(ReadSerial rs) {
         this(rs.getInt("y"));
     }

     public BaseFoo(ReadSerial rs, int y) {
         super(rs);
         this.y = y;
     }
}

Is this what you envision?





On 12/27/2014 8:03 PM, Peter Firmstone wrote:
> 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.