Java

[mcnabb @ argus . cu-online . com (Paul McNabb)]

> W.r.t Java's virtual machine.  The idea has merit.  Theoretically, one
> could monitor the applet as it is interpreted, basically adding
> another layer of security.  The problem lies in defining unacceptable
> behaviour (or its complement) and correctly implementing the VM.  So
> far all of the Java security problems that I have heard of were
> problems with the implementation, not with the design.  Does anyone
> see a fundamental problem with Java's security model?
> 
> Mark Riggins
> Secure Systems Engineering
> AT&T Bell Labs

I have been talking to Sun Java people for awhile, and this is what I
understand the security to be:

1) a very tight language with little chance of problems due to out-of-range
errors, memory overwrites, etc.

2) an engine that tries to look at everything the applet is doing and
prevent anything that looks suspicious (note: this includes prohibiting
the applet from creating subprocesses, running other programs, directly
access most operating system functions, etc.)

3) "registering" applets with a digital signature so that you can know
"for sure" where the applet came from (and presumably you run only those
from people you trust).

Item #2 is the real problem.  It sure helps make the applet secure --
but it really limits the usefulness of the applet.  The problem is that
the applet's environment isn't secure enough if it runs something outside
the Java engine's strictly controlled environment.  That's where 3rd
party products like our Decaf come in.  Without those kinds of security,
Java will take a long time to really be a big force in the market.

paul


------------------------------------------------------------
Paul McNabb			mcnabb @
 argus .
 cu-online .
 com
Argus Systems Group, Inc.	TEL 217-384-6300
1405A East Florida Avenue	FAX 217-384-6404
Urbana, IL 61801 USA
------------------------------------------------------------