[5274] in java-interest
Re: Netscape security => lame applets
daemon@ATHENA.MIT.EDU (Doug Lea)
Sun Feb 4 18:45:25 1996
Date: Sun, 4 Feb 1996 17:16:37 -0500
From: Doug Lea <dl@altair.cs.oswego.edu>
To: Walter@adco.com
CC: horstman@jupiter.SJSU.EDU, java-interest@java.sun.com
In-reply-to: <199602040246.VAA09814@cs.oswego.edu> (Walter@adco.com)
Walter Szewelanczyk writes...
> There are many, many other examples of usefull applets that need to
> access other hosts than the one that they connected to.
Yes, I'm entirely sympathetic. I had written a bunch of such things in
Alpha Java that cannot work within Java-1.0/Netscape-2 policies. I've
been trying to redo some of them, much less elegantly, while giving up
as little functionality as I can. I figured I'd save some people some
effort by describing some tricks I'd discovered.
Of course, I'd love to have a kludge-free way of putting together open
but secure distributed OO applications based around Java Applets. But
it doesn't look like this will happen soon or easily.
Here comes a much-too-long diagnosis/discussion (sorry!) about why I
think that's so.
As I understand it, one of the main considerations leading to the
current Applet security policies is the need to respect firewalls. If
you allow unlimited connectivity, then an Applet can be the cause of a
firewall breach. An Applet inside the firewall can open sockets to
some external machine, Ext, and to an internal machine, Int, and
thereby transmit data from Int to Ext (and/or vice-versa):
outside | inside
Ext ----- | ----- Applet ----- Int
There is no way for the Java runtime to know whether an Applet is
trying to do such a thing, as opposed to, say, just opening two
external URLs.
Notes:
1. `Applet' and `Int' might be the same machine. This is in
part why Applets cannot read/write from/to their own file
systems.
2. For http transport anyway, there's basically no way to fully
separate the notion of `reading' from `writing', so you cannot
base a very secure policy on this distinction. For example, it
wouldn't work to restrict communication for Applet to do only
HTTP GETs to Ext here. The Applet can encode any information it
likes as part of a URL used in a GET (as is done for CGIs), so
could, for example, leak out information from Int to Ext as part
of URL open requests.
3. Note that someone could write a non-java (say, C) program
that connects Int to Ext. The ability to do such things is
treated as a local policy matter though. The difference between
a C program and a Java program is that no one from the outside
can (legitimately) cause such a C program to run without the
knowing assistance of someone on the inside. But a Java program
from the outside just starts running in a browser without any
knowledge or intervention of the user, so security policies must
in part be embedded directly in the Java runtime.
4. The ability to dynamically pass connection information
(machine IDs, ports, hostnames, etc) along with any other kind
of information, from one program/machine to another is one of
the cornerstones of open systems. Without it, you wouldn't have
the internet. But the fact that any such infrastructure has to
be designed to allow connection/handle/name-passing also makes
it harder to restrict things so as to only selectively close off
part of the system. These days, now-standard firewall techniques
represent awkward and often hard-to-live-with parts of any such
solution.
To disable these kinds of scenarios, the current rules disallow ALL
communication except woth machines that serve as codebases. The
underlying notion here appears to be that serving as a codebase is a
kind of certificate of communicability. Actually, there's little
choice about this part; the rules really have to allow communication
to codebases. The codebase machine must be talked to by the client
Java runtime in order to pull the needed .class files anyway. And if
you didn't also allow the Applets themselves to open connections from
their codebases, they wouldn't be able to pull over GIFs and the like
as part of their functionality, and would be too crippled to be useful
on the WWW.
So, the above Ext<-Applet->Int path would be legal only if both Ext
and Int served as codebases. Presumably, system administrators of
internal machines that should never communicate with the outside world
would not allow them to serve as codebases.
That's the current state of affairs, at least so far as I understand
them. (Although that's not the whole story about Applet security. For
example, there's the issue of whether a pulled .class file is really
the one a client asked for, which could (will?) be settled via
signature-based encryption.)
I know that there are lots of people at Sun and elsewhere trying to
fashion different rules and frameworks that still respect firewalls
and other commonly desired security properties, but here's a rundown
of options that I know of, ranging from quick-and-dirty to heavy and
hard-to-implement:
1. Change the way that the current codebase-allows-communication
rule is interpreted. For example, allow communication to any machine
that COULD serve as a codebase. This could be done, for example,
by trying to grab a ConnectingApplet.class file (as described
in my previous posting), or something along those lines, before
allowing a socket to be used or a URL to be opened.
2. Allow communication only to particular ports on machines that
connect to standardized, generic Java daemon agents. This is the
same idea as (1) but at a lower, more efficient, and more
controllable level. The daemons can implement any particular local
security policy they like for Applet communication (as opposed to
possibly different policies for serving other HTTP requests.) This
is the easiest way to build `Java-ized servers' that speak only
some special structured-message-based protocol (not HTTP) for
Java-to-Java communication. (For example, my (but not most
people's) favorite such protocol is for Applets to send
.class-style Java bytecode closures that can be verified and
interpreted by the daemons -- this meshes nicely with (4) below.)
3. On top of something like (2), establish a full capability-based
system. Don't allow Applets to make connections given only
name-based handles like hostnames or InetAddresses. Instead, use
values of a new built-in primitive type (or perhaps an extended
version of current reference types) that intrinsically and securely
carry information about what a holder may do with them. Such
capabilities would be a lot like Java `interface reference' values
-- a holder may only invoke operations on them that are known to be
supported. The main addition is that the ability to copy/relay a
capability may itself be one of its properties. So, for example, it
might not be legal to pass a capability as an argument from one
machine to another, or even from one Java method to another. There
are lots of specific forms of such capabilities possible. For
example those that contain originating information, access lists,
passwords, tunable rights-transfers, etc. And several existing standard
implementations to choose among. It's hard to choose a form that's
perfect for all possible purposes.
4. In addition to (3), establish a different Java local name-space/binding
discipline at least for Applets; in particular, the lexical closure
strategy used in Obliq and Python. (This would be a noticeable
change to the Java language.) This attacks the bridging-Applet
problem at its source. One reason that a firewall breach can happen
in the first place is that a client's Java interpretor maintains
information and rights over and above that `brought in' by an
Applet. The Applet can determine and exploit enough of the client's
rights to build the bridge. (This is seen in the `ConnectingApplet'
design used to circumvent current rules.) Lexical closure rules
are the simplest, best-understood, and most easily verifiable way
to make sure that Applets obey the basic axioms of capabilities;
i.e., that objects use only those references/capabilities that
* they are born knowing about.
* they create (by constructing new objects, if so able).
* they obtain as arguments/results in messages from other objects.
5. In addition to any of the above, optionally support things like:
* Ways to restrict some or all communications to particular
sequences of exchanges, presumably those corresponding to
standard security protocols.
* Ways for users to transparently interpose other screening,
filtering, encrypting, etc., objects between their machine
and others to monitor and control message traffic.
As you traverse down through these options, you find that doing all of
this right amounts to putting together a full native Java distributed
object messaging system. Except for the kludgy option (1), none of
them are very compatible with just using HTTP transport and other
typical WWW practices, but all of them are required parts of any
secure, open, remote OO framework. Something like what CORBA might
have been had it been designed around Java, and been designed
primarily for WWW use.
Or something like what Java was when it was OAK.
Note that there's nothing (except a lot of hard work) stopping you
from handcrafting a non-Applet-compatible distributed OO system
yourself as a set of frameworks and conventions purely on top of
existing basic Java capabilities. But of course, it would not be
usable with Applets.
Given all this, I think there's only one reasonable conclusion: That it is
better to live with / work around current Applet rules for the time
being, while also experimenting with non-Applet-compatible but secure,
open, ..., Java-based distributed object systems before trying to mesh
them together into something that will be sensible and defensible in
the long run.
--
Doug Lea | dl@cs.oswego.edu | dl@cat.syr.edu | 315-341-2688 | FAX 315-341-5424
Computer Science Dept, SUNY Oswego, Oswego, NY 13126 | http://g.oswego.edu/dl/
Also: Software Eng. Lab, NY CASE Center, Syracuse Univ, Syracuse NY 13244
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
