One of the most important features of Java is its security model. It allows untrusted code, such as applets downloaded from arbitrary web sites, to be run in a restricted environment that prevents that code from doing anything malicious, like deleting files or sending fake email. The Java security model has evolved considerably between Java 1.0 and Java 1.2 and is covered in detail in Java in a Nutshell.
To write applets, you don't need to understand the entire Java security model. What you do need to know is that when your applet is run as untrusted code, it is subject to quite a few security restrictions that limit the kinds of things it can do. This section describes those security restrictions and also describes how you can attach a digital signature to applets, so that users can treat them as trusted code and run them in a less restrictive environment.
The following list details the security restrictions that are typically imposed on untrusted applet code. Different web browsers and applet viewers may impose slightly different security restrictions and may allow the end user to customize or selectively relax the restrictions. In general, however, you should assume that your untrusted applet are restricted in the following ways:
Untrusted code cannot read from or write to the local filesystem. This means that untrusted code cannot:
Read files
List directories
Check for the existence of files
Obtain the size or modification date of files
Obtain the read and write permissions of a file
Test whether a filename is a file or directory
Write files
Delete files
Create directories
Rename files
Read or write from FileDescriptor objects
Untrusted code cannot perform networking operations, except in certain restricted ways. Untrusted code cannot:
Create a network connection to any computer other than the one from which the code was itself loaded
Listen for network connections on any of the privileged ports with numbers less than or equal to 1,024
Accept network connections on ports less than or equal to 1,024 or from any host other than the one from which the code itself was loaded
Use multicast sockets
Create or register a SocketImplFactory, URLStreamHandlerFactory, or ContentHandlerFactory
Untrusted code cannot make use of certain system facilities. It cannot:
Exit the Java interpreter by calling System.exit() or Runtime.exit()
Spawn new processes by calling any of the Runtime.exec() methods
Dynamically load native code libraries with the load() or loadLibrary() methods of Runtime or System
Untrusted code cannot make use of certain AWT facilities. One major restriction is that all windows created by untrusted code display a prominent visual indication that they have been created by untrusted code and are "insecure." This is to prevent untrusted code from spoofing the on-screen appearance of trusted code. Additionally, untrusted code cannot:
Initiate a print job
Access the system clipboard
Access the system event queue
Untrusted code has restricted access to system properties. It cannot call System.getProperties(), so it cannot modify or insert properties into the system properties list. It can call System.getProperty() to read individual properties but can read only system properties to which it has been explicitly granted access. By default, appletviewer grants access to only the following 10 properties. Note that user.home and user.dir are excluded:
java.version
java.class.version
java.vendor
java.vendor.url
os.name
os.version
os.arch
file.separator
path.separator
line.separator
Untrusted code cannot create or access threads or thread groups outside of the thread group in which the untrusted code is running.
Untrusted code has restrictions on the classes it can load and define. It cannot:
Explicitly load classes from the sun.* packages
Define classes in any of the java.* or sun.* packages
Create a ClassLoader object or call any ClassLoader methods
Untrusted code cannot use the java.lang.Class reflection methods to obtain information about nonpublic members of a class, unless the class was loaded from the same host as the untrusted code.
Untrusted code has restrictions on its use of the java.security package. It cannot:
Manipulate security identities in any way
Set or read security properties
List, look up, insert, or remove security providers
Finally, to prevent untrusted code from circumventing all of these restrictions, it is not allowed to create or register a SecurityManager object.
When an applet is loaded from the local filesystem, instead of through a network protocol, web browsers and applet viewers may relax some, or even many, of the preceding restrictions. The reason for this is that local applets are assumed to be more trustworthy than anonymous applets from the network.
Intermediate applet security policies are also possible. For example, an applet viewer can be written so that it places fewer restrictions on applets loaded from an internal corporate network than on those loaded from the Internet.
Java 1.1 added the ability to attach a digital signature to a JAR file that contains an applet. This signature securely identifies the author or origin of an applet. If you trust the author or originating organization, you can configure your web browser or applet viewer to run applets bearing that signature as trusted code, rather than as untrusted code. Such an applet runs without the onerous security restrictions placed on untrusted applets. Java 1.2 platform actually allows the security policy to be customized based on the origin of an applet. This means that an end user or system administrator may define multiple levels of trust, allowing fully trusted applets to run with all the privileges of a standalone application, while partially trusted applets run with a reduced list of security restrictions.
The process of attaching a digital signature to an applet's JAR file is platform dependent. In Java 1.1, you use the javakey program. In Java 1.2, this program has been superseded by jarsigner. Netscape and Microsoft also provide their own digital signature programs that are customized for use with their browsers.
The process of telling your web browser or applet viewer which digital signatures to trust is also vendor dependent, of course. In Java 1.1, you use javakey to specify which signatures are trusted. In Java 1.2, you use a different tool, policytool, to specify trusted signatures and the security policies associated with them. See Java in a Nutshell for further details.
 |  |  |
| 7.2. Including Applets in HTML Files |  | Part 2. API Quick Reference |
Copyright © 2001 O'Reilly & Associates. All rights reserved.