1996-12-18 - RE: Securing ActiveX.

Header Data

From: Blake Coverett <blake@bcdev.com>
To: “cypherpunks@toad.com>
Message Hash: f5ed3aef45704a738fb294c40d778371244bad4971a98ebdc2c0f9e2efec989a
Message ID: <01BBEC70.68E48680@bcdev.com>
Reply To: N/A
UTC Datetime: 1996-12-18 04:18:03 UTC
Raw Date: Tue, 17 Dec 1996 20:18:03 -0800 (PST)

Raw message

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


Ray wrote:
> 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.

We're in violent agreement here Ray.  Sandboxes are good, signed code 
is good, having both is very good.  We differ on the relative importance of
the two techniques but I suspect that is because we are coming from
different contexts.  My work is all intranet so the users trust the software
produced for them by definition.  Obviously the factors are different on
the net at large.
 
> 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.

It's not a Java vs ActiveX thing for me at all.  What is important is that
some of the applets I write can't function in a sandbox, they need access
to the disk and other resources for business reasons.  For this type of
thing signed code without a sandbox is the only choice.

What I'd really like is the sort of thing Bill Frantz is describing on 
another branch of this thread.  Signed code and an administrator 
defined policy that specified for a given signature exactly what 
types of resources should be accessible.  Anything from don't
execute and audit a security alarm to complete access to the
whole machine.
 
> The whole point of this was creating a distributed network of DES 
> crackers.

Yes, but in good cypherpunk fashion I've hijacked the original topic 
into a new direction. :-)

> > 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?  

They don't need to.  All they need to do is unzip the java classes into their 
classpath and all of the normal restrictions on an applet are ignored.  
Think it would be very hard to persuade a user to do just that in order
to play a kewl java game?  More importantly it shows that even expert
users don't always know where the holes in the sandbox are.

regards,
-Blake





Thread