Explicit Serialization API and Security

[Peter Firmstone]

On 13/01/2015 1:56 AM, Chris Hegarty wrote:
> On 10/01/15 07:00, Peter Firmstone wrote:
>
>> As shown in my earlier example, intra class invariants can be enforced
>> using Serialization constructors, from which static methods are called
>> to check invariants prior to super class constructors being called.
>
> Yes, but it is cumbersome and easy to make mistakes.

I think if the user has unit tests for the invariants, then the 
liklihood of mistakes is very low.

Cumbersome, I don't think we need to worry about that.  I've had to do 
so much work, implementing work arounds, it would be like all my prayers 
answered just to be able to prevent reference stealing attacks and 
enforce invariants with failure atomicity.

Did you know that .NET uses de-serialization constructors?

A third option that hasn't yet been considered would be to investigate 
an api that various already existing frameworks can implement providers 
for, so they no longer need to find creative ways to construct instances 
of java platform classes when unmarshalling.


>
>> Presently, I override ObjectInputStream and use a Permission called
>> DeserializationPermission to limit classes that can be deserialized.
>> Untrusted connections are run from unprivileged context to limit classes
>> that can be instantiated, while those with trusted connections are run
>> with a Subject that allows any class to be deserialized.
>
> Interesting. I think there is overlap here with confinement.

The good thing about using a permission check is it allows 
administrative based changed when a new vulnerability is discovered.

Regards,

Peter.