Trust-Based Security for Java

Overview

Trust-based security for Java is a cross-platform security model that provides fine-grained administration of the permissions granted to Java applets and libraries. This security system provides intermediate levels of trust so that Java applications can be given some additional permissions without being offered unlimited access to every permission in the system. The following features are provided.

• Security Zones that allow related sites (such as all sites on a company intranet) to be administered as a group.
• A Permission Model that integrates with security zones to provide parameterized control over what Java classes can do.
• Permission Signing that allows a signed cabinet file to specify not only the identity of the signer but also the set of permissions being requested for the signed classes.
• Permission Scoping that enables a developer who designs a trusted class to precisely limit the range of code for which a granted permission is enabled.
• A Package Manager that allows classes to be installed with their permissions.
• A User Interface that simplifies or eliminates the decisions that end users need to make.

Features of Trust-Based Security

Each of the features of the trust-based security system offers benefits to end users and to administrators. To further explain these benefits, the implementation of each feature is discussed in the following sections.

Security Zones

Security zones allow a system administrator to manage groups of sites using the same level of trust for a whole group. The idea is to be able to set nonrestrictive security options for trusted areas and, at the same time, set very safe (restrictive) security options elsewhere. Predefined zones exist for categories such as the Local Intranet and the Internet. Security zones relieve administrators from having to list every trusted applet and its permissions, and they help administrators avoid the risk of leaving too many detailed decisions up to end users.

There are five default security zones defined in the trust-based security for Java implementation in Internet Explorer 4.0. These zones correspond to the most commonly used types of sites.

• My Computer

  This zone includes most classes stored on the local machine. Because this zone is completely trusted, few or no security restrictions apply.
  
  

• Local Intranet

  This zone includes content that is known to be reliable (typically located inside the firewall or obtained using a secure sockets layer [SSL] connection).
  
  

• Trusted Sites

  This zone includes responsible Internet sites that are allowed to run with increased permissions, but not with the powerful permissions allowed to the Intranet zone.
  
  

• Internet

  This zone includes all other sites, including scratch and development areas inside the firewall, and untrusted parts of local drives. This zone would typically be set to the standard applet permissions.
  
  

• Restricted Sites

  This zone includes potentially harmful sites to which severely restricted permissions apply. For these sites, you may want to define "sandboxes" that are even more restrictive than the standard Java sandbox.

Network administrators can configure three different sets of permissions for each zone. The set that a permission is placed in determines whether or not the user will be presented with a dialog box that shows requested permissions.

• Permissions granted without user intervention.

  These permissions are granted to applets from the specified zone without querying the user. These permissions can be separately specified for signed and unsigned applets.
  
  

• Permissions granted with user intervention.

  These permissions can be determined directly through a list of permissions to query the user about, in which case every permission not mentioned is assumed to be denied.
  
  

• Permissions that are prohibited.

  These permissions are considered too dangerous to allow under any circumstances. They are automatically denied.
  
  

If an applet uses only permissions granted without user intervention to its zone, it will run without user intervention. If it uses any explicitly denied permissions, it will automatically be prevented from running. Otherwise, the user will be presented with a single dialog box listing all of the permissions being requested and their associated risk. The user can then make one decision about whether to trust the applet that has that set of permissions.

An applet that does not receive the additional permissions requested will still be permitted to run, but will be prevented from exercising those permissions by security exceptions. The applet can catch the security exceptions so that it can take alternate action, perhaps continuing to run with more limited functionality.

The administrator can define a set of permissions that is assigned to all unsigned classes and scripts. This set defines the permissions of unsigned applets.

The Permission Model

The permission model for trust-based security supports a useful set of parameterized and non-parameterized permissions that can be individually granted or denied for a particular zone by an administrator. To reduce the number of options that administrators must specify in common cases, the administrative user interface provides several "preset" permission sets that can be applied. These predefined permission sets, called High, Medium, and Low, represent the most restrictive to the least restrictive predefined set of permissions, respectively.

Permissions can only be defined by system libraries with the highest degree of trust. This solves the problem of having to administer a potentially unlimited set of permission requests with uncertain, application-defined meanings.

Defined Permissions

The following list describes each permission defined by the permission model and lists the parameters available for limiting each permission.

• Client Storage Permission

  Determines whether applets can access scratch space. Parameters for this permission include the size of the scratch space and flags that indicate whether storage is exempt from global storage limits and whether roaming files can be created. For more information, see the ClientStoragePermission class.
  
  

• Execution Permission

  Determines which programs can be executed on the client's machine. Parameters for this permission include a pattern that indicates which applications to include or exclude from the permission. For more information, see the ExecutionPermission class.
  
  

