From: Blake Coverett <blake@bcdev.com>
Date: Mon, 16 Dec 1996 13:19:31 -0800 (PST)
To: "cypherpunks@toad.com>
Subject: RE: Securing ActiveX.
Message-ID: <01BBEB6C.A6148AA0@bcdev.com>
MIME-Version: 1.0
Content-Type: text/plain


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.

Running code in a sandbox, a la Java applets, is one approach to allowing 
safe execution of downloaded code.  If one has a perfect implementation of 
the sandbox, which doesn't appear to be the case for Java thus far, this can 
be a useful solution.  There is however a severe limit to the types of 
applications you can run from inside a sandbox unless you subscribe 
completely to the 'Network Computer'-type model.

Digitally signed code, a la ActiveX, is another approach to the same problem.  
If the digital signatures and infrastructure around them are sound, which they 
appear to be for ActiveX, this is also a useful solution.  The built-in gotcha 
with this model is the all or nothing nature, either I trust the software publisher 
to run arbitrary native code on my machine or I don't run it at all.

Specify technical issues follow:

> It can be done under 95 but Microsoft will have to write a Sandbox 
> Virtual Machine (a Virtual x86 session whose API's are filtered to 
> prevent access to certain things like the file system, and disables 
> direct I/O.)  Not that easy under '95, but it already exists for NT.

But of course it's not enough to filter out filesystem calls.  The entire
windowing system would have to be separated as well.  For example
a rogue control might watching all edit controls for ones
that have the ES_PASSWORD style and grabbing the contents.  

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.)

> The problem is how to deal with DLL's.  You don't know all 
> features/functions of all DLL's.  It may be possible to write a DLL that 
> runs outside the sandbox and can act as a proxy to the file system, so 
> it's iffy unless you limit the DLL's and services that ActiveX apps talk 
> to, and make them all live inside the sandbox.

DLL's are by definition mapped into the processes address space, they
would have to be inside the sandbox too.  It's not a call gate type of thing.


regards,
-Blake