[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
|