# Re: Java security

L. Peter Deutsch (ghost@aladdin.com)
Fri, 3 Oct 97 14:47 PDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Glenn Twiggs: "FTP Error in an Applet"
- Previous message: Li Gong: "Re: Java security"
- Maybe in reply to: L. Peter Deutsch: "Java security"

    Message-Id: <m0xHFZ8-000R25C@lamp.aladdin.com>

    Date: Fri, 3 Oct 97 14:47 PDT

    From: "L. Peter Deutsch" <ghost@aladdin.com>

    To: gong@games.eng.sun.com

    Subject: Re: Java security

> I thought there were security issues specific to image or 2D.

The security issue specific to "executable content" is a simple one. No one
sensible would download an unknown piece of executable code and execute it.
However, if "executable content" becomes widespread (and many people,
including the person who suggested adding Java attachments to the standard
formats for communicating graphics through the net, are advocating this),
accessing any document on the Net may result in executing an unknown piece
of (Java) code. In this environment, the place that the strong protection
will have to come from is the mechanism that executes this code: the Java VM
and library.

The goal that I believe is the subject of this discussion is:

Knowingly downloading a document containing executable Java content
should not create any higher security risk than knowingly
downloading a non-executable document does today.

In this context, comparisons to executing C or machine code are irrelevant,
because we (the designers of the Java systems) can exercise an arbitrary
amount of control and caution over the Java engine, which is not the case
for the OS, the C compiler, machine code libraries, downloaded plug-ins or
scripts, etc., etc. That is one of the reasons why Java is such an
important technology right now: it's one of those few historical leverage
points where addressing these problems might actually make a difference.

> No security kernel, true. But Win95 has no security kernel either,
> and neither does Solaris or any of the most widely used underlying OS.

As noted above, I don't believe this comparison is relevant to the goal
under discussion.

> 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.

Fair enough. Note, however, that any failure of the type safety mechanism
is a potential entry point for other breaches.

> 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.

I have been told, by someone who knows in more detail how security works in
Java than I do, that in fact making Java security work requires a lot of
code outside the java.security package to make explicit security checks
correctly: this is not the case with an OS that has a security kernel. I
don't know enough to substantiate or refute this claim, but if you disagree
with it, I'll try to dig up details.

> 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

Good. I'll read it with interest.

> 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.

Some versions of scheme have the necessary hooks for it, and in a
(conceptually) interpreted language, it's easy to add, because the
implementor of the VM has control over all accesses to all of the resources
(CPU time, virtual address space, screen real estate, and external sharable
resources like the file system). Whether "any other widely used system" has
protections against this is irrelevant: again, see the goal statement at the
beginning of this e-mail.

> The same sort of things can be said for compiled C code too.

Again, see above.

> The theorectical possibility of creating rogue bytecode

It is not theoretical: as I recall, a couple of students demonstrated within
the last year or two that they could wipe out one's filesystem by doing
this.

> must be considered
> together with the possibility of attacking your system from other aspects,
> such as via browser plug-ins or cgi scripts.

Again, see above.

    --

    L. Peter Deutsch         |       Aladdin Enterprises :::: ghost@aladdin.com
    203 Santa Margarita Ave. | tel. +1-650-322-0103 (AM only); fax +1-650-322-1734
                             | ** NOTE ^^^ NEW AREA CODE AS OF AUG. 1 ^^^ **
    Menlo Park, CA 94025     |        http://www.cs.wisc.edu/~ghost/index.html
                "Few things are impossible to diligence and skill."

- Next message: Glenn Twiggs: "FTP Error in an Applet"
- Previous message: Li Gong: "Re: Java security"
- Maybe in reply to: L. Peter Deutsch: "Java security"