JBoss Enterprise Application Platform 7 allows the definition of Java Security Policies per application. The way it’s implemented means that we’ll also be able to define security policies per module, in addition to define one per application. The ability to apply the Java Security Manager per application, or per module in EAP 7, makes it a versatile tool in the mitigation of serious security issues, or useful for applications with strict security requirements.

The main difference between EAP 6, and 7 is that EAP 7 implements the Java Enterprise Edition 7 specification. Part of that specification is the ability to add Java Security Manager permissions per application. How that works in practice is that the Application Server defines a minimum set of policies that need to be enforced, as well as a maximum set of policies that an application is allowed to grant to itself.

Let’s say we have a web application which wants to read Java System Properties. For example:

System.getProperty("java.home");

If you ran with the Security Manager enabled, this call would throw an AccessControlException. In order to enable the security manager, start JBoss EAP 7 with the option -secmgr, or set SECMGR to true in standalone, or domain configuration files.

Now if you added the following permissions.xml file to the META-INF folder in the application archive, you could grant permissions for the Java System Property call:

Add to META-INF/permissions.xml of application:

<permissions ..>
        <permission>
                <class-name>java.util.PropertyPermission</class-name>
                <name>*</name>
                <actions>read,write</actions>
        </permission>
</permissions>

The Wildfly Security Manager in EAP 7 also provides some extra methods for doing privileged actions. Privileged actions are ones that won’t trigger a security check. However in order to use these methods, the application will need to declare a dependency on the Wildfly Security Manager. These methods can be used by developers instead of the built in PrivilegedActions in order to improve the performance of the security checks. There are a few of these optimized methods:

• getPropertyPrivileged
• getClassLoaderPrivileged
• getCurrentContextClassLoaderPrivileged
• getSystemEnvironmentPrivileged

For more information about custom features built into the Wildlfy Security Manager, see this presentation slide deck by David Lloyd.

Out of the box EAP 7 ships with a minimum, and maximum policy like so:

$EAP_HOME/standalone/configuration/standalone.xml:

<subsystem xmlns="urn:jboss:domain:security-manager:1.0">
    <deployment-permissions>
        <maximum-set>
            <permission class="java.security.AllPermission"/>
        </maximum-set>
    </deployment-permissions>
</subsystem>

That doesn’t enforce any particular permissions on applications, and grants them AllPermissions if they don’t define their own. If an administrator wanted to grant at least permissions to read System Properties to all applications then they could add this policy:

$EAP_HOME/standalone/configuration/standalone.xml:

<subsystem xmlns="urn:jboss:domain:security-manager:1.0">
    <deployment-permissions>
        <minimum-set>
            <permission class="java.util.PropertyPermission" name="*" actions="read,write"/>
        </minimum-set>
        <maximum-set>
            <permission class="java.security.AllPermission"/>
        </maximum-set>
    </deployment-permissions>
</subsystem>

Alternatively if they wanted to restrict all permissions for all applications except FilePermission than they should use a maximum policy like so:

<subsystem xmlns="urn:jboss:domain:security-manager:1.0">
    <deployment-permissions>
        <maximum-set>
            <permission class="java.io.FilePermission" name="/tmp/abc" actions="read,write"/>
        </maximum-set>
    </deployment-permissions>
</subsystem>

Doing so would mean that the previously described web applications which required PropertyPermission would fail to deploy, because it is trying to grant permissions to Properties, which is not granted by the application administrator. There is a chapter on using the security manager in the official documentation for EAP 7.

Enabling the security manager after development of an application can be troublesome because a developer would then need to add the correct policies one at a time, as the AccessControlExceptions where hit. However the Wildfly Security Manager EAP 7 will have a debug mode, which if enabled, doesn’t enforce permission checks, but logs violations of the policy. In this way, a developer could see all the permissions which need to be added after one test run of the application. This feature hasn’t been backported from upstream yet, however a request to get it backported has been made. In EAP 7 GA release you can get extra information about access violations by enabling DEBUG logging for org.wildfly.security.access.

When you run with the Security Manager in EAP 7 each module is able to declare it’s own set of unique permissions. If you don’t define permissions for a module, a default of AllPermissions is granted. Being able to define Security Manager policies per module is powerful because you can prevent sensitive, or vulnerable features of the application server from a serious security impact if it’s compromised. That gives the ability for Red Hat to provide a workaround for a known security vulnerability via a configuration change to a module which limits the impact. For example, to restrict the permissions of the JGroups modules to only the things required you could add the following permissions block to the JGroups:

$EAP_HOME/modules/system/layers/base/org/jgroups/main/module.xml:

<permissions>
    <grant permission="java.io.FilePermission" name="${env.EAP_HOME}/modules/system/layers/base/org/jgroups/main/jgroups-3.6.6.Final-redhat-1.jar" actions="read"/>
    <grant permission="java.util.PropertyPermission" name="jgroups.logging.log_factory_class" actions="read"/>
    <grant permission="java.io.FilePermission" name="${env.EAP_HOME}/modules/system/layers/base/org/jboss/as/clustering/jgroups/main/wildfly-clustering-jgroups-extension-10.0.0.CR6-redhat-1.jar" actions="read"/>
    ...
</permissions>

In EAP 7 GA the use of ${env.EAP_HOME} as above won’t work yet. That feature has been implemented upstream and backporting can be tracked. That feature will make file paths compatible between systems by adding support for System Property, and Environment Variable expansion in module.xml permission blocks, making the release of generic security permissions viable.

While the Security Manager could be used to provide multi-tenancy for the application server, Red Hat does not think that it’s suitable for that. Our Java multi-tenancy in Openshift is achieved by running each tenant’s application in a separate Java Virtual Machine, with the Operating System providing sandboxing via SELinux. This was discussed within the JBoss community, with the view of Red Hat reflected in this post

In conclusion EAP 7 introduced the Wildfly Java Security Manager which allows an application developer to define security policies per application, while also allowing an application administrator the ability to define security policies per module, or a set of minimum, or maximum security permissions for applications. Enabling the Security Manager will have an impact on performance. Red Hat recommends taking a holistic approach to security of the application, and not relying on the Security Manager only.