JAR File Manifest Attributes for Security (original) (raw)

The JAR file manifest contains information about the contents of the JAR file, including security and configuration information. Use the manifest attributes described in this section to enhance the security of running Rich Internet Applications (RIAs) from a browser.

The attributes must be added to the manifest before the JAR file is signed. See Modifying a Manifest File in the Java Tutorial for information on adding attributes to the JAR manifest file.

26.3 Application-Name Attribute

The Application-Name attribute provides a title for your signed RIA. The title of a RIA is used in security prompts when the user is prompted for permission to run the RIA. A meaningful title helps users make the decision to trust and run the RIA. The value can be any valid string, for example:

Application-Name: Hello World

If the RIA has an unsigned JNLP file or is started with the applet tag in a web page, use the Application-Name attribute to ensure that users are shown a valid title from a signed source. If the Application-Name attribute is not present in the JAR file manifest, a warning is written to the Java Console and the value for the Main-Class attribute is used. If neither attribute is present in the manifest, no title is shown in the security prompts.

If a RIA has a signed JNLP file, the title shown in the security prompts is taken from the title element in the JNLP file. The Application-Name attribute is ignored.

Titles are not shown for unsigned RIAs.

26.6 Entry-Point Attribute

The Entry-Point attribute is used to identify the classes that are allowed to be used as entry points to your RIA. Identifying the entry points helps to prevent unauthorized code from being run when a JAR file has more than one class with a main() method, multiple Applet classes, or multiple JavaFX Application classes. Set this attribute to the fully qualified class name that can be used as the entry point for the RIA. To specify more than one class, separate the classes by a space, for example:

Entry-Point: apps.test.TestUI apps.test.TestCLI

If the JAR manifest is signed and the main-class or applet-class entry point specified in the JNLP file or application descriptor differs from the class specified for the Entry-Point attribute, then the RIA is blocked. If the Entry-Point attribute is not present, any class with a main() method, or any Applet or JavaFX Application class in the JAR file can be used to start your RIA.

26.8 Trusted-Library Attribute

The Trusted-Library attribute is used for applications and applets that are designed to allow untrusted components. No warning dialog is shown and an application or applet can load JAR files that contain untrusted classes or resources. Set the value of the attribute to true, for example:

Trusted-Library: true

This attribute prevents components in a privileged application or applet from being repurposed with untrusted components. All classes and resources in a JAR file containing this manifest attribute must be signed and request all permissions.

In a mixed code application or applet, all privileged classes and resources must be included in JAR files that contain the Trusted-Library attribute. This attribute is used for calls between privileged Java code sandbox Java code. If you have JavaScript code that calls Java code, see Caller-Allowable-Codebase Attribute.

All trusted library JARs are loaded into a separate dedicated class loader that is unique to the application or applet instance. This Trusted-Library loader is now the parent of the normal Web Start or applet class loader. For backwards compatibility with the original search order, both loaders cooperate to implement a common class path. Consistent with prior releases, JAR files use lazy download and are opened as needed to find requested classes and resources.

Code in a JAR file that is to be marked with the Trusted-Library manifest attribute may need to be modified slightly if it uses calls that are class loader dependent, such as the single parameter version of Class.forName(), Class.getResource(), and Class.getResourceAsStream(), some variants of java.util.ResourceBundle.getBundle(), and any other methods that operate relative to their immediate caller's defining loader. Changes only need to be made if the requested class or resource might be found in a JAR file that is not a Trusted-Library (and is therefore loaded by the normal Web Start or applet class loader).

Code in a Trusted-Library can look up the normal loader by invoking Thread.currentThread().getContextClassLoader(). Note, however, that there are uncommon circumstances in which getContextClassLoader() may return null. For example, this may happen when the garbage collector uses a JRE system thread to invoke the Object.finalize() method of an unreachable instance.

If you need to convert class to Class.getResource() or Class.getResourceAsStream() to their ClassLoader equivalents, remember to adjust the string parameter as described by the documentation for those two methods. If the original resource name began with '/', then it was an absolute name and the leading '/' simply needs to be removed. Otherwise, determine if the class instance which was the target of the getResource call is in a named package. If it is an array you should first determine the underlying component type of the array. Invoke Class.getName() on the class or component type instance. If the class name contains any '.' characters, it is in a named package that will need to be prepended to the original resource name. Determine the package name by removing any characters after, and including, the trailing '.' character. Next, replace any remaining '.' characters with '/' characters. Finally, add a trailing '/' and append the original resource name string. This new string can now be passed to the ClassLoader version of the getResource() or getResourceAsStream() methods.

Generally, care must be taken to ensure that the code in the trusted library is written in a careful and secure manner and is otherwise compatible with being loaded in a separate class loader instance from any remaining jars that are part of the application and are loaded by the normal loader.

26.9 Preventing RIAs from Being Repurposed

The Permissions attribute and the Codebase attribute were introduced in the JDK 7u25 release to defend RIAs against unauthorized code repurposing.

Without the Permissions attribute, it might be possible for an attacker to exploit a user by re-deploying an application that is signed with your certificate, and running the application at a different privilege level.

If the Codebase attribute does not specify a secure server, such as HTTPS, some risk exists that your code could be repurposed in Man-in-the-Middle (MITM) attack schemes.

The following code example shows the attributes to add to the manifest if you have a RIA that runs in the security sandbox and is expected to be accessed from https://example.com:

Permissions: sandbox Codebase: https://example.com

If the RIA is also available from example.backup.com:8080, include both domains for the Codebase attribute:

Codebase: https://example.com example.backup.com:8080