State of Serialization (original) (raw)

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