From: nicolas cellier Sent: Monday, July 31, 2006 6:12 PM
The main two questions are:
- can you disable compiler ? (that means no doIt)
- can you disable loading of compiled code and class by other means ?
If you cannot remove compiler, then you must restrict its use.
[snip]
A restricted compiler must not have access to Smalltalk environment but only a restricted one. It must also have access to a restricted number of messages, expecially not the system reflexive ones like allOwners allInstances basicAt: subclasses become: etc... It is safer in this case to authorize a few than forbid a lot of messages.
I did this kind of tricks in the days when ParcPlace runtime policy were really conservative. Maybe you will find more informations in commercial Smalltalk versions...
I will look into it; it's a very good suggestion.
- Disable interactive debugger.
- Enable some sort of class level MAC checking which can verify that no
changes were made to code before it is executed.
It is much simpler to close the system by reducing it's interface, than trying to secure the kernel.
Anyway, what do mean before it is executed? Once image loaded does execution ever stop ? You mean at some strategic or random points of execution ?
What I mean is before each user method is executed, or each class is accessed if method execution is too resource intensive to verify the structure and the methods match some signed hash to verify that they have not changed. We could implement some time dependent verification or other caching methods to help improve performance.
- Prevent changes to compiled methods
You can try and lock MethodDictionary so that they do not accept to add remove or change any key/value, but for UndefinedObject doIt... (You just have to redefine few messages...). But you must make sure that there isn't a way to interpret some unbound CompiledMethod...
Without restricted compiler, I can figure some attacks on such a lock, like creating a simple dictionary, copying compiled methods from here and there and changing class to that of MethodDictionary and then replacing MethodDictionary's MethodDictionary via a become:., all this in a single doIt...
If you allow user relexive access to the Compiler, MethodDictionary or whatever you did protect, then your system is not closed enough.
Then you can play the game to protect the protections, but untill you find a way to have a protection loop, that is just adding complexity to the system, and you might well add more weak points if your design is too complex...
How to obtain a cyclic protection? That may be interesting...
Plus more that I'm sure will also be needed. If we can sign the image
and
VM and change the VM to check the signature before staring up and find a way to protect the live image then we will have gone a long way to
having a
more secure development platform.
And of course the plugins and DLL must be signed too.
Agreed.
Maybe i didn't had much value...
Nicolas
On the contrary your comments are very helpful and I hope you will continue to participate as more concrete suggestions are made.
Ron Teitelbaum