Bert,
Thank you for your comments, I wasn't planning on using the sandbox since there are a number of external connections like Glorp-PostgreSQL needed where I plan to ultimately use this new functionality. I was hoping to address this with a signed image and VM. A signed image and VM could keep any changes out of the system.
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 input would be very much appreciated.
Ron Teitelbaum
From: Bert Freudenberg Sent: Monday, July 31, 2006 12:37 PM Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
Hello all,
I'm currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls.
Well ... FFI is inherently unsafe - it allows to call any C function in any library. So depending on the area of application this might be a problem, since you're giving up the relative safety of a VM-based system. For example, if the VM's sandbox is enabled, FFI calls are disallowed, so you could not use crypto in a sandboxed environment.
- Bert -