27.1 Mixed Code Protection Options for Users

Two mechanisms are available for managing how mixed code programs are handled:

• From the Java Control Panel

  You can manage how mixed code programs are handled via the Java Control Panel. Four levels of control are available.

  How to access the Java Control Panel varies for each platform and sometimes varies for different releases of a platform. On Microsoft Windows, you can bring up the panel via Start menu > Control Panel > Java.

  In the Mixed Code section of the Advanced Tab, the first three options enable the software protections, but behave a bit differently.

  • Enable - show warning if neededThis is the default setting. When a potential security risk is encountered, a warning dialog is raised. Clicking Block blocks potentially unsafe components from running and may terminate the program. When the user clicks Don't Block, the application or applet continues execution with some added protections (packages or resources that are later encountered with the same names but have different levels of permissions will not be loaded).

  • Enable - hide warning and run with protectionsThis option suppresses the warning dialog. The code executes as if the user had clicked Don't Block from the warning dialog.

  • Enable - hide warning and don't run untrusted codeThis option suppresses the warning dialog and behaves as if the user had clicked Block from the warning dialog.

  The final option, Disable verification, is not recommended. This option completely disables the software from checking for a mixture of privileged code and sandbox code, leaving the user to run potentially unsafe code with no warning and without the additional protections.

• From the deployment.properties file

  The mixed code protection options can also be set by using the deployment.security.mixcode deployment property, as described in Chapter 21, "Deployment Configuration File and Properties."

  • deployment.security.mixcode=ENABLE

    This option enables mixed code verification. When a potential security risk is encountered, a warning dialog is raised. This is the default value for this property.

  • deployment.security.mixcode=HIDE_RUN

    This option suppresses the warning dialog. The code executes as if the user had clicked Don't Block from the warning dialog.

  • deployment.security.mixcode=HIDE_CANCEL

    This option suppresses the warning dialog and behaves as if the user had clicked Block from the warning dialog.

  • deployment.security.mixcode=DISABLE

    This option is not recommended. The software is disabled from checking for a mixture of privileged code and sandbox code, leaving the user to run potentially unsafe code with no warning and without the additional protections.

27.2 Deploying Privileged Applications and Applets Securely Without a Mixed Code Warning

This section describes best practices for developers and deployers to protect their Java Web Start applications and applets from being maliciously re-purposed by replacing trusted components with untrusted ones.

Two JAR manifest attributes are available, as of Java SE 6 Update 19, for deploying privileged Java Web Start applications and applets. A warning dialog is not displayed when one of these manifest attributes is included.

Developers and deployers should check their Java Web Start applications and applets to determine if they mix privileged code and untrusted code. If users of these applications and applets may inadvertently download these applications and applets from rogue websites, deploying or re-deploying with one of the following attributes should be considered. Existing signed JARs need to be re-signed after adding these manifest attributes. Source code of the classes and resources are not required for re-signing with the manifest entries.

27.3 Mixed Code FAQ

I develop or deploy applications. How do I know if I need to be concerned about this issue?

Answer: If you do not use the manifest attributes described in Section 27.2, "Deploying Privileged Applications and Applets Securely Without a Mixed Code Warning" and you encounter the warning dialog when running your privileged Java Web Start application or applet, your program contains mixed code and is affected.

Is there a test I can run to determine if I am affected?

Answer: Test your applets and Java Web Start applications using the latest version of the JRE. If you see the warning dialog, then the application contains mixed code.

What actions can I take?

Answer: End users can click the More Information link before deciding whether to click Block or Don't Block in response to the warning dialog. IT or System Administrators can choose from one of the Mixed Code protection options and configure enterprise desktops through the respective deployment properties described above. Developers and deployers can use the manifest entries to protect their applications from tampering. No warning dialog is displayed when one of these manifest entries is used.

What should Java ISVs, OEMs, and application vendors do with their code?

