Virtual Machines and Memory Protections
Posted Nov 30, 2006 14:54 UTC (Thu) by
llupus (guest, #20164)
Parent article:
Virtual Machines and Memory Protections
The restrictions that systems like PaX and SElinux can enforce can prevent any JIT from working, it is not specific to the Mono VM. The people that suggested the use of Java obviously missed the point.
We should also consider that suggesting the use of an interpreter misses the point, too, as an interpreter uses data as opcodes and there is no way to prevent the interpreter from executing opcodes (generated, say, by using a flaw in libpng) using page table permissions.
An interpreter could be considered better here only for the fact that an interpreter is usually simpler than a JIT so it can be more easily audited, but just proposing the use of an interpreter doesn't solve the problem at all.
Also, a needed clarification, since some people seem to be unaware of it:
while C# allows the easy use of native shared libraries, only code that is fully trusted can do so. you could decide to run some programs will less privileges if you think they are security sensitive. The set of permissions and restrictions is also quite flexible, like, you could allow a specific program to access only some environment variables etc.
The article already mentioned that using Mono we could execute most programs without the need of the JIT, by using the AOT mode. Of course some restrictions apply for the mentioned need of Reflection.Emit and also for other features, like marshaling a delegate object as a C function pointer.
The point, though, is that, in security issues, we should try to minimize the risks and still be able to get work done. If you are afraid of being kidnapped, you can lock yourself in your house and never go out of it and have someone else feed you. In most cases in the real world this is not the usual way to protect people, even if it can be effective, because you need to have a balance between security and freedom.
The same happens with virtual machines: we need a balance between security, speed, features, etc.
In this view, the Mono VM, like the JVM, is built to be secure, but trying to avoid the jit is like locking yourself in your house: a miserable life.
This doesn't mean, though, that risks can't and shouldn't be mitigated.
Someone, for example, may want to AOT the code, to minimize the use of the JIT. We could also later implement the code to make the jit code area writable only for the shortest amount of time possible and randomize the positioning of the code. This won't prevent all kinds of attacks, but it reduces the risks while maintaining the feature set intact. This would be a good compromise between features and security concerns. If you really want to feel yourself secure, you'd need to run only code that has been prooved correct, or you can lock yourself at home. Of course feeling secure is not the same as being secure anyway...
(
Log in to post comments)
