Understanding Permission-Based Security for Microsoft Virtual Machine

Permission-based security for Microsoft Virtual Machine (which is Java-compatible) is a Windows 32-bit security model that provides fine-grained management of the permissions granted to Java applets and libraries. This model uses Java cabinet (.cab) file-signing technology to ensure that an applet can perform actions only for which it specifically requests permissions.

Using permission-based security for Microsoft Virtual Machine, developers can precisely limit the section of code where permissions have been granted, and administrators can control the permissions granted to Java code, such as access to scratch space, local files, and network connections. Also, when used in conjunction with security zones, permission-based security for Microsoft Virtual Machine can simplify security decisions because it permits sets of Java permissions to be specified for each security zone.

Permission-based security for Microsoft Virtual Machine includes the following elements:

• Permission-based security model - This security model provides fine-grained control over the actions that Java classes can perform.

• Security zones - You can use security zones to assign security settings to a group of Web sites, such as all sites on a company intranet.

• Permission signing - You can use permission signing to associate specific security permissions with a Java package. You can specify the identity of the signer for the package's cabinet (.cab) file and the set of permissions being requested by the signed classes.

• Permission scoping - This feature enables you to precisely limit the sections of code for which a granted permission is enabled.

• Package Manager - The Package Manager allows classes to be installed with their associated permissions. Using the Package Manager, you can also control the permissions granted to local classes.

• Trust User Interface - This interface enables you to greatly simplify or eliminate the decisions that users need to make about the permissions granted to an applet.

The following sections describe these features of permission-based security for Microsoft Virtual Machine. For more information, see the MSDN Online Web site and the Microsoft Software Development Kit for Java.

Permission-Based Security Model

The permission-based security model for Microsoft Virtual Machine supports a set of parameterized and non-parameterized permissions that can individually be granted or denied. For an applet to obtain access to the desired set of resources, such as a file's input and output, the applet must be signed with the proper permissions. For more information about permission signing, see "Permission Signing" later in this chapter.

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

• Allow thread access in the current execution context.

• Open network connections to the applet host.

• Create a top-level pop-up window with a warning banner.

• Access reflection application program interfaces (APIs) for classes from the same loader.

• Read base system properties.

Security Zones

Security zones integrate with the permission-based security model to create a configurable, extensible mechanism for providing security for users. Whenever users attempt to open or download content from the Web, Internet Explorer checks the security settings associated with that Web site's security zone. For more information about security zones, see "Understanding Security Zones" earlier in this chapter.

You can configure three different sets of permissions for each security zone for both signed and unsigned code:

• Permissions that are granted without user intervention - These permissions are available to applets from the zone without user intervention. They can be specified separately for signed and unsigned applets.

• Permissions that are granted with user intervention - Users are prompted about whether to grant these permissions to applets from the zone.

• Permissions that are denied - These permissions are considered harmful and are automatically denied to applets from the zone.

Only applets that have permissions granted without user intervention run automatically. An applet that has been denied permissions will not run. If an applet uses permissions granted with user intervention, Internet Explorer displays a dialog box with a list of all the permissions and their associated risks and prompts the user about whether to trust the applet. If the user chooses not to trust the applet, the applet can continue to run with alternate and limited functionality, but the applet is prevented from using the expanded set of permissions.

Note The user will be asked to confirm execution of the applet only if it requests more permissions than the zone can automatically grant. You can configure the specific permissions that Internet Explorer will automatically grant in each zone.

For more information about setting up permissions for each security zone, see "Configuring Java Custom Security" later in this chapter.

Permission Signing

Permission signing extends the signed .cab file functionality provided by previous versions of Internet Explorer. Under permission-based security, a signed .cab file can securely specify not only the identity of the signer, but also the set of permissions being requested for the signed classes.

When the signed .cab file is downloaded, the signature is examined for permission information before any code is permitted to run. By signing your applet with Java permission information, you request only the specific permissions that you need. Because your applet can perform only the actions that it specifically requests permission to perform, users can make informed decisions about the risks associated with running your applet.

Microsoft Virtual Machine uses the permissions requested in the signature and the user's general security preferences to determine whether to grant the requested access. If Microsoft Virtual Machine cannot automatically grant the requested access, it displays a dialog box prompting the user about whether the applet should be allowed to run. If the user approves, the applet is run with the permissions it requests. Otherwise, the applet is run in the sandbox. Because the set of permissions are fully defined and understood by Microsoft Virtual Machine, the requested permission information is displayed, and the user is warned about the risk of each requested access.

Note The .cab files can contain both Microsoft ActiveX controls and Java code. Because ActiveX controls must be fully trusted to be run, they are treated differently from Java code. For ActiveX controls to run when they are in a .cab file that uses permission signing, you must specify in the signature that the .cab file contains ActiveX controls.

Java code can be signed with the default capabilities of the following safety settings:

• High Safety - This setting is a restrictive set of capabilities that are the equivalent of "sandboxed" Java code. In addition, High Safety allows the applet to do the following:

  • Allow thread access in the current execution context.

  • Open network connections to the applet host.

  • Create a top-level pop-up window with a warning banner.

  • Access reflection APIs for classes from the same loader.

  • Read base system properties.

