DeserializationPermission Proposal

[David M. Lloyd]

On 02/11/2016 03:52 AM, Peter Firmstone wrote:
> An example might be more useful.
>
> Traditionally, when the first non serializable superclass zero argument
> constructor is called, the domains of the subclasses aren't present on
> the call stack.  Any security checks performed in the constructor of the
> superclass will not include the subclasses domains.
>
> In the proposed case, prior to construction, all domains in the class
> heirarchy of the to be deserialized object via the local
> ObjectStreamClass, are added to an AccessControlContext, which is then
> passed to the SecurityManager two argument permission check.

Sure, that makes sense; in fact this could be a very good 
standalone/incremental enhancement.

> Now an attacker will not be able to construct this object unless all
> domains have DeserializationPermission.
>
> If we use the stack context, it won't contain the yet to be deserialized
> classes.

True; perhaps the ideal solution would use the initial context plus a 
per-deserializing-class context, so that both the original caller and 
the class being deserialized have permissions.  This would have the 
advantage of consistent behavior, and would also allow the PD of each 
class to restrict whether it can be deserialized (which would apply 
globally no matter who was doing the deserialization in the VM).

-- 
- DML