Export (0) Print
Expand All
2 out of 4 rated this helpful - Rate this topic

Chapter 7 - Permission-Based Security for Microsoft Virtual Machine

Microsoft® Internet Explorer 6 provides comprehensive management and enforcement of Internet and network security. This chapter describes a key feature of security management—permission-based security for Microsoft virtual machine (Microsoft VM). Read this chapter to learn how this security feature can help protect access to information in your organization.

Note Windows Update Setup for Internet Explorer 6 and Internet Tools does not install Microsoft VM. However, if users attempt to run an applet that requires Microsoft VM, the Internet Explorer Install On Demand feature prompts users to download the program. Users can also obtain the latest version of Microsoft VM from the Microsoft Technologies for Java Web site at http://www.microsoft.com/mscorp/java/ and the Microsoft Update Web site at http://update.microsoft.com/microsoftupdate/. If you want to include Microsoft VM as part of your custom browser packages, when you run the Internet Explorer Customization Wizard, add Microsoft VM as a custom component.

Related Information in the Resource Kit

  • For more information about Internet Explorer features that help ensure user privacy, see "Users' Privacy." 

  • For more information about planning user security before you install Internet Explorer 6 and Internet Tools, see "Planning the Deployment." 

Overview: Permission-based Security for Microsoft VM

Permission-based security for Microsoft VM (which is Java-compatible) is a Microsoft® 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 VM, 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 local files and network connections. Also, when used in conjunction with security zones, permission-based security for Microsoft VM can simplify security decisions, because it enables you to specify sets of Java permissions for each security zone.

Permission-based security for Microsoft VM 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 .cab file and the set of permissions 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. Package Manager allows classes to be installed with their associated permissions. Using Package Manager, you can also control the permissions granted to local classes, which are installed on the computer. 

  • 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 VM. For more information, see the MSDN® Web site at http://msdn.microsoft.com/ and the Microsoft Software Development Kit (SDK) for Java, which you can download from the Microsoft Technologies for Java Web site at http://www.microsoft.com/mscorp/java/.

Permission-based Security Model

The permission-based security model for Microsoft VM supports a set of permissions, with or without parameters, that can be granted or denied individually. For an applet to obtain access to the set of resources you want, such as a file's input and output, the applet must be signed with the proper permissions.

The following sets of permissions correspond to the standard Java sandbox, an area in memory outside of which the program cannot make calls:

  • Allow thread access in the context of the current execution. 

  • Open network connections to the applet host (a remote Web server) so that the applet can communicate with the host and download additional files, as necessary. 

  • Create a top-level pop-up window with a warning banner that indicates that the window was created from an applet. 

  • 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 a Web site, Internet Explorer checks the security settings associated with that site's security zone. For more information about security zones, see "Security Zones" in this Resource Kit.

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. You can specify the permissions separately for signed and unsigned applets. 

  • Permissions that are granted with user intervention. Microsoft VM prompts users about whether to grant these permissions to applets from the zone. 

  • Permissions that are denied. These permissions are considered harmful, and Microsoft VM automatically denies these permissions 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, Microsoft VM displays a dialog box showing a list of all the permissions and their associated risks, and prompts the user to choose 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 Microsoft VM prevents the applet from using the expanded set of permissions.

Note Microsoft VM prompts the user to confirm execution of the applet only if the applet requests more permissions than can be automatically granted for the zone. You can set up the specific permissions that Microsoft VM will automatically grant in each zone.

For more information about setting up permissions for each security zone, see "Setting Up 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 requested for the signed classes.

When the signed .cab file is downloaded, Microsoft VM examines the signature for permission information before it permits any code 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 VM uses the permissions requested in the signature, as well as the user's general security preferences, to determine whether to grant the requested access. If Microsoft VM cannot automatically grant the requested access, it displays a dialog box prompting the user to choose whether the applet should be allowed to run. If the user approves, the applet is run with the permissions that it requests. Otherwise, the applet is run in the sandbox. Because the set of permissions are fully defined and understood by Microsoft VM, 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 Internet Explorer must fully trust the ActiveX controls to run them, they are treated differently than 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.

You can sign Java code with the default capabilities of the following safety settings:

If you need closer control of the types of permissions granted to the signed code, you can also use custom permissions. These 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 SDK 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 only by trusted callers 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. The enabled permissions are determined by the permissions granted to other callers on the call stack and by whether any explicit calls have been made to the assertPermission, denyPermission, or revertPermission methods. If there are less-trusted callers on the call stack (which identifies the sequence of calls and callers when Java code is run and the different methods contained within the code call into other methods), the enabled permissions can be more restrictive than the granted permissions.

