In response to my questioning why one would want to run an ActiveX control in a sandbox Ray writes:
To prevent ActiveX controls from formatting your hard drive while still being able to run native code to do fast DES cracking, why else? Sandbox!=Virtual CPU emulator. Sandboxes work at the supervisor/user CPU level deciding which calls are cool and which will result in a core dump.
I would be happier running an ActiveX control with Peter Trei's signature on it than I would an unsigned control in a sandbox. (This kind of a trust decision is probably the normal case in the intranet world. ActiveX as it sits is quite sufficient for rolling out internal intranet applications.) On the second point, I never suggested that a sandbox would require virtual CPU emulation. What I do find likely is that the overhead from the extended types of checking the kernel would need to do would probably outweight the performance advantage of native code over a JIT compiler. The DES cracker is probably not a good example of the problem because it would make virtually no API calls.
Viruses can sneak into software. Given enough time you will see them sneak into compilers which will then happily create virus infected or trojan loaded controls which will be happily signed. I'll leave the test of that scenario up to your imagination. There were cases of viruses making their way to production distributed disks back a few years ago because people weren't watching carefully enough.
This is scaremongering. No, I don't virus scan every new CD I get from Microsoft/Netscape/etc, do you? More importantly to the discussion at hand, what is to prevent said virus from infecting the compiler used to build the sandbox? Part of the decision to trust a software vendor must include trusting that they use appropriate clean build procedures.
Or you may find that shareware control authors won't bother to sign their controls, etc... Same situation. At some point trust or no trust, once your hard drive is wiped, so is the record of the signature that says "The last control you downloaded came from XYZ.com and was written by Vulis."
If you choose to run an unsigned control all bets are off. On a related note, I recently saw a Java implementation of a board game that recommended the user download the zipped up .classes and run it locally. How many average users realize this would disable the Java sandbox entirely?
An equivalent Unix problem would be to allow an open-access guest account with the ability to transfer in and execute arbitrary binaries. While doing this securely may be possible in theory I don't think the state of the art is up to it today. (I sure wouldn't allow it on my system.)
Right, so if that's the case, why would you allow ActiveX controls to run on your system? It's the same problem whether signed or not as signatures only tell you the author's identity and not much else.
You mis-read the paragraph above. Trying to build the sandbox for native code as you've described is akin to the problem above. Is it not? regards, -Blake