David M. Lloyd
david.lloyd at redhat.com
Thu Feb 11 12:16:20 UTC 2016
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
> 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
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).
More information about the core-libs-dev