> The Java bytecode verifier ensures that no object references are forged,
> so that no area of computer memory can be accessed unless allocated, by
> the Java environment, as an object.
Or unless there are bugs in the Java verifier or runtime code (as there
were to begin with and probably still are).
> Java *applications* *may* be allowed to access pre-written (not
> net-loaded) native methods for executing commands such as "rm -rf
> $HOME", but Java *applets*, which are loaded automatically, can't do
> that.
Actually, because I've written Java applets I do know this. I thought we
were talking about applications, not applets. The original comment was about
cross-platform apps, and said that because of verifiers the "security bugs
that were neccesary to make the most powerful tools work that were initially
closed will be opened and enhanced". Verifiers cannot reliably prevent you
from downloading a Java app that erases your hard disk without bouncing any
application that uses the I/O classes.
> Java is a virtual world.
Netscape is a virtual world that processes HTML files. That didn't stop
people from creating URLs that executed host code inside Netscape and
could have done anything.
> The bytecode verifier ensures that the Java
> bytecodes stay within the virtual world. There are no halting problems
> here.
Of course there is. You throw out any code that might break the security,
even when it doesn't, *because* of the halting problem. Only simple code
will pass the verifier. So you're limiting people's ability to write good,
fast code in order to ensure that it's theoretically secure. If GNU come
out with a super-duper highly-optimized free compiler which doesn't
produce the same bytecode as Sun, then their applications will be bounced.
More to the point, a 'secure' language should not need a verifier. The
mere fact that Java bytecode must be verified before it's run shows that
the bytecode is not secure!!! And you're right... it is *theoretically*
secure. The problem, as I understand it, is that Sun chose not to write
a secure interpreter with runtime verification of parameters because it
would be extremely slow. So no matter how theoretically secure the
bytecode definition is, Sun *chose not to create a secure implementation*,
and rely entirely on the verifier to prevent abuse.
> In point of fact, if Java wasn't secure, *then* I could write a
> Turing machine capable of solving the halting problem.
Huh? Well go ahead, because plenty of security holes in Java have already
been demonstrated.
> There may be
> flaws in the implementation,
And how exactly do you prove there are no flaws in the implementation?
Plenty have been found and exploited already, and more will be.
> but I think that your challenges here are
> based on a lack of knowledge.
Then you presume wrong.
Mark
|-----------------------------------------------------------------------|
|Mark Grant M.A., U.L.C. EMAIL: mark@unicorn.com |
|WWW: http://www.c2.org/~mark MAILBOT: bot@unicorn.com |
|-----------------------------------------------------------------------|