DeserializationPermission Proposal

[David M. Lloyd]

On 02/08/2016 10:19 PM, Peter Firmstone wrote:
> Why not, just prior to instantiating an object just prior to deserializing, add each class' ProtectionDomain in the objects hierarchy to an AccessControlContext and pass this to the SecurityManager's two argument checkPermission call?
>
> This permission could never be granted to a principal, it is only ever a code trust concern.  This would allow an administrator to minimise the attack surface of Serializable classes.

I think rather than using the ProtectionDomain of the objects in the 
serialization stream, would it not make more sense to capture and use 
(exclusively) the access control context of the entity which is 
constructing the stream?  The reason I say this is that it's very 
possible for a less-privileged object to have references to 
more-privileged objects and vice-versa; also, in some cases you're 
predicating the success of deserialization upon the order in which 
objects are deserialized.

For example, if I have a four-object graph of A, B, C, and D, in a 
diamond like this:

A->B
A->C
B->D
C->D

If B's class does not have privileges to construct D, deserialization 
will fail, even if C does.  On the other hand, if B has permission to 
construct D, but C doesn't, C can escape its restriction by relying on B 
to have already deserialized the object.

But by using one permission set - the captured context of the creator of 
the stream, or perhaps the captured context of the "root" readObject() 
call, you cannot change the authorization outcome of the deserialization 
just by fiddling with the bits.  A graph in this case is either valid or 
not.

-- 
- DML