Answer: Two manifest attributes, described in Section 27.2, "Deploying Privileged Applications and Applets Securely Without a Mixed Code Warning," are available to application vendors to deploy, or re-deploy, their Java Web Start applications and Java applets.

What about Java applets and Java Web Start applications from the Internet, do I need to be concerned about those?

Answer: Users will see a warning dialog if a Java Web Start application or Java applet contains mixed code regardless of whether it is downloaded from the Internet or Intranet.

What if I am behind a corporate firewall?

Answer: The mixed code issue applies. See the question "What about Java applets and Java Web Start applications from the Internet, do I need to be concerned about those?."

Is this an issue for Oracle JRockit?

Answer: No.

I am using an implementation of Java from another vendor. Are they affected in the same way?

Answer: Contact your vendor for advice on their implementation.

I am a developer. What are the security exceptions that are added with this enhancement?

Answer: The following SecurityException messages are described for informational and debugging purposes only. The actual message contents may change between different implementations and releases.

These SecurityExceptions are thrown when a JAR file contains one of the manifest attributes and the JAR file itself contains untrusted components.

attempted to open sandboxed jar "+ url +" as Trusted-Only
attempted to open sandboxed jar "+ url +" as Trusted-Library

The following SecurityException is thrown when a JAR file contains the Trusted-Only manifest attribute and untrusted components have previously been accessed.

attempted to open Trusted-Only jar "+ url +" on sandboxed loader

The following SecurityException is thrown when at least one JAR containing the Trusted-Only manifest attribute has been opened and a subsequent attempt is made to load an untrusted component.

Trusted-Only loader attempted to load sandboxed resource from "+ url"

The following two SecurityExceptions are thrown when mixed components are first detected and a decision is made to disallow mixing. In the first case, everything previously loaded was trusted and then an attempt was made to load an untrusted component. The second case is the reverse condition.

trusted loader attempted to load sandboxed resource from "+ url"
sandboxed loader attempted to load trusted resource from "+ url"

The following two SecurityExceptions are thrown after mixed components had previously been detected and a decision was made to allow them to coexist. The exceptions indicate that a component name collision (resource name or class package name) was detected between trusted and untrusted components and the request to load the resource or class was denied.

"resource \"" + name + "\" does not match trust level of other resources of the same name"
"class \"" + packageName + "\" does not match trust level of other classes in the same package"

The following two SecurityExceptions are thrown when untrusted components have been previously accessed, an attempt to load a trusted component was previously detected, and a decision was made to allow mixed components to coexist, and a JAR containing trusted components is opened and a component name collision is detected between trusted and untrusted components.

"untrusted resource \"" + name + "\" in class path"
"untrusted class package \"" + packageName + "\" in class path"

I have a mixed code Java Web Start application which cannot be easily updated to use the Trusted-Library manifest attribute. Can I sign the JAR files in the sandboxed JNLP without having to change the JNLP to request the all-permissions security model?

Answer: Yes, with some limitations. The sandboxed JAR files must be signed with the same signing certificates as one or more of the trusted JAR files in a JNLP file that uses the all-permissions security model, and the trusted JAR file must be opened by Java Web Start prior to any sandboxed resource being loaded that shares the same signer. This means the trusted JAR file must be earlier in Java Web Start's JAR search order or it is triggered to load independent of the simple search order by use of the JAR indexing feature. In Java Web Start, the main application JNLP's JARs are searched first, followed in declaration order by any JNLP extensions. JAR files labeled within a JNLP as "eager" are searched first, followed by "lazy" JAR files, followed by any JAR files labeled as using the "part" feature.

I have Java on my phone. Is that affected by this issue?

Answer: No, Java ME is not affected.

27.4 For More Information

• Chapter 26, "JAR File Manifest Attributes for Security"

• Secure Coding Guidelines for Java

• Chapter 21, "Deployment Configuration File and Properties"

• Modifying a Manifest File, a section in The Java Tutorial, has information on how to work with manifest files.

• Signing JAR Files, a section in The Java Tutorial.