[Cryptography Team] Securing the VM and Image

Hans-Martin Mosner hmm at heeg.de
Mon Jul 31 20:50:22 UTC 2006


Ron Teitelbaum wrote:

>...
>
>The thing that concerns me is changes to a live system that happen without
>needing to save the image.  Plenty can happen as the system is running so
>the question is: how can we secure the image while it is running?  
>
>Some things that would be needed off the top of my head are: 
>
>1) Disable file in
>2) Disable the compiler for accepting or performing new code, but allow it
>for already coded performs.  (I'm sure this is much easier said then done).
>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. 
>5) Prevent changes to compiled methods
>
>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.
>
>I've mentioned this before and got absolutely no comment from anyone.
>(Maybe the email was too long to read?)
>  
>
Some unstructured ideas from the top of my head:
Securing a Smalltalk image is pretty difficult. The VM protects the 
system against a number of security holes such as buffer overflows etc. 
which would allow external attackers to compromise security. Protecting 
against internal attacks is much more difficult. If I were a computer 
security expert, I'd probably prefer an architecture where there is 
absolutely no possibility of adding new code to a running application. 
The Smalltalk image is *designed* to be the exact opposite of that :-)
A truly secure VM/image combo would perhaps need to be done differently: 
The image should be split up into a read-only part containing classes 
and methods, and a writable part where the more mundane objects reside. 
Ideally, the read-only part would be protected using the hardware and OS 
mechanisms, so its integrity does not depend on the correctness of the 
VM and all its primitives.
Of course, none of the development tools are supposed to be present in 
such an image, and even the hooks which they use should be carefully 
removed. There are some primitives (such as #become: and class-changing 
primitives) which a secure VM should either not implement or implement 
in a safer way.
Checking the code integrity with checksums etc. is certainly a necessity.
Linking to and depending on external code without checking its integrity 
as well is probably a no-no. Static linking is probably ok.

In any case, soothing the paranoia of security experts is going to be a 
difficult task. Once you know how many possibilities there are for 
tampering with software, you understand why...

Cheers,
Hans-Martin



More information about the Squeak-dev mailing list