Explicit Serialization API and Security

[Peter Firmstone]

Not quite, the constructor signature is the same for super and child classes.

ReadSerial is a container for each serialized Object in an ObjectInputStream that provides and controlls access to serial fields, identified by name, type and calling class, such that each class has it's own parameters contained within ReadSerial.

Serial parameters, might be better terminology than serial fields.  Serial parameters, retrieved from ReadSerial are compatible with serial fields in the serialization specification, providing a compatible upgrade path, and enabling all classes belonging to an Object to obtain parameters during construction, whilst allowing implementations to be independant of an object's serial form.

When ReadSerial doesn't contain a parameter, it will return null.

// pseudocode
public abstract class ReadSerial {

    protected ReadSerial(){
        // check permission
    }

    // perform caller class dependant permission and type check
    public <T> T getParameter( Class<T> type, String name );

}


Peter.

Sent from my Nokia N900.

----- Original message -----
> 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.