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
