On 02/08/2016 10:19 PM, Peter Firmstone wrote:
Why not, just prior to instantiating an object just prior to deserializing, add
each class' ProtectionDomain in the objects hierarchy to an
AccessControlContext and pass this to the SecurityManager's two argument
checkPermission call?
This permission could never be granted to a principal, it is only ever a code
trust concern. This would allow an administrator to minimise the attack
surface of Serializable classes.
I think rather than using the ProtectionDomain of the objects in the
serialization stream, would it not make more sense to capture and use
(exclusively) the access control context of the entity which is
constructing the stream? The reason I say this is that it's very
possible for a less-privileged object to have references to
more-privileged objects and vice-versa; also, in some cases you're
predicating the success of deserialization upon the order in which
objects are deserialized.
For example, if I have a four-object graph of A, B, C, and D, in a
diamond like this:
A->B
A->C
B->D
C->D
If B's class does not have privileges to construct D, deserialization
will fail, even if C does. On the other hand, if B has permission to
construct D, but C doesn't, C can escape its restriction by relying on B
to have already deserialized the object.
But by using one permission set - the captured context of the creator of
the stream, or perhaps the captured context of the "root" readObject()
call, you cannot change the authorization outcome of the deserialization
just by fiddling with the bits. A graph in this case is either valid or
not.
--
- DML
