Share via

Internet Explorer security setting, "Java Permissions: Disable Java"

  • Article

[Authors: Aaron Margosis and Shelly Bird]

We recently noted in testing some problems with the Disable Java setting. 

We had stated in a recent FDCC LiveMeeting that the "Java Permissions/Disable Java" IE security zone settings only apply to the Microsoft Java Virtual Machine (MSJVM).  Our testing at larger enterprises did seem to confirm this:  numerous Java applications, running with various versions of Sun JRE, were running without errors, with this setting turned on. 

However, deeper examination of application compatibility issues with some Line of Business applications at other customers sites have shown that under certain circumstances, customers will see non-Microsoft Java runtime engines affected by this setting.  These failures do not appear to be common, and do seem to be limited to just a few applications; however, everyone should be aware of exactly how and when this setting could have impact.

To give some background on this, FDCC applies an "Enabled: Disable Java" setting on every single Internet Explorer Security Zone, including Intranet and Trusted Sites.  For example, it is set at this location in policy:

Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone\Java Permissions

In Group Policy Editor, when you navigate to these settings, you see the choices listed below:

Java Permissions properties dialog

The various "Java Permissions" settings were designed primarily to control the behavior of the Microsoft JVM.  To our knowledge, only the Microsoft implementation of Java ever adjusted its behavior based on the "safety" level or the more granular Custom permissions assigned to the security zone in which an applet was running.  This is why many of us believed that the "Java Permissions" setting only ever impacted MSJVM.  Most likely, the reason that "Disable Java" was configured across the board in the FDCC was specifically to prevent further use of the MSJVM, which is no longer supported and is not included in any shipping Microsoft products.

However, the "Disable Java" option is actually enforced by Internet Explorer, not the MSJVM, by blocking the use of the <APPLET> element in HTML.  The <APPLET> element is one of several available ways to run Java code within a web page.  There are other HTML elements that can be used instead, and that are not affected by the "Java Permissions" setting.  This explains why many Java apps have continued to work with "Disable Java" enabled.

The symptom of a failure will be the following error message in the Internet Explorer Information Bar:

Your security settings do not allow websites to use ActiveX controls installed on your computer. This page may not display correctly. Click here for options…

Switching the "Java Permissions" setting to anything other than "Enabled: Disable Java" allows the page to load.  In these situations, we suggest switching the "Java Permissions" settings in the Local Intranet and Trusted Sites zones from "Disable Java" to "High Safety".  This will allow the full use of non-Microsoft Java implementations in IE for those zones, while restricting any lingering MSJVM use as much as possible.  Report this change as a necessary variance to NIST.  (This link describes the effects of the various "Java permissions" settings on the MSJVM:  https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/ierk/Ch07_e.mspx.  Note that customers are strongly encouraged to identify and eliminate any remaining dependencies on the MSJVM.)

If you have control over the HTML that is used to invoke the Java applet, another option is to change the HTML not to use the <APPLET> element.  Documentation on these other techniques is available here:  https://java.sun.com/docs/books/tutorial/deployment/applet/deployindex.html

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://javanet.agendamilano.info/?p=1796

  • Anonymous
    January 01, 2003
    Part 2 of a series on the intersection of Internet Explorer 7 and application of security guidance (e.g., the US Federal Desktop Core Configuration). This part talks about the impact of locked-down configurations on typical non-admin end users.

  • Anonymous
    January 16, 2013
    The comment has been removed