These documentation pages are no longer current. They remain available for archival purposes. Please visithttps://docs.oracle.com/javase for the most up-to-date documentation.

Contents

• Overview
• Mixed Code Protection Options for Users
• Deploying Privileged Applications and AppletsSecurely Without a Mixed Code Warning
  • Trusted-OnlyAttribute
  • Trusted-LibraryAttribute
• Mixed Code FAQ
• For More Information

Overview

Privileged Java Web Start applications and applets that containcomponents that are restricted to the security sandbox could potentially be unsafe unlessthe mixed code was intended by the application vendor. When aprogram contains both privileged components and sandbox components, security warnings are shown.Note that JavaScript code is restricted to the sandbox and could also cause security warnings to be shown. SeeCaller-Allowable-Codebase Attribute for information on the manifest attribute for authorizing JavaScript code.

The security warnings state that Java has discovered applicationcomponents that could indicate a security concern and recommendsthat you contact the application vendor to ensure that theapplication components have not been tampered with.

In the dialog, you choose toBlock, orDon't Block execution of the applicationcomponents. You can also click the optionalMoreInformation link.

Clicking theBlock button blocks potentiallyunsafe components from running, and the program may terminate.Clicking theDon't Block button causes theapplication or applet to continue execution with some addedprotections.

Raising a warning is the default behavior, but there are optionsavailable to manage how this situation is handled.

• For users and systems administrators, various protectionoptions are available. For more information, seeMixed Code Protection Options for Users.
• For developers and deployers, two manifest attributes areavailable. For more information, seeDeployingPrivileged Applications and Applets Securely Without a Mixed CodeWarning.

---

Note: If any concepts are unclear, such as how tomodify a manifest file, or how to sign a JAR file, or how to use adeployment configuration file, seeFor MoreInformation for useful links.

---

Mixed Code Protection Options forUsers

There are two mechanisms for managing how mixed code programs arehandled.

• From the Java Control Panel

  You can manage how mixed code programs are handled via the JavaControl Panel. There are four levels of control available.

  How to access the Java Control Panel varies for each platformand sometimes varies for different releases of a platform. OnMicrosoft Windows, you can bring up the panel viaStart menu > Control Panel > Java.

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

  • Enable - show warning if needed
    This is the default setting. When a potential security risk isencountered, a warning dialog is raised. ClickingBlock blocks potentially unsafe components fromrunning and may terminate the program. When the user clicksDon't Block, the application or applet continuesexecution with some added protections (packages or resources thatare later encountered with the same names but have different levels of permissions will not be loaded).
  • Enable - hide warning and run withprotections
    This option suppresses the warning dialog. The code executes as ifthe user had clickedDon't Block from the warningdialog.
  • Enable - hide warning and don't run untrustedcode
    This option suppresses the warning dialog and behaves as if theuser had clickedBlock from the warningdialog.

  The final option,Disable verification, is notrecommended. This option completely disables the software fromchecking for a mixture of privileged code and sandbox code, leaving the user torun potentially unsafe code with no warning and without theadditional protections.

• From thedeployment.properties File

  The mixed code protection options can also be set by using thedeployment.security.mixcode deployment property, asdescribed inDeploymentConfiguration File and Properties.

  • deployment.security.mixcode=ENABLE

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

  • deployment.security.mixcode=HIDE_RUN

    This option suppresses the warning dialog. The code executes asif the user had clickedDon't Block from thewarning dialog.

  • deployment.security.mixcode=HIDE_CANCEL

    This option suppresses the warning dialog and behaves as if theuser had clickedBlock from the warningdialog.

  • deployment.security.mixcode=DISABLE

    This option is not recommended. The software is disabled fromchecking for a mixture of privileged code and sandbox code, leaving the user torun potentially unsafe code with no warning and without theadditional protections.

---

Version note: To take advantage of these securityenhancements, users need to install the Java SE or Java forBusiness 6 Update 19 release (or later) and use the new JavaPlug-in, which is enabled by default. To use an earlier JRE withthe new Java Plug-in, you need to install the Java for Business 5.0Update 24 release (or later) or the Java for Business 1.4.2_26release (or later) in order to enable the mixed code securityenhancement for those release families.
Note 1: Mixed code checking for the 1.4.2 releaseis available only for the Windows platform.
Note 2: For Solaris, the new Java Plug-in requiresFirefox 3 or later. Netscape 7 and Firefox 2 are notsupported.
Note 3: For more information on which platformsare supported by the new plug-in, see theRelease Notes for the Next-Generation JavaPlug-in.

---

Deploying Privileged Applicationsand Applets Securely Without a Mixed Code Warning

This section describes best practices for developers anddeployers to protect their applications and applets from beingmaliciously re-purposed by replacing trusted components withuntrusted ones.

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

Developers and deployers should check their Java WebStart applications and applets to determine if they mix privileged code anduntrusted code. If users of these applications and applets mayinadvertently download these applications and applets from roguewebsites, deploying or re-deploying with one of the followingattributes should be considered. Existing signed JARs need to bere-signed after adding these manifest attributes. Note:source code of the classes and resources are not required forre-signing with the manifest entries.

Trusted-Only Attribute

For applications and applets that do not require untrustedcomponents, use theTrusted-Only attribute.No warning dialog is displayed and an application or appletthat loads a JAR file containing this attribute does not load anyuntrusted classes or resources. This attribute prevents a privilegedapplication or applet from being re-purposed with untrustedcomponents. SeeTrusted-Only Attribute for more information.

Trusted-Library Attribute

