From: Ray Cromwell <rjc@clark.net>
Date: Thu, 3 Aug 95 22:17:39 PDT
To: rsalz@osf.org (Rich Salz)
Subject: Re: Java, Netscape, OpenDoc, and Babel
In-Reply-To: <9508040342.AA23479@sulphur.osf.org>
Message-ID: <199508040517.BAA05467@clark.net>
MIME-Version: 1.0
Content-Type: text/plain


> 
> >Perry -- do you have the same basic objection to Safe-TCL that you do
> >do to Java?  I would think so.
> 
> Safe-TCL comes from a different starting place.  For example, the original
> intent was to actually remove all the dangerous operations such as
> file manipulation.  As Perry's explained, this is different, and better,
> then just having the run-time "guarantee" that all file I/O is in a
> "Safe" place.

  Uh, no. There is no difference between this and Java. File I/O
operations can be added to any Safe-TCL restricted interpreter
via "declareharmless". The trusted and untrusted interpreters
don't run in separate process spaces, nor is it chrooted(). Perry's
criteria is that a failure can not result in the interpreter gaining
priveleges it doesn't have. In Safe-TCL this is possible because there
is no protection between the trusted and untrusted interpreters. It's
possible that a bug could cause the interpreter to use an operating
system privelege the model clearly wasn't supposed to have.
(e.g., what if, by chance, the restricted and unresstricted interpreter
pointers get swapped or given to a function in reverse argument order
within an application? Kaboom, the safe-tcl script executes with full
priveleges)

  This is much less secure than Java. First of all, there is no
"declareharmless" in Java. The only way to access any low-level
I/O in Java is via a class interface, and the "final" keyword on
the Java i/o classes prevent any subclasses from overriding these
methods. You can not tell the Java runtime to add a new privelege
to the interpreter like in Safe-TCL. The only way to extend Java is to
create "native" C-code methods and link them in.

  Java relies on its class loader and byte-code verifier to make sure
unauthorized code is attempting execution (such as overriding a system
method)

  It's not as secure as chroot() the Java runtime and running it in a 
separate process with only a pipe to communicate with the outside
O/S, but I feel it is a lot safer than Safe-Tcl. (not to denigrate
Safe-TCL, I am using it in a large project, but this is MHO)


  Finally, all you have to do to remove all I/O ability from Java is delete
the File I/O classes from the class hierarchy on your disk where HotJava
runs. Most apps don't use any File I/O anyway. (Java forces file i/o to
only be allowed in ~/.hotjava or wherever an environment variable
points) Java has no built in I/O primitives in the language itself.

-Ray