• File I/O Permission

  Determines whether applets can perform file operations. Parameters include the type of access (read, write, or delete), the filename or a pattern that indicates a group of files, and a flag that specifies whether the operation is denied or allowed. For more information, see the FileIOPermission class.
  
  

• Multimedia Permission

  Controls access to extended multimedia capability. This permission has no parameters. For more information, see the MultimediaPermission class.
  
  

• Network I/O Permission

  Controls the ability to perform networking components for three types of network operations: connect, bind, and multicast. Parameters include the network operation type (connect, bind, or multicast), a flag that indicates allowing or denying the operation, a pattern that indicates which hosts or ports to include or exclude, Internet Protocol (IP) addresses, port ranges, and flags that indicate whether you can bind to a non-file:// URL codebase or to a file://URL codebase. For more information, see the NetIOPermission class.
  
  

• Printing Permission

  Controls whether an applet is allowed to print. This permission has no parameters. For more information, see the PrintingPermission class.
  
  

• Property Permission

  Controls the ability to access and manipulate the global system properties. Parameters include a flag that indicates whether access to all properties is turned on or off, a pattern that indicates which properties are included or excluded, and suffixes indicating properties that could be accessed under certain conditions. For more information, see the PropertyPermission class.
  
  

• Reflection Permission

  Determines whether access to the java.lang.reflect API is permitted. Parameters include a loader type (same loader, different loader, system loader, all, or none) and an access type (public or declared). For more information, see the ReflectionPermission class.
  
  

• Registry Permission

  Controls the ability to access the registry. Parameters include the type of access (read, write, open, delete, or create) and a pattern that indicates which keys/values are included or excluded from access. For more information, see the RegistryPermission class.
  
  

• Security Permission

  Controls access to the java.lang.security package. This permission has no parameters. For more information, see the SecurityPermission class.
  
  

• System Streams Permission

  Controls the ability to change the values of the system streams java.lang.System.in, java.lang.System.out, and java.lang.System.err. Parameters include flags that indicate whether System.in, System.out, and System.err can be set. For more information, see the SystemStreamsPermission class.
  
  

• Thread Permission

  Controls the ability to create and manipulate threads and thread groups. Parameters include a thread or thread group object, a flag that indicates whether unrestricted thread access is allowed, and a flag that indicates whether unrestricted thread group access is allowed. For more information, see the ThreadPermission class.
  
  

• User File I/O Permission

  Determines whether user-directed file I/O can be performed. Parameters for this permission include the access type (read or write) and a file name or a pattern that indicates which files to allow access to. For more information, see the UserFileIOPermission class.
  
  

• User Interface Permission

  Controls the ability to create top level windows, access the system clipboard, create file dialog boxes, and access the AWT event queue. Parameters for this permission include flags that indicate access to one or more of the enhanced UI functions. For more information, see the UIPermission class.
  
  

Defining Applet Permissions

The following sets of permissions correspond to the standard Java sandbox.

• Thread access in the current execution context.
• Network connections to the applet host.
• Creation of top-level windows with warning banners.
• Reflection to classes from the same loader.
• Access to base system properties.

You can choose these permissions or you can set up an even more restrictive set of permissions for applets. Choosing a less restrictive set is not recommended

Defining Custom Permissions

Internet service providers or personal users might want to define custom permissions. Permission objects can be defined to protect some functionality in your code against misuse. Custom permissions can be added to the digital signature so that the user can decide (via a dialog box) whether or not to accept the risk. To add custom permissions to the digital signature, you would specify the requested permissions in an .ini file that is used by the signcode tool when signing the cabinet file. For more information about using the permission .ini file with the signcode tool, see the Signing a Cabinet File with Java Permissions Using Signcode article and the Sample Permissions .INI File.

Permission Signing

Permission signing extends the signed cabinet file functionality provided by Microsoft® Internet Explorer 3.0. Under trust-based security, a signed cabinet file can securely specify not only the identity of the signer but also the set of permissions being requested for the signed classes. The security system can determine all of the permissions requested by a Java component by inspecting the digital signature. This information is used to present to the user a single dialog box that displays all of the relevant trust questions. The dialog box is presented before any code starts to run. In addition, because the set of permissions is fully defined and understood by the Microsoft Win32 VM for Java, the dialog box can accurately warn users about the risk of each requested permission. For more information on permission signing, see the article on Signing a Cabinet File with Java Permissions Using Signcode.

Permission Scoping

Permission scoping prevents permissions granted to a trusted component from being misused (either inadvertently or intentionally) by a less trusted component. A trusted class can precisely limit the range of code for which a granted permission is enabled. This is an important issue because some methods that use enhanced permissions are designed to be safely called by anyone, while other methods are designed to be used internally by trusted callers only and should not expose their permissions to less trusted callers.

