State of Serialization

Tom Hawtin tom.hawtin at oracle.com
Mon Jul 21 15:10:19 UTC 2014


On 20/07/2014 11:57, Peter Firmstone wrote:

> Since private methods are only be called by the ObjectOutputStream /
> ObjectInputStream, during de-serialisation, subclass are not responsible
> for calling these methods, hence subclass ProtectionDomain's are not
> present in the Thread's AccessControlContext and as such are missing
> from security checks, this is why it's currently essential for classes
> to ensure that de-serialisation isn't performed in a privileged context.

It's more complicated than that. Even final serialisable classes may 
have security checks.

> To improve security, it would be preferable to use a deserialization
> constructor, required to be called by subclasses in the class
> hierarchies, placing their ProtectionDomains in the stack context,
> avoiding a number of security issues. Another benefit is the ability to
> use final fields, while checking invariants during construction.

Certainly it would be better have a mechanism that better fitted in with 
non-serialisation mechanisms. Addressing this without unraveling too 
much when pulling on a thread, and without increasing complexity of 
corner cases, is non-trivial.

Tom



More information about the core-libs-dev mailing list