[Cryptography Team] Securing the VM and Image

Ron Teitelbaum Ron at USMedRec.com
Mon Jul 31 21:09:20 UTC 2006


Hans-Martin,

Thank you for your thoughts!

I'm not sure the separation of code to isolate read only classes would be of
much help since most of the problem lives in the memory model not in the
stored code on disk.  I would think that placing a certificate on the image
file would be good enough "IF" we could prevent changes to the object
structure and code in memory.

#become is a real problem since it is a very necessary part of proxy
handling for almost all db interfaces I've worked with (including GLORP).  

I wonder how much of this could be solved by on the fly checksums for
everything.  A few years ago this would have been impossible but with today
performance is it really out of the question?

I agree with the need to remove the development tools.

As for the appeasing the security hacks: It's a nice challenge and I can
tell you that "good enough security" is all anyone can ask for.  If we set
the bar too high we prevent advances in security that will do nothing but
help to make a bad situation better.

Ron Teitelbaum


> From: Hans-Martin Mosner 
> Sent: Monday, July 31, 2006 4:50 PM
> 
> 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