HotJavaTM Browser Security Notes

This page contains notes about JavaTM applet and JavaScriptTM security that are of particular interest to Java applet and JavaScript developers. Look here for information about:

- Javakey Restriction
- Loading Multiple Applets From a Single Codebase
- Details on Security Levels
  - Avoiding Deadlocks in Ask First Mode

## Javakey Restriction

If you mark a certificate as "trusted" using the javakey utility, applets running on your machine that are signed with that certificate are treated by your system as if they are trusted local application code. These applets will not be subject to any security manager controls you set in the HotJava Browser application.

This has no effect on users who download your applet unless they also use the javakey utility to mark the certificate as trusted.

For information about using javakey, see the Javakey page for Solaris or for Windows.

## Loading Multiple Applets From a Single Codebase

If an unsigned applet is loaded from the same codebase as a signed applet, the unsigned applet uses the same class loader. When the unsigned applet calls methods in the signed applet's classes, the unsigned applet is treated with the same level of trust as the signed applet. Applet developers should avoid mixing signed and unsigned code.

For information about how an applet's codebase relates to its scope, see Inter-Applet Communication in HotJava Browser.

## Details on Security Levels

Use the HotJava Browser Security Preferences page (Edit->Security Preferences) to set a default security level that will apply to all signed applets, one that will apply to all unsigned applets and JavaScript, and possibly all code that comes from a particular web site or signed by a particular certificate. You can allow applets and JavaScript any of four security levels, defined below.

See the Security Preferences Help page in HotJava Browser for information on how to set each of the security levels. The information on that Help page duplicates some of the information provided below, but this document provides additional technical information.

Note: For simplicity, the remainder of this document refers only to security for Java applets. The same information applies to security for JavaScript.

The following table provides information about allowed applet behavior at each security level. The Unprotected security level is only available on the Special Cases Security Preferences panel.

Note that in addition to the tangible protections described below, the Java language and HotJava Browser work together to enforce other constraints on Java applets to make them run in a safe fashion. For example, applets are not permitted to send messages to windows that cause them to be closed (except windows the applet has created on its own).

| Security Restriction Level
| Blocked | Restricted | Ask First | Unprotected
Read Files | No | No1 | Warn1 | Yes
Write Files | No | No | Warn | Yes
Delete Files | No | No | Warn | Yes
Access HotJava Browser Properties | No | Limited2 | Warn | Yes
Manipulate Threads | No | Limited3 | Limited3 | Limited3
Exit HotJava Browser | No | No | No | No
Start Local Applications | No | No | Warn | Warn
Link to Local Libraries or DLLs | No | No | No | Yes
Listen on Network Port | No | Limited4 | Warn | Yes
Accept Network Connection | No | Limited5 | Warn7 | Yes
Connect to Another Computer | No | Limited6 | Warn7 | Yes
Create Windows | No | Yes8 | Yes8 | Yes
Access Clipboard | No | No | No | Yes
Access Print Queue | No | No | No | Yes
Access AWT Event Queue | No | No | No | Yes

Permissions listed as "Warn" have the following behavior:

> Each time an applet attempts one of the listed actions, (for example, read a file), HotJava Browser checks its list of granted permissions. If the specific permission has previously been granted, it is allowed. Otherwise, the user chooses through a dialog box to either allow this specific action (read the specified file), allow all similar actions (read any file), or block the action (deny reading this file this time).

Footnotes:

1: Applets with Ask First or Restricted security that are loaded using the file protocol have read access (without warning) to files in the directory from which they were loaded.

2: Individual properties can be exposed to Restricted security applets by creating another property with a name in the form of propertyname.applet=true. For example, to allow applets access to the user.name property, add an additional property user.name.applet=true. See HotJava Browser Property Files for information about editing your personal or admin properties file. The default standard set of properties that applets have access to are java.version, java.vendor, java.vendor.url, java.class.version, os.name, os.version, os.arch, file.separator, path.separator, and line.separator.

3: Applets with Unprotected, Ask First, or Restricted security may manipulate their own thread priorities.

4: Applets with Restricted security may listen on ports 1024 and higher.

5: Applets with Restricted security may accept connections from their originating site, but no others.

6: Applets with Restricted security may connect to their originating site, but no others.

7: User is warned and can deny permission when an applet attempts any network access except when connecting to the applet's original site.

8: Windows created by applets with Restricted or Ask First security will show a warning banner.

Additional Restrictions and Permissions:

- Applets with Restricted or Ask First Security are not allowed access to classes in packages that are identified using the property package.restrict.access.[packagename]=true. This is true for both system classes loaded via CLASSPATH and classes loaded over the network. For example, package sun.* is not accessible to applets due to the property package.restrict.access.sun=true.

- Applets with Restricted or Ask First Security are not allowed to define classes in packages identified using the property package.restrict.definition.[packagename]=true. By default, applets are not allowed to define classes in the sun and java packages.

- Applets with Restricted or Ask First Security can only connect to their originating host if the applet is loaded via a protocol with the property applet.protocol.host.meaningful set to true. By default, the following properties are set: applet.http.host.meaningful=true, applet.https.host.meaningful=true, applet.ftp.host.meaningful=true, and applet.gopher.host.meaningful=true.

Avoiding Deadlocks in Ask First Mode:

Applet developers need to be aware of a condition that can cause deadlocks.

When applets are run in the Ask First security mode, security checks initiated from the AWT event queue thread will cause a deadlock. Deadlocks will occur because the event queue is no longer serviced during the dialog interaction. Therefore, avoid potentially security-restricted actions when running in the context of the AWT event queue thread, unless you can ensure the applet is not able to run in the Ask First mode.

Copyright © Sun Microsystems, Inc.