Trust-based security distinguishes between permissions that have been granted to a class and permissions that are actually enabled at a particular time. The granted permissions are determined by the administrative options for a class's zone and by the permissions with which the class was signed. In contrast, enabled permissions are determined by the permissions granted to other callers on the call stack and by any calls that were made to the assertPermission, denyPermission, and revertPermission methods. If there are any less trusted callers on the call stack, the enabled permissions can be more restrictive than the granted permissions.

When the Microsoft VM for Java implements permission scoping, two rules are followed. The first rule is that permissions are never inherited from the caller. If a class has not been directly granted a permission, it can never make use of that permission, regardless of what permissions its callers may have. This makes trust-based security invulnerable to "luring" attacks, in which an untrusted class "lures" a trusted class into calling it so that the untrusted class is allowed to make use of the expanded permissions of its caller.

The second rule is that even if a class has been granted a permission, its methods must explicitly enable that permission using the assertPermission method whenever there is a caller on the call stack that has not been granted that permission. In other words, permission P is enabled only if either statement 1 or 2 listed below is true, and if statement 3 is true.

1. P is granted in all of the stack frames from the active frame up to the earliest frame on the stack.
2. P is granted in all of the stack frames up to a frame that has called assertPermission on P.
3. No intervening frame has called denyPermission on P.

The deep security checks of the PolicyEngine class perform the stack crawl that follows the above rules. The Java APIs contain calls to the StandardSecurityManager checkXX methods, which in turn call the PolicyEngine.checkPermission methods to check for a particular permission.

The methods of the PolicyEngine class allows you to control which permissions are enabled. For example, the following code sample asserts the right to access scratch space through the com.ms.io.clientstorage APIs, then reverts this right.

import com.ms.security.*;
import com.ms.io.clientstorage.*;

// Assert the right to access the 
// com.ms.io.clientstorage APIs.
PolicyEngine.assertPermission(PermissionID.CLIENTSTORE);

// Now open a file for writing. Because rights have been
// asserted, this check will succeed even if the callers 
// do not possess the CLIENTSTORE permission. 
OutputStream os = 
   ClientStorageManager.openWritable("Scratch1.txt");

...
// Remove the scratch space assertion.
PolicyEngine.revertPermission(PermissionID.CLIENTSTORE);
...

// Open a file for reading.
// This time the callers will be included in the 
// security check because the right to access the 
// com.ms.io.clientstorage APIs is no longer asserted.
// The security check will succeed only if all callers
// have the appropriate CLIENTSTORE permission.
InputStream is = 
   ClientStorageManager.openReadable("Scratch2.txt");
...

For more information on asserting, denying, and reverting permissions, see the com.ms.security overview. For more information about how the stack crawl for security checks is implemented, see the overview for the PolicyEngine class.

The Package Manager

The package manager allows the installation of local class libraries that are not fully trusted by using permission signing. This is especially important for components such as JavaBeans and class libraries. It is desirable to allow these components to reside locally and to have some expanded permissions, but it is often not necessary to give them unlimited power.

System libraries are libraries that are shared and have all possible security permissions available to them. These libraries are the core of the Java system APIs, and they are the most privileged Java code. Most packages installed from non-system providers do not need this level of permissions. However, Java has traditionally treated all local classes on the class path as if they were system libraries.

Under trust-based security, classes from installed packages are not shared between applets or applications that use them. They carry specific system permission identifiers that are approved by either the user or the system administrator when the package is installed on the user's system. The permission identifiers determine the maximum permissions that can be used by the classes in that package. For more information on the package manager, see the Java Package Management article.

The User Interface

The user interface (UI) defined by trust-based security for Java shields end users from complicated trust decisions and reduces the number of dialog boxes that they must respond to. The integration of permissions with zones means that users only need to make a simple yes/no decision about whether to trust an application. An administrator has already made preliminary decisions, based on the zone involved, about which permissions to leave to the discretion of the user.

Permission signing allows the security system for the Microsoft VM for Java to predetermine all of the permissions required by a class. When a package is installed, the security system uses the digital signature to determine exactly which system permissions are needed. Before the code runs, a single dialog box clearly presents to the user all of the permissions required by an application.

Summary

Trust-based security for Java provides a flexible, easy to use security system. The permission model provides control over what a Java class can do by providing a way to associate a set of permissions with a class. Encoding the permission set in the digital signature allows the Microsoft VM for Java to present the end user with a dialog box that lists the requested permissions so that the user can decide whether to trust the applet. Because administrators can make preliminary security decisions based on predefined zones, the end user is spared from many tedious security decisions. Permission scoping prevents untrusted classes from taking advantage of the expanded permissions of trusted classes and gives developers the ability to decide which parts of their trusted code enable a particular permission. Finally, package management allows for local installation of components that are not fully trusted so that those components have expanded permissions, but not unlimited power.