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