Securing the VM and Image (was: Suggestions for C++ or DLL code)

Ron Teitelbaum Ron at USMedRec.com
Mon Jul 31 22:45:28 UTC 2006


> From: nicolas cellier 
> Sent: Monday, July 31, 2006 6:12 PM
> 
> The main two questions are:
> 
> 1) can you disable compiler ? (that means no doIt)
> 2) 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.

> 
> > 3) Disable interactive debugger.
> > 4) 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.

> 
> > 5) 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





More information about the Squeak-dev mailing list