From: Blake Coverett <blake@bcdev.com>
Date: Tue, 17 Dec 1996 07:20:17 -0800 (PST)
To: "cypherpunks@toad.com>
Subject: RE: Securing ActiveX.
Message-ID: <01BBEC03.C251AC10@bcdev.com>
MIME-Version: 1.0
Content-Type: text/plain


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