State of Serialization
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.
More information about the core-libs-dev