On Tue, 17 Dec 1996, Blake Coverett wrote:
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.)
And I'd be happier running the signed ActiveX control, written by Peter Trie, or anyone else within a Sandbox regardless of signature as it increases security.
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.
You did however say this a few days ago: "This thread branch seems to be based on bad assumption. Why would one want to run ActiveX controls in a sandbox? If you need a sandbox, use a Java applet, if you need native code level access to the system use ActiveX." The above says that you wouldn't want to run ActiveX in a sandbox while you would want to run Java in a sandbox. The difference between technologies is that one runs native the other emulative. I wouldn't want to run ANY foreign code outside a sandbox. Java or ActiveX. The whole point of this was creating a distributed network of DES crackers. There is zero API security checking on a control that does nothing but math and integer operations. The loss of performance occurs when the control or applet wants to read or write to the file system or tries to talk over the network, which a DES cracker won't do very much of, hrrrm? In other words, an ActiveX sandbox will not slow down the DES cracker, and it will increase security. What's your problem with it being used on ActiveX when you say it's cool to use on Java applets?
This is scaremongering. No, I don't virus scan every new CD I get from Microsoft/Netscape/etc, do you?
I back up my hard drives to CDR's. While it is true that viruses can get into my system, I'd notice them quickly with the scanners, and if they did manage to wipe my drives, I'd have the data safe on CD where they can't write. I don't store programs on the CD's, just data.
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.
Precisely why you need to sandbox an OS. A good operating system / virus scanner doesn't allow programs to modify other programs, except for a user approved compiler. If you've ever used a Mac compiler and Symantec's SAM, you'll notice that if you enable certain features, you have to allow exceptions for your compilers - you as the user. If a virus infects your compiler it is because you've allowed it permissions to do so previously. (With my Mac, I have the virus checkers warn me, even when I compile. Yes, it is annoying, but it's much safer.)
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?
How many users know how to download the jdk and run the java vm locally? Yeah, all bets are off when you download an unsigned control, but having them downloaded into a sandbox means that even if they are written by VulisSoft, they won't damage anything of importantce.
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?
It is not. The sandbox runs in supervisory (Ring 0 for you intel freaks) mode, the code it allows to execute runs in user mode (ring 3 is an example) so no matter what the control does, it cannot get into anything the sandbox doesn't allow it to since it cannot switch to supervisory mode. (Assuming you've implemented your sandbox securely and it lacks security holes.) At the same time, only I/O calls are hindered by the extra checking, so it's a moot point in the case of the DES cracker. Now what you are saying is that if you don't trust the control, why should you trust the manufacturer of the sandbox? The answer is that they are a highly more visible target for lawsuits than a possibly unknown author who wrote some control which you ran ten months ago that decided to wake up today and wipe your drive. There's a big difference between protect the user wholy and presenting a dialog box where they can press Ok to download a destructive bit of code. In one case the user is culpable for agreeing to download destructive code, the other prevents the problem from happening. Also, the secure sandbox source code can be made visible (if such an entity as one that wrote it deems to do so in the name of trust.) See pgp. need I say more? Would you trust PGP more or less than say Norton Diskreet? Whether or not you are qualified to analyze PGP source code isn't the issue, you at least have the ability to do so once you learn how. =====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian | "If you're gonna die, die with your|./|\. ..\|/..|sunder@sundernet.com|boots on; If you're gonna try, just |/\|/\ <--*-->| ------------------ |stick around; Gonna cry? Just move along|\/|\/ ../|\..| "A toast to Odin, |you're gonna die, you're gonna die!" |.\|/. .+.v.+.|God of screwdrivers"| --Iron Maiden "Die With Your Boots on"|..... ======================== http://www.sundernet.com =========================