[4728] in WWW Security List Archive
RE: Latest Java hole is Netscape/Sun only
daemon@ATHENA.MIT.EDU (schemers@stanford.edu)
Sun Mar 9 04:12:52 1997
Date: Sat, 8 Mar 1997 22:24:27 -0800 (PST)
From: schemers@stanford.edu
To: Thomas Reardon <thomasre@microsoft.com>
Cc: "'Bob Denny'" <rdenny@dc3.com>,
"'WWW Security List'"
<WWW-SECURITY@ns2.rutgers.edu>
In-Reply-To: <c=US%a=_%p=msft%l=RED-76-MSG-970308012950Z-217036@INET-03-IMC.itg.microsoft.com>
Errors-To: owner-www-security@ns2.rutgers.edu
Thomas Reardon writes:
> Then let me make my own opinion known. First, Java still doesn't have
> signing, other than announcement-ware. Sun, Netscape, Microsot and
> others are working to address that.
JDK 1.1 has signing and was released a few weeks ago. Obviously it
won't see widespread use until the browser vendors implement it
though.
> As for your "who+what" assertion: The idea of capabilities-based-trust
> is a complication, not a simplication for end-users. That is, once you
> decide that you will depend on a trust-based system then that becomes
> the anchor for your security model, its not really complemented by the
> sandbox anymore. Sandboxes are great for *untrusted code*.
I have to disagree. I don't care who signs what. Micrsoft could be signing
IE for all I care, and it will still have the security holes. Once you
have code signing and a capabilities-based-trust (which is coming, there
should be a talk at Java One on it), then you have multiple lines of
defense. Even if you "trust" the code signer, you might still want
to restrict what it can do. Also, if you do trust the signer, you can
also trust the signer to state the capabilties they intend to use.
For example, if I'm running App XYZ, then App XYZ should only be able
read files created by App XYZ by default, and even then, only in a
certain directory. These capabilties can be included along with the
signed bytecode, and instantiated when the applet starts.
> And ActiveX
> is absolutely only good for *trusted* code (where trusted code is
> written&deployed within the firewall, or across the firewall via
> identifiable publishers).
Unfortunately there is no such thing as "trusted" code. Programmers
will always make mistakes, and when writing in a language like C/C++
there are plenty of ways to exploit those mistakes. Microsoft itself
has shipped CDs with Macro viruses on them. How are you going to identify
some ActiveX compoment that sets a timebomb that at some point in
the future deletes your hole harddrive? Or changes something in the
registry that loosens system security in other ways? Or makes your
modem dial some 1-900 number?
I also think that a capabilities-based-trust model extends well beyond
downloading code over the network. It could/should be applied to
all applications you run. Why should a program like "dir" be given any
capabilites other then "read"? There is a longstanding design goal
in security systems that operating with the least amount of privileges
required to do something is always a *good* thing. There is currently
no way to do that in an ActiveX world.
roland