Microsoft VM follows two rules for permission scoping:

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

  • Even if a class has been granted a permission, its methods must explicitly enable that permission by using the assertPermission method whenever a caller on the call stack 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 VM 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 has not been 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 capability is especially important for JavaBeans and class libraries. It is recommended that you allow these components to reside locally and to have some expanded permissions, but not 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 appropriate permissions. The Package Manager, in coordination with the security manager in Microsoft VM, 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 (when two different applets have the same name), 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, greatly speeding 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 are still restricted to the permissions with which the application was originally signed. 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 the classes in a specific package can use. 

  • Upgrading. When a user revisits a Web page that contains a newer version of a Java package that 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 VM shields users from complicated trust decisions and reduces the number of dialog boxes to which they must respond. 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. An administrator has already made the complex decisions about which permissions to allow.

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 which system permissions it needs to provide, and a single trust dialog box can reliably present all 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.

Setting Up Java Custom Security

You can deploy Internet Explorer with the default settings, or you can configure Java custom settings, which explicitly define the Java permissions for signed and unsigned applets. The options for configuring Java custom settings are the same whether you access them from Internet Explorer 6, the Internet Explorer Customization Wizard, or the IEAK Profile Manager. For more information about using the Internet Explorer Customization Wizard and IEAK Profile Manager, see "Running the Microsoft Internet Explorer Customization Wizard" and "Keeping Programs Updated" in this Resource Kit.

Important You can configure Java custom settings only if the Microsoft VM is installed on your computer.

Configuring Java Custom Security

You can configure Java custom security by using the following methods:

  • In Internet Explorer, you can adjust security settings by using the Tools menu. 

  • You can use the Internet Explorer Customization Wizard to create custom browser packages that include Java custom settings. If you are a corporate administrator, you can also lock down these settings to prevent users from changing them. 

  • After the browser is deployed, you can use the IEAK Profile Manager to manage Java custom settings through the automatic browser-configuration feature of Internet Explorer. You can automatically push the updated security-zone settings to each user's desktop computer, enabling you to manage security policy dynamically across all computers on the network. 

The following procedure describes how to configure Java custom settings in Internet Explorer.

To configure Java custom settings

  1. On the Tools menu, click Internet Options

  2. Click the Security tab. 

  3. Click a security zone. 

  4. Click Custom Level. 

    To control the permissions that are granted to Java applets when they are downloaded and run in the selected zone, in the Java Permissions area, select one of the following security levels:

    • Custom, which controls permissions settings individually. 

    • Disable Java, which prevents any applets from running. 

    • High Safety, which enables applets to run in their sandbox. 

    • Low Safety, which enables applets to perform all operations. 

    • Medium Safety, which enables applets to run in their sandbox. In addition, applets are given other capabilities such as access to scratch space and user-controlled file input and output. 

    Note These options control the maximum permission level silently granted to signed applets that are downloaded from the zone. Also, they control the permissions granted to unsigned applets that are downloaded from the zone and to scripts on pages in the zone that call into applets. If a Java applet is downloaded from a different site than the page on which it is used, the more restrictive of the two sites' zone settings is applied. For example, if a user views a Web page within a zone that is set to allow a download, but the code is downloaded from another zone that is set to prompt a user first, Internet Explorer uses the prompt setting. 

  5. If you selected Custom in Step 5, click Java Custom Settings

    As necessary, perform the following tasks:

    • To view Java permissions, click the View Permissions tab. 

    This tab displays permissions in a hierarchical tree that you can expand and collapse. Permissions are organized into the following categories: 

    Permissions Given To Unsigned Content. Unsigned Java applets that request these permissions can run without user prompting. 

    Permissions That Signed Content Are Allowed. Signed Java applets that request these permissions can run without user prompting. 

    Permissions That Signed Content Are Denied. Signed Java applets are denied these permissions. 

    Dd361899.ierk701(en-us,TechNet.10).gif 

    • To edit Java permissions, click the Edit Permissions tab, and then select the options you want for more precise control of Java permissions.

    At any time, you can click the Reset button to reset the Java custom settings to the last saved permissions or to the default high, medium, or low security settings. 

    Dd361899.ierk702(en-us,TechNet.10).gif 

Selecting Java Custom Settings

