One of the major enhancements added in JBoss Enterprise Application Platform (EAP) 6 was modular classloading. Combined with the use of a Java Security Manager in EAP 7, we now have a flexible extra layer of security for threats against Java Enterprise Applications. However the extra layer of security still comes at the cost of performance.
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:
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 following option:
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:
java.util.PropertyPermission * read,write
The custom Security Manager in EAP 7 also provides some extra methods for doing unchecked actions. These can be used by developers instead of PrivilegedActions in order to improve the performance of the application. There are a few of these optimized methods:
Out of the box EAP 7 ships with a minimum, and maximum policy like so:
That doesn’t enforce any particular permissions on applications, and grants them
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:
Alternatively if they wanted to restrict all permissions for all applications except FilePermission than they should use a maximum policy like so:
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 will be a chapter on using the security manager in the official documentation for EAP 7
when it goes GA.
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 custom 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, we raised a request to get it backported here
. In EAP 7 GA release you can get extra information about access violations by enabling DEBUG logging for
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
is granted. Being able to define Security Manager policies per modules 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:
In EAP 7 GA the use of
as above won’t work yet. That features has been implemented upstream and backporting can be tracked here
. 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.
In conclusion EAP 7 introduced a custom 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. We recommend taking a holistic approach to security of the application, and not relying on the Security Manager only.
For more information see this presentation slide deck by David Lloyd