Fwd: Re: DeserializationPermission Proposal

[Peter Firmstone]

If ObjectInputStream's creation was guarded by a Permission, this would 
prevent serialization for untrusted users.

Regards,

Peter.

-------- Original Message --------
Subject: 	Re: DeserializationPermission Proposal
Date: 	Fri, 12 Feb 2016 16:30:35 +1000
From: 	Peter Firmstone <peter.firmstone at zeus.net.au>
To: 	Core-Libs-Dev <core-libs-dev at openjdk.java.net>



Thanks David,

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.

Cheers,

Peter.

>  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