Chapter 4: Lock Down Security
IT professionals have the option of using Internet Explorer (IE) security settings to disable or restrict the applicability of the MSJVM. Locking down security rather than migrating to another solution allows the MSJVM to stay on some machines. This is a viable option for internal applications that are dependant on the MSJVM, but are not intended for public use. This security policy can be deployed to an organization as a Group Policy with Active Directory. However, if your organization currently does not utilize Active Directory, it will be necessary to make the appropriate adjustments on each client desktop.
This option reduces, but does not completely eliminate, security concerns with respect to the MSJVM. The optimal method for eliminating security concerns is to completely remove the MSJVM and dependencies, rather than limiting the execution of the MSJVM.
.gif)
On This Page
.gif){kind=icon}
Locking Down Internet Explorer
Pointing to the MSJVM
Locking Down Internet Explorer
In Internet Explorer, from the Tools menu, select Internet Options and then the Security Settings tab to disable the MSJVM. To turn off Java for the Internet zone, select the Custom Settings button. In the Microsoft VM section, under Java Permissions, select Disable Java. These settings are stored in the registry for the current user; they can be stored as a .reg file and propagated throughout an organization through a login script that loads the .reg file. On a machine with multiple user accounts, these changes will have to be done separately for each account. You should note that if you have installed Sun’s Java plug-In for Windows on your system, this option also impacts the Sun JRE, which “impersonates” the MSJVM in IE.
A second possibility for customers who continue using the MSJVM is to reduce security issues by limiting the use of Java to specific sites. After turning off Java in the Internet zone, they can turn on Java for all trusted sites and then re-enable support for applets by adding the specific sites with the applets to their Trusted Sites list.
Pointing to the MSJVM
An option when locking down the availability of the MSJVM to only secure and trusted sites is to install a second JRE. A second JRE allows applications that support multiple JREs, and may allow applets and applications without MSJVM-specific dependencies, to continue running. Test all JREs sufficiently during implementation to ensure the applications work properly with the newly installed JRE.
There are additional considerations if you are planning to install a second JRE on some machines that are locked down. For example, some JRE vendors provide a configuration item that allows you to specify one JRE to run <OBJECT> tags and another JRE to run <APPLET> tags. Refer to the documentation associated with your JRE to determine how to configure tag handling.
The IE Security Zone settings specified applies to all <APPLET> tags. You can edit the Web files to use the <OBJECT> tag instead of the <APPLET> tag. The <OBJECT> tag is a more generic tag for embedded objects, including applets.
The structures of the two tags are similar:
<APPLET code=Applet1.class height=200 width=320 name=Applet1 VIEWASTEXT> <PARAM NAME="foreground" Value="FFFFFF"> <PARAM NAME="background" Value="008080"> <PARAM NAME="label" Value="This string was passed from the HTML host."> No applet tag handlers installed. </APPLET>
In the <OBJECT> tag, some attributes have become parameters (to avoid namespace conflicts), and there are additional parameters because the <OBJECT> tag is more generic:
<OBJECT CLASSID="clsid:08B0E5C0-4FCB-11CF-AAA5-00401C608501" height=200 width=320 VIEWASTEXT> <PARAM NAME="code" Value="Applet1.class"> <PARAM NAME="type" Value="application/x-java-applet"> <PARAM NAME="scriptable" Value="true"> <PARAM NAME="foreground" Value="FFFFFF"> <PARAM NAME="background" Value="008080"> <PARAM NAME="label" Value="This string was passed from the HTML host."> No Microsoft VM installed </OBJECT>
The classid attribute is a URI that can indicate inline data. For an Active X control — and a JRE is considered an Active X control — the URI begins with “clsid” and is followed by the clsid value in the registry. The value 08B0E5C0-4FCB-11CF-AAA5-00401C608501 indicates the MSJVM; different versions of third-party JREs may use different numbers. Some Java plug-ins install on a Windows system by “impersonating” the MSJVM using the same registry entry and class ID on installation. Be cautious when installing JREs that impersonate the MSJVM, as you may need to configure the CLSID or the individual JREs to make sure the desired one loads.
If you are determined to point to a particular JRE in some circumstances, you may run into a second problem. As of this writing, at least one JRE installs a subkey under the key that identifies the MSJVM. The following key has as its default value the CLSID of the new JRE:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{08B0E5C0-4FCB-11CF-AAA5-00401C608501}\TreatAs.
Attempting to explicitly load the MSJVM through the <OBJECT> tag when this key exists will actually load the new JRE. Deleting the subkey will solve this problem.