The Java Security Concept

 Since a Java-enabled Web browser allows to embed executable Java code in a Web page, which can be downloaded across the net and run on any client machine, security is a critical concern. Users can download Java applets with exceptional ease -- sometimes without even knowing it. This exposes Java users to a significant amount of risk.

For our planned SNMP applet, we will have to use the networking functions from the Java class libraries. In order to use them, it is important to understand the security concept Java uses, since networking functions are extremely dependent on the security model.

The Java security management distinguishes three different classes of Java applets. This is necessary because there is a clear difference between programs that are installed on a local machine -- and therefore will always be given a certain trust that they are not ``evil'' -- and programs that the user gets over the network. When things downloaded over the network are just text and data there is no security issue. However, downloading a Java program and executing it on the local machine is of course very much a security issue. Unless measures are taken to prevent it, a malicious (or buggy) applet could delete files, post confidential data it reads from the hard disk over the network or do other nasty stuff.

The measures that have been taken to prevent those things mostly consist of providing applets loaded over the network with a very restrictive ``sandbox'' environment in which they run. Since not all applets are loaded over the network, and locally stored programs may be trusted more, the Java security management distinguishes between the following security classes which are given different permissions to use the resources of the machine:

Applications

can connect anywhere they like, unless a new security manager which limits connections is installed. However, applications cannot run in a web browser and are therefore not interesting for us, except for the reason that they can connect any other system on the network.

Untrusted Applets

are all applets that are loaded over the network. Since code that has been loaded via the network is potentially dangerous, this code is executed in a ``sandbox'' environment where it has only limited access to the machine the web browser is running. Especially networking capabilities are being restricted to avoid the applet communicating sensitive information to the outside.

Trusted Applets

are loaded from the local machine. For trusted applets, some of the restrictions may be relaxed by the browser. They are nevertheless not granted all the privileges that applications get.

Intermediate applet security policies are also possible. An applet viewer could be implemented that would place fewer restrictions on applets loaded from an internal network (a so called ``intranet'') than on those loaded from the Internet.

The restrictions the ``sandbox'' environment is putting on an untrusted applet include the following:

• It can't load libraries or define native methods.
• It can't ordinarily read or write files on the host that's executing it.
• It can't make network connections except to the host that it came from.
• It can't start any program on the host that's executing it.
• It can't read every system property.
• Windows that an applet opens up look different than windows that an aplication opens up.

Since we want to write an applet that will run inside a web browser anywhere on our network, we have to live with those restrictions for untrusted applets. This imposes some problems, especially with SNMP, since here we forceably will need to establish network connections to SNMP agents. Since those agents are (usually) not running on the host we loaded the applet from, this imposes a major design problem here. Fortunately, AdventNet provides a solution for this problem, which we will see later.

The networking restrictions do not only depend on the source the applet is loaded from. There are also differences depending on the type of proxy server that might be located between the client browser and the web server as well as the actual implementation of the environment the applets are loaded into. Additionally, the restrictions do also depend on the kind of networking operation that is attempted. Connections to arbitrary network sockets are not routed through HTML proxies, therefore they are to be treated differently than so called ``URL connections'', which are used to fetch information from web or ftp servers and may transparently access HTTP proxies.

Table 4.1 summarizes where untrusted applets are allowed to connect using
java.net.Socket and table 4.2 summarizes where they are allowed to connect to when using java.net.URLConnection (to communicate with WWW/ftp servers etc.).

For SNMP applications, URL connections cannot be used. We need direct access to the SNMP port of the agent that is to be queried. As it can be seen from Table 4.1, this connectivity can only be achieved to the web server itself, and currently only if no HTTP proxy is used.

1012

 

Depending on the setting of the appletviewer.security.mode property, you can connect nowhere, only to the originating host, or anywhere. Can only connect to the originating host.

Same as no proxy, assuming you set the socksProxyHost property. No connections allowed (except under OS/2, where it's the same as with no proxy).

if the appletviewer.security.mode property is set to ``none'' then all connections are allowed; else no connections are allowed. No connections allowed.

1012

 

Depending on the setting of the appletviewer.security.mode property, you can connect nowhere, only to the originating host, or anywhere. Can only connect to the originating host (= the web server).

Same as no proxy, assuming you set the socksProxyHost property. Same as no proxy, assuming Netscape has been properly configured to use the proxy.

Same as no proxy, assuming you set the appropriate properties (see Proxies). Same as SOCKS Proxy.

The solution that Advent proposes as a workaround for this problem is called ``SNMP Applet Server (SAS)''. This server allows the applet to send and receive SNMP packets to and from any managed devices accessible from the web server host. The SAS program is a Java application and has to be run on the web server. The applet using the Advent library will then automatically communicate with the SAS application on the web server, which relays all communication to the agent that the applet wants to communicate with. This is possible, since Java applications don't have to deal with security problems. The whole use of the SAS is completely transparent to the programmer and the user. It suffices to start the server application on the web server once, the applet can then automatically detect the TCP port that is used on the web server and all further communication will be relayed by it.

  

Figure 4.7: Relaying SNMP communication via the SNMP applet server (SAS)

The SNMP applet server can be used for arbitrary TCP ports, not only the SNMP port. Since this would be a potential security hole, the function of the Applet server can be limited to the forwarding of messages for the SNMP port with the command-line switch. In addition to its networking capabilities, the server also provides functionality that gives the applets limited access to files stored in a user directory on the web server.

It should be mentioned that with the recent new version of the Java JDK an additional new security mechansim is introduced: So called ``signed applets''. In the future, those applets will allow the user to trust certain applets that are loaded over the network as well. For this purpose, applets can be signed using a public key mechanism. Currently, this is still under development and has no significance for us.