On 13/01/2015 1:56 AM, Chris Hegarty wrote:
On 10/01/15 07:00, Peter Firmstone wrote:
As shown in my earlier example, intra class invariants can be enforced
using Serialization constructors, from which static methods are called
to check invariants prior to super class constructors being called.
Yes, but it is cumbersome and easy to make mistakes.
I think if the user has unit tests for the invariants, then the
liklihood of mistakes is very low.
Cumbersome, I don't think we need to worry about that. I've had to do
so much work, implementing work arounds, it would be like all my prayers
answered just to be able to prevent reference stealing attacks and
enforce invariants with failure atomicity.
Did you know that .NET uses de-serialization constructors?
A third option that hasn't yet been considered would be to investigate
an api that various already existing frameworks can implement providers
for, so they no longer need to find creative ways to construct instances
of java platform classes when unmarshalling.
Presently, I override ObjectInputStream and use a Permission called
DeserializationPermission to limit classes that can be deserialized.
Untrusted connections are run from unprivileged context to limit classes
that can be instantiated, while those with trusted connections are run
with a Subject that allows any class to be deserialized.
Interesting. I think there is overlap here with confinement.
The good thing about using a permission check is it allows
administrative based changed when a new vulnerability is discovered.
Regards,
Peter.
