Oracle Blog

SecuritEE

Friday May 11, 2012

Some Java EE applications require specific Java SE Permissions to be granted to them for them to operate properly in the deployed environment.

At the same time, it is imperative that system administrators be able to configure their installations in such a way as to best protect the installation and operating environment. Emerging deployment scenarios within the cloud as well as traditional enterprise deployments may have various levels of needed restriction based on different levels of trusted code and sensitivity of resources.

In order to meet the needs of applications requiring specific permission grants it has been common to have to add statements to policy files within the installation to grant permissions to the appropriate codebase and restart the application server.

While this puts the control of the permission grants in the hands of the system administrator and ensures that specific action is taken in order to have these permissions granted to the applications, it is a tedious and error prone task. Applications have had no standard way to communicate their requirements for such permissions and are often run in development environments that are not running with security manager enabled or with AllPermission being granted to all codebases. Once they are staged in a new environment with security manager enabled, attempts to access protected resources cause runtime failures or worse, code paths that would cause runtime failures aren't executed until later in testing or even production environments.

Consider the PaaS/cloud environment now. Such manual granting of certain permissions for specific applications would never work. In addition, granting overarching permission sets to all applications would be ill advised and a violation of the principle of least privilege (http://en.wikipedia.org/wiki/Principle_of_least_privilege). Application deployers would potentially need to know how to describe the permissions required for an application in the management pages of a PaaS provider's offering. They would have to know how to do this in the offering of any other current or future providers as well.

How can we communicate an application's need for specific permissions in a standard manner and, at the same time, retain the system administrator's flexibility to secure the Java EE installation to meet the needs of the enterprise or cloud provider's security policies?

Enter the Champion: Permission Declarations Appear

By extending the metadata provided with an application to declare the specific permissions required by that application, the deployment machinery of an application server can assess the declarations within the context of the installation configuration. Application servers may provide configuration that limits the granting of certain permissions based on the level of trusted code to deployed to the installation or the sensitivity of the resources available to the server instance, etc.

The processing of the declarations, as described in the proposed specification changes, requires deployment of the application to fail when its declared permissions include permissions that are in violation of the security policy for the installation. It also requires that all declared permissions be granted to applications that successfully deploy to the environment.

This mechanism will now provide the application developer the means to declare the application's need for specific permission grants without involving the system administrator, without the deployer having to learn policy configuration pages, without the PaaS provider having to make such pages available and still retain the system administrator's control over the installation policy and what permissions are granted to applications.

The fact that the declarations are provided within the context of an application affords us the ability to simplify the syntax. We don't need to specify the codebase of the grant since it is implied the declaration's residence inside the application archive.

A simple xml descriptor to represent the declaration should look like something along the lines of:

Listing 1. permissions.xml example

<?xml version="1.0" encoding="UTF-8"?>

<permissions>

<permission>

<classname>java.io.FilePermission</classname>

<name>/tmp/abc</name>

<actions>read,write</actions>

</permission>

<permission>

<classname>java.lang.RuntimePermission</classname>

<name>createClassLoader</name>

</permission>

</permissions>

It has been suggested that it may make sense to add a description to the declaration as well. Tooling and management pages would then be able to display more context around the application's need for the permission. This may be helpful when there is a need for manual intervention for resolving grants by the administrator or deployer.

Applications that do not bundle a permissions.xml file are fully backward compatible and any permissions that are required by the application are subject to the security policy of the installation. The security policy may or may not grant all of the permissions required by a given application. There is however a baseline set of permissions that are guaranteed to be able to be configured as the default permission set for any Java EE product.

Again, these permissions are guaranteed to be available to applications given an installation's security policy that allows them.

The best way for applications to know for sure whether their required permissions are granted will be by declaring them through permissions.xml. Doing so will let the deployer know through their ability to successfully deploy the application.

Permission declarations will be a great enhancement to the programming model and administration of security policy for Java EE applications. Using this feature will provide the earliest indication that a required permission has not been granted and make for a better experience for developers, deployers, admins and end users.