java security concerns

[Ray Cromwell]

> 
> 
> Mike McNally writes:
> >  > I can
> >  > physically remove all the "dangerous" calls from a Postscript
> >  > interpreter and still have it be useful.
> > 
> > I don't see the difference.  An interpreter is an interpreter.
> 
> I suppose most of this is dead obvious to me because I work in
> security every day, but it seems that some otherwise smart people don't
> see the point I'm making, repeatedly.
> 
> As an exercise to the reader compare the following two tasks in
> difficulty.
> 
> 1) Find a bug that lets you execute arbitrary programs unintentionally
>    from a program that contains instances of the 'fork()' system call.
> 
> 2) Find a bug that lets you execute arbitrary programs unintentionally
>    from a  program that contains *no* instances of the 'fork()' system call.

   I agree, however I would point out that not all postscript interpreters
are emasculated (especially those on unix systems like IRIX, they contain
all kinds of calls to fork(), read()/open(), etc). Nothing in the
Java spec tells you that you must call fork() in a Java interpreter
implementation. In fact, Java has nothing to do with the GUI calls, the
network calls, etc. You can support as much or as little system
I/O in a Java implementation as you want. If need be, a Java
implementation could hard code all data needed from a hard disk into 
executable and run entirely in ram, and totally remove all file
system access. (except the implicit one needed to load and run
the executable in the first place) Even Java apps without network
or filesystem capability are useful (as graphic widgets), but I think
atleast the ability to load URLs is a good thing, and can be done
in a reasonable secure manner.

  Atleast from my reading of the Java Language Spec, and Virtual Machine,
there is no requirement that an implementation implement the File I/O
classes. Having a standardized class hierarchy is probably a good idea
though.

-Ray