Safe copying
Hello all.
I'm trying to create an application to produce arithmetic functions that use a generic Guess interface, but I'm not sure how to ensure that I have a "clean" Guess object for my calculations. A simple object reference could originate from a source I don't trust and therefore be attacked during the calculation. I'm therefore trying to work out if it's possible to make a defensive copy of an Interface class whose implementation I don't know.
I've settled on the idea of an abstract class that implements the Cloneable interface as well as Guess, with a 'protected final' clone() method that simply calls super.clone() (ie, Object's).
Is this sufficient, or will it simply return a binary copy of my abstract class whatever subclass it's called from because it's declared final? There seems to be very little info on the mechanics of the Cloneable interface and exactly how this works.
Alternatively, has anyone else run into this problem and, if so, how did you solve it?
Thanks in advance, and apologies to anyone who saw this before. I think I posted it under the wrong topic.
Winston
# 1
> or will it simply return a binary
> copy of my abstract class whatever subclass it's
> called from because it's declared final?
It will return a cloned copy of the source object whatever it is, i.e. an object of the same class with the same properties as defined by the various clone() methods that are invoked.
> There seems to be very little info on the mechanics of the
> Cloneable interface and exactly how this works.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#clone()
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Cloneable.html
> Alternatively, has anyone else run into this problem
> and, if so, how did you solve it?
You can't solve it if you're going to allow the Guess object to be supplied by someone else. Why do you need Guesses supplied from outside? You could also look into making Guess an abstract class and hardware the behaviour you need to rely on as final protected methods which the implementation must call.
You could also look into the SecurityManager, and into providing your own GuessFactory so you provide the implementation objects.
ejpa at 2007-7-9 20:35:34 >
# 2
> You can't solve it if you're going to allow the Guess
> object to be supplied by someone else. Why do you
> need Guesses supplied from outside?
Because I want the Function to be able to work with any type of Guess, including ones defined by other people. The only thing I want to guard against is someone creating a Guess class that they can use to attack my function while it's in the process of calculation, so I want to be able to create a defensive copy of whatever Guess is passed to my function without having to rely on a clone() method that I have no control over,
because it could easily pass back a reference to the same object (or another known one) that could also be used to attack my function,
Basically, what I want is a way of creating a shallow binary copy of an Object without knowing its type. Is this possible?
Thanks very much for your help.
Winston
# 3
No it is not possible, and anyway what makes you think a shallow binary copy of the object would be safer than the original?
ejpa at 2007-7-9 20:35:34 >
# 4
> No it is not possible, and anyway what makes you
> think a shallow binary copy of the object would be
> safer than the original?
For the same reason that any defensive copy is safer, because the original cannot retain a reference to it. OK, it might be possible to attack some of the references to the internals but, since most of these are likely to be Big numbers it would be difficult because they're immutable. Secondly, it reduces the amount of time that a function (which could take a substantial amount of time to resolve) is dealing with a potentialy corruptible source.
# 5
> OK, it might be possible to attack some of the
> references to the internals but, since most of these
> are likely to be Big numbers it would be difficult
> because they're immutable.
If someone else is writing the class, you have no idea what its internals are or what damage they may be capable of doing.
ejpa at 2007-7-9 20:35:34 >
# 6
> If someone else is writing the class, you have no
> idea what its internals are or what damage they may
> be capable of doing.
By induction, what you say would make one think that no publicly extensible class (or indeed any class derived from a public Interface) is ever safe, yet they are used all the time. A class written to corrupt its user regardles of whether it's copied or not would have to share any damaging internals with every instance ever created and so could never target an individual client.
But perhaps you're right. I'm now leaning towards providing only package-private Guesses and saving myself the hassle of worrying about unsafe ones; but it does seem to run counter to the OO idea of cooperative development.
Thanks very much for all your help anyway.
Winston
# 7
Well I never really understood the problem in the first place: how a shallow copy addresses your security concerns, or what 'a class written to corrupt its user regardles of whether it's copied or not' might be, or what 'would have to share any damaging internals with every instance ever created' means; but if you've got security concerns about an externally derived class, a security manager and a security policy for that codebase is the answer. That's what RMI requires for example.
ejpa at 2007-7-9 20:35:34 >
# 8
> how a shallow copy addresses your
> security concerns
It actually doesn't. For that I would have to copy the entire object tree generically (it can be done with reflection, but it's awfully tedious).
> what 'a class written to
> corrupt its user regardles of whether it's copied or
> not' might be, or what 'would have to share any
> damaging internals with every instance ever created'
Any class can be made to corrupt a user by simply including references
to mutables which can then be changed by the ******* to affect behaviour. As you correctly point out, this can't be prevented by a shallow copy, only a deep one.
It sometimes happens by accident (eg, Date, which is why Calendar is now recommended), but if the source is trusted (as with Date) you can prevent a client from gaining access to your Date by simply copying it. Joshua Bloch talks about it in great detail in 'Effective Java',
including things like making sure you 'sanitize' BigIntegers and
BigDecimals to make sure they aren't some untrusted subclass.
> but if you've got security concerns about an
> externally derived class, a security manager and a
> security policy for that codebase is the answer.
I'll definitely give it a look. I think for the moment I'm simply going to keep things package-private, get the sucker developed, and then worry about how I can deploy it for others to add to.
Thanks very much for your comments.
Winston
