It is a layered approach, first you wold have to find an exploit in the "VM" (which is a sandbox really) thn exploit the underlying OS. The VM has a much smaller attack surface as you have less you can do, so it is easier to audit. NaCl, which is used here has had minor flaws http://arstechnica.com/open-source/news/2009/07/google-nacl-... but nothing like straight kernel. Sure there are other approaches eg see http://sandboxing.org/ eg to use selinux to constrain processes, but none are easy. There is some more recent work on more directly limiting syscalls to processes which is another approach, so the OS provides an isolation service.
1. Filtering all resources accesses, letting some pass and others denied.
2. Enforcing different abstraction and then unwanted resources accesses become impossible as they are not even addressable.
Filtering is by definition less secure. As filtering get more complicated there would be false negatives and false positives. Both are harmful.
Enforcing different abstraction is usually less efficient as there is a need to simulate hardware devices. However, some devices have hardware support for virtualization as with Intel CPUs and MR-IOV devices and then enforcing abstraction is free.
True, even the JVM verifier was flawed, maybe neither approach can succeed. It just seems to me we now have good reason to believe it's a dead end to try to sandbox native code in legacy instruction sets.
Every system might have weaknesses. What matters is:
1. Small surface for attack. With NaCl it is all concentrated in single tiny validator module. The model is also simple and mathematically proven to be secure.
2. Prior testing. It is especially hard for security product. Establishing motivating prizes is good way to ensure it is not easily breakable.
3. The speed with which patch is made available
4. Defense-in-depth, ability to have multiple levels of defense cheaply.