• Medium Safety - This setting includes the capabilities of High Safety. In addition, Medium Safety allows the applet to do the following:

  • Access scratch space.

  • Perform user-directed file input and output.

• Low Safety - This setting includes the capabilities of High and Medium Safety. In addition, Low Safety allows the applet to do the following:

  • Perform file input and output.

  • Execute other applications on the client computer.

  • Implement user-interface dialog boxes.

  • Provide thread group access in the current execution context.

  • Open network connections with computers other than the host.

  • Load libraries on the client computer.

  • Make native method calls.

  • Determine whether an applet can make native method calls.

  • Create a top-level pop-up window without a warning banner.

  • Exit the virtual machine.

  • Perform registry operations.

  • Perform printing operations.

  • Create a class loader.

Custom permissions can also be used if you need more fine-grained control of the types of permissions granted to the signed code. Custom permissions are defined in an initialization (.ini) file. The .ini file includes a section for each desired permission, which defines its necessary parameters. You can create the .ini file manually, or you can use the Piniedit tool provided with the Microsoft Software Development Kit for Java.

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 a particularly important feature 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.

Permission-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 the permissions with which the class was signed. Enabled permissions are determined by the permissions granted to other callers on the call stack and whether any explicit calls to the assertPermission , denyPermission , or revertPermission methods have been made. If there are less trusted callers on the call stack, the enabled permissions can be more restrictive than the granted permissions.

Microsoft Virtual Machine follows two rules for permission scoping:

• Permissions are never inherited from the caller. If a class has not been directly granted a permission, then it can never make use of that permission, regardless of what permissions its callers have. This means that an untrusted class would never incorrectly be allowed to make use of the expanded permissions of its caller.

• 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.
  For example, permission P is enabled only if the following statements are true:

  • P is granted in all of the stack frames from the active frame up to the earliest frame on the stack.

  • P is granted in all of the stack frames up to a frame that has called assertPermission on P.

  • No intervening frame has called denyPermission on P.

Permission-based security for Microsoft Virtual Machine checks to see whether the code making the call to perform a trusted operation is signed with the proper level of permissions before honoring the assertPermission request. A security exception occurs if the caller was not signed with the permissions for the operation that it is trying to perform.

Package Manager

The Package Manager administers the installation of Java packages and classes and provides a database for storing them. The Package Manager uses permission signing to allow the installation of local class libraries that are not fully trusted. This is especially important for JavaBeans and class libraries. It is desirable to allow these components to reside locally and to have some expanded permissions, but not to give them unlimited power.

The Package Manager was designed to address the limitations of using the CLASSPATH environment variable. It does so in the following ways:

• Security - Packages and classes installed through the Package Manager are not implicitly trusted as system library classes. Any Java package installed through the Package Manager that requires access to certain resources on the user's computer must be signed with the desired permissions. The Package Manager, in coordination with the security manager in Microsoft Virtual Machine, enforces these signed permissions.

• Versioning - The Package Manager database stores the version number of every Java package it installs. By tracking version numbers, the Package Manager can upgrade Java packages if a newer version is being installed or downloaded from the network. The Package Manager can also eliminate any downgrading of Java packages.

• Installing Java packages - When Java packages are installed through the Package Manager, it is not necessary to update the CLASSPATH environment variable. Therefore, the user does not need to restart the computer.

• Namespace - To prevent namespace collision, Java packages can be installed under the global namespace or under an application namespace. Packages installed in the application namespace are visible only to applications running in that namespace. Packages in the global namespace are visible to all Java applications.

• Load-time performance - The Package Manager locally stores all of the packages it installs on the user's computer, which greatly speeds up class load time performance for Java applets. This improved performance occurs because the classes do not need to be downloaded from the network every time the user visits the Web page containing the applet.
  When the application classes are loaded from the user's computer, they will still be restricted to the permissions the application was originally signed with. The Java package includes specific system permission identifiers that are approved when the package is installed on the user's computer. These permission identifiers determine the maximum permissions that can be used by the classes in a specific package.

• Upgrading - When a user revisits a Web page that contains a newer version of a Java package (which was previously installed through the Package Manager), the new version is downloaded and the local classes are automatically upgraded. The Java applet or application must be packaged in a .cab file and signed with the permissions it needs to run.

Trust User Interface

The Trust User Interface defined by permission-based security for Microsoft Virtual Machine shields users from complicated trust decisions and reduces the number of dialog boxes they must respond to. The integration of permissions with security zones means that users need to make only a simple "Yes or No" choice when deciding whether to trust an application. The complex decisions about which permissions to allow have already been made by an administrator.

In addition, permission signing allows the security system to predetermine all the permissions required by a class. When a package is installed, the security system can use the signature to determine exactly the system permissions that it needs to provide, and a single trust dialog box can reliably present all of the permissions required by an application before running any code. Because the default system permissions are well defined and static, their level of risk can be determined and refined over time, ensuring that the level of risk is acceptable.

.