Message-Id: <v04204f02b35b3ff67119@[128.8.129.122]>
In-Reply-To: <199905090015.RAA00976@shorter.eng.sun.com>
Date: Sun, 9 May 1999 09:57:04 -0400
To: Jeff Nisewanger <jeff.nisewanger@eng.sun.com>
From: William Pugh <pugh@cs.umd.edu>
Subject: Re: Huge security hole in Sun's JVM
I agree it isn't an implementation bug. I would argue that relaxing the
security model most Java programmers expect, without informing them
of this relaxation, is a flawed design decision.
I don't care that much about Java code in web page. But I download and install
Java applications (and they are read off my classpath), but I don't
trust all of
the applications I have installed. I had presumed that the Java
security rules were
being enforced. But I find that you relaxed them without informing
people. (I checked,
and you even allow classes from another package to access private
variables, even
if a security manager is installed -- yes, I realize this is a simple
consequence of
not doing the checks at all, but I found it surprising and disturbing).
How much code is out there that really needs this hack? I find it
hard to believe that
there is a significant amount of code, and none of it would work if
it were downloaded via a URL or Applet Classloader (correct?).
Wouldn't it be better to tell the people who wrote these applications
to recompile their code than to weaken the Java security model?
I really appreciate the fact that Java has a strong security model.
That is why I was
surprised to see such a big "feature".
On a related note, I've done some work that provides an efficient
solution to the security hole introduced by InnerClasses (the
creation of access methods that can be invoked by anyone in the
package). I've got some information on that up on my web page about
Java (http://www.cs.umd.edu/~pugh/java). I was doing some work on
that problem when I came across this problem.
Bill Pugh