peter.firmstone at zeus.net.au
Fri Feb 12 06:30:35 UTC 2016
I'd originally considered something like that, but I later realised I'd
need to grant DeserializationPermission to other domains I might not
want allow objects to be deserialized with, simply because their domain
is included in the call stack. It looked like it would widen the scope,
which was contrary to the intended goal of minimising the attack
surface. In the end I decided to limit the context to only the domains
of classes involved in deserialization.
> 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
More information about the core-libs-dev