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:
- Disable file in
- 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).
- 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. 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