Date: Fri, 3 Oct 1997 14:21:32 -0700
Message-Id: <199710032121.OAA05778@games.eng.sun.com>
From: Li Gong <gong@games.eng.sun.com>
To: "L. Peter Deutsch" <ghost@aladdin.com>
Subject: Re: Java security
In-Reply-To: L. Peter Deutsch's mail of Fri, 3 October, 1997
<m0xH7Mr-000R25C@lamp.aladdin.com>
I thought there were security issues specific to image or 2D. Now you
have raised some general issues, let me chip in my two cents worth.
L. Peter Deutsch writes:
> There are several general classes of security problems with
> Java that have been widely reported in the public press:
I agree in general with your concerns, but I would argue that if you
evaluate Java security in a wider context, you will see that Java
contributes to security and there is no clear alternative.
> 1) Java has no security kernel. Security in Java depends on an
> enormous amount of widely dispersed code being bug-free.
No security kernel, true. But Win95 has no security kernel either,
and neither does Solaris or any of the most widely used underlying OS.
Although the addition of Java may give you a new way to attack the
system (in the sense that running any program such as sendmail might
expose new security holes), I would say that if we compare running
either 100% compiled C code on DOS/Win95 or 100% Java code over a JVM
on Win95, the latter gives you more protection (due to JVM features).
As Robert Morris says, if we do not have correct code, we do not have
secure code. Nevertheless, I'd like to divide security issues into
two categories -- Java language type safety and all other protection
issues. Type safety is a hard thing to get it right, and various
pieces of code are involved. As far as other protection is concerned,
the entire java.security package in JDK1.2beta1 (going out in a few
days) contains 10730 lines code that includes *lots* of comments (all
copyright notice and javadoc comments). This is not bad at all
compared to other alternatives.
> 2) The definition of what security guarantees are being
> provided is unclear. For example, without a clear model of what it
> means for an access to be authorized, the question of whether an
> unauthorized access has occurred is unclear.
A clearer model is now specified for JDK1.2, and info is at
http://java.sun.com/products/jdk/preview/docs/guide/security/index.html
> 3) Because Java has no model of resource allocation,
> denial-of-service problems are not dealt with.
True, but I do not see any other widely used system that has this
feature. I hope that denial-of-service will be handled to some extent
soon.
> 4) The Java VM definition does not specify precisely what
> constitutes legal compiled code: it specifies neither what
> properties of compiled code are sufficient to guarantee legal
> execution by all conforming VMs, nor how those properties are
> verified by the loader. It is therefore possible for rogue bytecode
> to exploit weaknesses in particular implementations of the checker
> or in the VM's execution machinery, implementations which may
> nevertheless conform to the published specifications.
The same sort of things can be said for compiled C code too. The
theorectical possibility of creating rogue bytecode must be considered
together with the possibility of attacking your system from other
aspects, such as via browser plug-ins or cgi scripts.
> If solutions to these problems have been found, implemented, and
> published, please let us know the references.
Two papers will be published (Dec at USENIX and March at ISOC) on the
new protection model in JDK1.2, and when the final versions are done
by the end of the month, they should be available thru my web page.
(I will try send a reminder.)
Cheers.
Li