The Java Custom Settings button on the Security tab gives you additional control over Java permissions. You can enable or disable specific Java permissions depending on the needs of your organization and its users.

Java custom settings for Internet Explorer are divided into two groups: Unsigned Content and Signed Content. The following tables identify the default value for each option based on the level of security.

Unsigned Content 

Java custom option

High security

Medium security

Low security

 
 
 
 

Run Unsigned Content


Run Unsigned Content

Run in sandbox

Run in sandbox

Run in sandbox


Additional Unsigned Permissions


Access to all Files

Disable

Disable

Disable

Access to all Network Addresses

Disable

Disable

Disable

Execute

Disable

Disable

Disable

Dialogs

Disable

Disable

Disable


Additional Unsigned Permissions


System Information

Disable

Disable

Disable

Printing

Disable

Disable

Disable

Protected Scratch Space

Disable

Disable

Disable

User Selected File Access

Disable

Disable

Disable


Signed Content 

Java custom option

High security

Medium security

Low security


Run Signed Content


Run Unsigned Content

Prompt

Prompt

Prompt


Additional Signed Permissions


Access to all Files

Prompt

Prompt

Disable

Access to all Network Addresses

Prompt

Prompt

Disable

Execute

Prompt

Prompt

Disable

Printing

Prompt

Prompt

Disable

Protected Scratch Space

Prompt

Enable

Disable

User Selected File Access

Prompt

Enable

Disable


The following sections describe the settings for the Unsigned Content and Signed Content groups.

Unsigned Content

The Run Unsigned Content group determines whether unsigned applets can run in the zone. This group has the following settings:

  • Run in sandbox. Runs unsigned Java applets for this zone in a Java sandbox that you specify. You can enable or disable individual options in the Additional Unsigned Permissions category. 

  • Disable. Disables running unsigned applets for this zone. Internet Explorer disables all options in the Additional Unsigned Permissions category. 

  • Enable. Enables running unsigned applets for this zone. Internet Explorer enables all options in the Additional Unsigned Permissions category. 

The Additional Unsigned Permissions options determine whether unsigned applets can have additional permissions, such as access to network addresses and the ability to run other applications. You can choose to disable or enable each of these options for unsigned permissions. If you disable the ability to run unsigned content, Internet Explorer automatically disables all of these options.

For the following unsigned permissions, click Disable or Enable:

  • Access to all Files. Determines whether unsigned applets can have read access to all the files on users' systems. 

  • Access to all Network Addresses. Determines whether unsigned applets can have access to network addresses. 

  • Execute. Determines whether unsigned applets can run other applications. 

  • Dialogs. Determines whether unsigned applets can create file dialog boxes. 

  • System Information. Determines whether unsigned applets can read system properties. 

  • Printing. Determines whether unsigned applets can have access to printer resources. 

  • Protected Scratch Space. Determines whether unsigned applets can use storage space on the hard drive. 

  • User Selected File Access. Determines whether unsigned applets can have access to selected files. 

Note If you click Enable, Internet Explorer prompts users to choose whether unsigned applets can have access to selected files.

Signed Content

The Run Signed Content group determines whether users can run signed applets. This group has the following settings:

  • Prompt. Sets individual options in the Additional Signed Permissions category to Prompt. You can disable or enable each individual option. 

  • Disable. Disables running signed applets for this zone. Internet Explorer disables all options in the Additional Signed Permissions category. 

  • Enable. Enables running unsigned applets for this zone. Internet Explorer enables all options in the Additional Signed Permissions category. 

The Additional Signed Permissions options determine whether signed applets can have additional permissions, such as access to network addresses and the ability to run other applications. You can choose to prompt users about each of these options for signed permissions, or you can prevent or allow the permissions without prompting. If you disable the ability to Run Signed Content, Internet Explorer automatically disables all of these options.

For the following signed permissions, click Prompt, Disable, or Enable:

  • Access to all Files. Determines whether signed applets can have read access to all the files on the users' systems. 

  • Access to all Network Addresses. Determines whether signed applets can have access to network addresses. 

  • Execute. Determines whether signed applets can run other applications. 

  • Dialogs. Determines whether signed applets can create file dialog boxes. 

  • System Information. Determines whether signed applets can read system properties. 

  • Printing. Determines whether signed applets can have access to printer resources. 

  • Protected Scratch Space. Determines whether signed applets can use storage space on the hard disk. 

  • User Selected File Access. Determines whether signed applets can have access to selected files. 


Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.