> The debate rages today in many sites as to which of these two approaches
> are better. With the Java applet, we have to rely on the sandbox not to
> leak.
Whereas with ActiveX, we have to rely on hundreds of sandboxes written by
application developers not leaking. Now, these sandboxes are a lot less
complex and less likely to have security holes, but there are very many
more of them.
As soon as someone finds a hole in a signed applet they can install it
and the exploit script in a web page and go to town. Your security will
depend on every applet signed by the sources you choose to trust being
written at least as well as the browser you're running them in.
Given that most of the security holes in UNIX have been in setuid or daemon
applications (which is the equivalent in capability to an ActiveX applet)
this doesn't bode well for ActiveX. And at least in UNIX you have the
choice of disabling a service you don't need... ActiveX can sneak in in
a web page with you all unawares.
> The real point is, you have about as much assurance as you have with shrink
> wrap software, and possibly a little more depending on how granular the
> assurance levels end up being.
But I have to take a deliberate action to install shrinkwrap software, it
won't suddenly activate when I hit a web page.
> What you don't have is some myth of a belief that you can trust the stuff
> implicitly. Rather than trying to pretend you can build a complete and
> totally secure sandbox that still has a network connection to the Internet,
> you instead are forced to continue to look at the viability of the vendor,
> the value it adds, and the need to use it.
But you *can* build a complete and secure sandbox. You just have to restrict
it to known safe actions. This means you can't do certain sexy things, but you
can do useful stuff regardless.
How can I say that? Simple. HTML is such a sandbox. It is a language made
sufficiently weak that it can't be used to leverage access to a computer
system. The problem with Java is not that they tried to create a sandbox,
but that for marketing reasons (ie, what do we need to put in here to make
it popular) they made it too powerful.
The best way to enhance HTML is not by creating extension languages, but by
simply enhancing HTML and HTTP with additional facilities that are carefuly
limited in what they can do. But if you *do* want to implement extension
languages, there are a number of limited languages that are very safe already:
for example, a "pure" postscript without any file I/O operators is pretty
much bulletproof... as is Safe TCL, and any of a number of lisp-like and
forth-like languages designed for this sort of purpose. The trick is, don't
include any primitives that change permanent state (or do I/O, which comes
to the same thing). Don't "protect" these primitives with security mechanisms,
rather don't include them at all.
Now people will say "if I can't do I/O and I can't change state, what good
is it?". Well, what good is HTML? There's just a limit to how far beyond
HTML you can go without getting into areas that are too hairy to evaluate.
Java and Livescript both stepped over that line. It's far better to stay
in the known safe area of stateless applets that don't do anything beyond
fancy GIFs and image-maps.
Follow-Ups:
References:
|
|