For applications and applets that are designed to allow untrustedcomponents, use theTrusted-Library attribute. No warning dialog is shown and an application orapplet can load JAR files containing untrusted classes orresources. This attribute prevents components in a privileged application or applet from being re-purposed with untrustedcomponents. SeeTrusted-Library Attribute for more information about using this attribute.

TheTrusted-Library attribute is used for calls between privileged Java code and sandbox Java code. If you have JavaScript code that calls Java code, use theCaller-Allowable-Codebase Attribute.

Mixed Code FAQ

• Question: I develop and/or deployapplications. How do I know whether I need to be concerned aboutthis issue?

  Answer: If you do not use themanifest entries and you encounter the warningdialog when running your privileged application or applet, your programcontains mixed code and is affected.

• Question:Is there a test I can run to determine whether I am affected?

  Answer: Test your Java Web Start applicationsand Java applets against Java SE or Java for Business 6 Update 19or later. If you are running earlier release families, you shouldadditionally install and test your program under 5.0 Update 24 (orlater), or 1.4.2_26 (or later), as appropriate. If you see thewarning dialog, then the Java Web Start application or appletcontains mixed code.

• Question: What actions can I take?

  Answer: End users can click the "MoreInformation" link before deciding whether to click "Block" or"Don't Block" in response to the warning dialog. IT or SystemAdministrators can choose from one of the Mixed Code protectionoptions and configure enterprise desktops through the respectivedeployment properties described above. Developers and deployers canuse the manifest entries to protect their applications fromtampering. No warning dialog will be displayed when one of thesemanifest entries is used.

• Question: What should Java ISVs, OEMs, andapplication vendors do with their code?

  Answer: Twomanifestentries are available to application vendors to deploy, orre-deploy, their Java Web Start applications and Java applets.

• Question:What versions of Java SE and Java forBusiness are affected?

  Answer: The following releases from Oracle areaffected:

  • Java SE and Java for Business 6 Update 18 and earlier
  • Java for Business 5.0 Update 23 and earlier
  • Java for Business 1.4.2_25 and earlier
• Question:What about Java applets and Java Web Start applications from theInternet, do I need to be concerned about those?

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

• Question: What if I am behind a corporatefirewall?

  Answer: The mixed code issue applies. See thequestion on applets and applications fromthe Internet.

• Question: Is this an issue for Oracle JRockit?

  Answer: No.

• Question: I am using an implementation of Javafrom another vendor. Are they affected in the same way?

  Answer: Please contact your vendor for adviceon their implementation.

• Question: What are the risks to remaining onJava SE 6u18 (or earlier) to avoid seeing the warnings?

  Answer: Java SE 6 Update 19 (or later) containsthe latest security fixes and Oracle recommends that customers usethe latest release.

• Question: If I move to 6 Update 19 or later,what type of testing do I need to consider?

  Answer: See thequestionon testing. In addition, the release notes for each update releasedocuments the latest changes included.

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

  Answer: The followingSecurityException messages are described forinformational and debugging purposes only. The actual messagecontents may change between different implementations andreleases.

  TheseSecurityExceptions are thrown when a JAR filecontains one of the manifest attributes and the JAR file itselfcontains untrusted components.

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

  The followingSecurityException is thrown when a JARfile contains theTrusted-Only manifest attributeand untrusted components have previously been accessed.

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

  The followingSecurityException is thrown when atleast one JAR containing theTrusted-Only manifestattribute has been opened and a subsequent attempt is made to loadan untrusted component.

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

  The following twoSecurityExceptions are thrown whenmixed components are first detected and a decision is made todisallow mixing. In the first case, everything previously loaded wastrusted and then an attempt was made to load an untrustedcomponent. 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 twoSecurityExceptions are thrown aftermixed components had previously been detected and a decision wasmade to allow them to coexist. The exceptions indicate that acomponent name collision (resource name or class package name) wasdetected between trusted and untrusted components and the requestto 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 twoSecurityExceptions are thrown whenuntrusted components have been previously accessed, an attempt toload a trusted component was previously detected, and a decisionwas made to allow mixed components to coexist, and a JAR containingtrusted components is opened and a component name collision isdetected between trusted and untrusted components.

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

• Question: I have a mixed code Java Web Startapplication which cannot be easily updated to use theTrusted-Library manifest attribute. Can I sign the JARfiles in the sandboxed JNLP without having to change the JNLP torequest theall-permissions security model?

  Answer: Yes, with some limitations beginningwith Java Web Start in Java SE or Java for Business Update 21. Thesandboxed JAR files must be signed in the same way (same signingcertificates) as one or more of the trusted JAR files in a JNLPfile that uses theall-permissions security model, andthe trusted JAR file must be opened by Java Web Start prior to anysandboxed resource being loaded which shares the same signer. Thismeans the trusted JAR file must be earlier in Java Web Start's JARsearch order or it is triggered to load independent of the simplesearch order by use of the JAR indexing feature. In Java Web Start,the main application JNLP's JARs are searched first, followed indeclaration order by any JNLP extensions. JAR files labeled withina JNLP as "eager" are searched first, followed by "lazy" JAR files,followed by any JAR files labeled as using the "part" feature.

• Question: I have Java on my phone. Is thataffected by this issue?

  Answer: No, Java ME is not affected.

For More Information

• JAR File Manifest Attributes for Security
• Secure Coding Guidelines for Java
• DeploymentConfiguration File and Properties
• Modifying a Manifest File, a section inThe Java Tutorial, has information on how to work withmanifest files.
• Signing JAR Files, a section inThe JavaTutorial.

©2009-2025 Movatter.jp