Common Criteria Configuration Guide

This document provides guidance to administrators and application developers who wish to use Red Hat JBoss Enterprise Application Platform 7 in a certified, Common Criteria compliant, secure configuration.

This document is intended to be self-contained in addressing the most important issues at a high level, and refers to existing documentation where more details are needed. Knowledge of the Common Criteria is not required for readers of this document.

JBoss EAP 7 is the subject of this document as the Target of Evaluation (TOE) for Common Criteria certification. JBoss EAP 7 has been evaluated under Common Criteria version 3.1 at level of assurance EAL4. This provides assurance that this product has been structurally tested.

This chapter contains a brief introduction to the Common Criteria certification and the structure of this book.

Requirements for the Evaluated Configuration contains the requirements for deploying the certified product.

Downloading and Verifying the Packages contains the steps that are required to ensure you are using the certified version of JBoss EAP 7.

Start and Stop JBoss EAP 7 provides instructions on how to start and stop the server, and the different modes of operation.

Development Guide for the Common Criteria Certified System contains guidelines for developers creating applications for JBoss EAP 7.

Overview of the Security Functions contains the details of the security implementation and usage limitations of JBoss EAP 7.

Should there be any discrepancy between information contained in this guide and any other product documentation, this guide takes precedence; it addresses the requirements for the evaluated configuration of JBoss EAP 7.

All instances of EAP_HOME in this guide refer to the JBoss EAP root installation directory. For example, if you used the ZIP installation package and extracted the JBoss EAP binary to your Linux /home/USER directory, EAP_HOME refers to the /home/USER/jboss-eap-[version]/ directory.

See About the Use of EAP_HOME in this Document topic in the Installation Guide for more information on this.

The Common Criteria for Information Technology Security Evaluation, usually known as Common Criteria or CC, is an internationally-recognized standard (ISO/IEC 15408) used as the basis for independent evaluation of the security properties of an IT product.

Common Criteria provides consumers with an impartial security assurance of a product to predefined levels. These levels range from EAL1 to EAL7, each placing increased demands on the developer for evidence of testing, in turn providing increased assurance within the product for consumers.

Under the Common Criteria Recognition Arrangement (CCRA), members agree to recognize Common Criteria certificates that have been produced by any certificate authorizing participant, in accordance with the terms laid out in the CCRA. Currently, the CCRA is comprised of more than 20 member nations: Australia, Austria, Canada, the Czech Republic, Finland, France, Germany, Greece, Hungary, India, Israel, Italy, Japan, the Netherlands, New Zealand, Norway, the Republic of Singapore, Spain, the United Kingdom, and the United States amongst others. New members are expected to join in the near future.

A system can be considered to be CC compliant if it matches an evaluated and certified configuration. This implies various requirements concerning hardware and software, as well as requirements concerning the operating environment, users, and the ongoing operating procedures.

You can find further information on Common Criteria at the Common Criteria Portal.

When installing, configuring, and operating JBoss EAP 7 in a Common Criteria evaluated configuration, you must only refer to the product documentation authorized for use with this Common Criteria certification.

The product documentation bundle is available in two certified formats from the Red Hat Customer Portal:

All references to JBoss EAP documentation in this guide refer to the guides contained in the certified formats.

The hardware and software executing JBoss EAP 7, as well as the software critical to security policy enforcement must be protected from modification by unauthorized parties, whether internal or external. Reasonable physical security measures to ensure that unauthorized persons do not have physical access to the hardware running the JBoss EAP 7 software must be implemented.

There must be one or more competent individuals who are assigned to manage JBoss EAP 7, its environment, and the security of the information it contains. The system administrator personnel must not be carelessly or willfully negligent, or hostile, and follow and abide by the instructions provided by the administrator documentation.

The developer of user applications executed by JBoss EAP 7, including web server applications and enterprise beans, must be trustworthy and comply with all instructions set forth by the user guidance and evaluated configuration guidance of JBoss EAP 7.

The operating system and the Java virtual machine operate according to their specification. These external systems shall be configured in accordance with this guidance.

Any other system with which JBoss EAP 7 communicates is assumed to be under the same management control and operate under the same security policy constraints as JBoss EAP 7.

The Red Hat Customer Portal is the centralized platform for Red Hat knowledge and subscription resources. Use the Red Hat Customer Portal to:

The Customer Portal is available here: https://access.redhat.com.

Red Hat Customer Portal and Red Hat Network are both secure sites. This is indicated by the 'security padlock' icon in the browser status bar.

If the 'security padlock' is not visible, check the authenticity of the site by viewing the identity certificate.

Figure 3.1. Example of the Red Hat Network SSL Certificate

If neither of the lock icons are present in your browser and a verified certificate cannot be found, you may not be connected to the correct site. If you are unable to reach the secure Red Hat Customer Portal site, contact Red Hat Support and report this problem.

Each downloaded file needs to be checked to verify that it is for the certified version of JBoss EAP PROD_VER. The Red Hat Customer Portal lists the SHA-256 hash sum for each file. If the SHA-256 hash sum of a downloaded file matches that quoted on the Red Hat Customer Portal, you can assume it is verified.

For JBoss downloads, you can view the SHA-256 hash sum on the Software Details page for each file, by clicking on the file name in the Download File list. For Red Hat Enterprise Linux downloads, the SHA-256 hash sum is listed next to the ISO download link.

On Apple OSX, the sha256 command must be replaced with shasum -a 256. On Microsoft Windows, a third-party SHA256 hash sum utility is required as there is no native utility.

For example:

$ sha256sum jboss-eap-7.2.0.zip
682d2e7168c9f09cc019dce8f5a70e61169e2dc438dc44ba7352aba4e0634e20 *jboss-eap-7.2.0.zip

The value generated by the sha256sum utility must match the value displayed on the Red Hat Customer Portal for the file. If they are not the same, your download is either incomplete or corrupt, and you will need to download the file again. If the checksum will still not successfully validate after several attempted downloads, contact Red Hat Support for assistance.

The JBoss EAP 7 ZIP file is available from the Customer Portal. The ZIP file installation is platform-independent and is the preferred way to install JBoss EAP 7 on all supported platforms.

Download the ISO installation file for JBoss EAP 7 from the Red Hat Customer Portal. It contains all the security and patch errata.

There are three ways to verify the version number of your JBoss EAP 7 installation.

Using the -V with the startup script

Retrieve information about the version of your JBoss EAP 7 installation by running the same script used to start the server with only the -V switch. If your installation is a standalone or managed domain, for Red Hat Enterprise Linux and Solaris, this script is either standalone.sh or domain.sh, and on Microsoft Windows Server it is the equivalent .bat scripts. The startup scripts are located in EAP_HOME/bin.

Running the startup script with only the -V switch will not start the server, and does not require the server to be running. It displays information about the JBoss EAP version and its configured Java environment. Below is an example of using it on an installation of JBoss EAP 7 on Red Hat Enterprise Linux. Note the version number, JBoss EAP PROD_VER.GA, displayed as the last line of the output.

$ ./standalone.sh -V
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/user/EAP-7.2.GA

  JAVA: java

  JAVA_OPTS:  -server -verbose:gc -Xloggc:"/home/user/EAP-7.2.GA/standalone/log/gc.log" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

17:57:11,912 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Final-redhat-1
JBoss EAP 7.2.0.GA (WildFly Core 3.0.10.Final-redhat-1)

Using the Management Console

When the JBoss EAP 7 server is running, the version information is displayed at top of the home page of the Web Console, located at http://localhost:9990/console/.

View the console output, or server.log file

When a server is started, the version is echoed to the console, and written to the server log. For standalone configurations the server log is located at EAP_HOME/standalone/log/server.log, and for managed domain servers it is EAP_HOME/domain/servers/SERVER_NAME/log/server.log:

08:29:23,756 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.0.GA (WildFly Core 3.0.10.Final-redhat-1) started in 3494ms - Started 299 of 560 services (348 services are lazy, passive or on-demand)

Updates are regularly released for JBoss EAP, and these updates may include fixes for important security issues. However, with the exception of a JBoss EAP 7 ZIP installation, any updates to a Common Criteria compliant JBoss EAP installation will invalidate that installation’s Common Criteria certification.

Start JBoss EAP 7 in one of the following ways:

This topic covers the steps to start JBoss EAP 7 as a Standalone Server.

If you do not specify a configuration file, the server starts with the default file. However, when you start the server, you can specify a configuration manually. The process varies slightly, depending on whether you are using a managed domain or standalone server, and depending on which operating system you are using.

JBoss EAP should now be running, using your alternative configuration file.

The application server startup script accepts the addition of arguments and switches at runtime. The use of these parameters allows for the server to be started under alternative configurations to those defined in the standalone.xml, domain.xml and host.xml configuration files. This might include starting the server with an alternative set of socket bindings or a secondary configuration. A list of these available parameters can be accessed by passing the help switch at startup.

Standalone server:

[localhost bin]$ standalone.sh -h

Managed domain:

[localhost bin]$ domain.sh -h

The following configuration steps must be performed to ensure security compliance with Common Criteria requirements.

Enable Elytron Security Across the Server

There is a simple way to enable Elytron across the server. JBoss EAP 7.2 introduced an example configuration script that enables Elytron as the security provider. This script resides in the EAP_HOME/docs/examples directory in the server installation.

/host=master/core-service=management/management-interface=native-interface:write-attribute(name=sasl-authentication-factory,value=management-sasl-authentication) /host=master/core-service=management/management-interface=native-interface:undefine-attribute(name=security-realm)

Execute the following command to enable Elytron security across the server. The server must be completely stopped before executing the command.

$ EAP_HOME/bin/jboss-cli.sh --file=EAP_HOME/docs/examples/enable-elytron.cli

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

/subsystem=elytron/policy=jacc:add(jacc-policy={})

reload

/subsystem=undertow/application-security-domain=other:write-attribute(name=enable-jacc,value=true)

/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)

/subsystem=ejb3/application-security-domain=other:write-attribute(name=enable-jacc,value=true)

/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain)

/subsystem=elytron/policy=policy-provider-a:add(custom-policy={class-name=MyPolicyProviderA, module=x.y.z})

The elytron subsystem is new in JBoss EAP 7.2. It is based on the WildFly Elytron project, which is a security framework used to unify security across the entire application server. The elytron subsystem enables a single point of configuration for securing both applications and the management interfaces. WildFly Elytron also provides a set of APIs and SPIs for providing custom implementations of functionality and integrating with the elytron subsystem.

You can find more background information on different Elytron components in the Security Architecture guide.

/extension=org.wildfly.extension.elytron:add()

/subsystem=elytron:add

reload

/subsystem=elytron:remove

reload

Security Permissions for JDBC Drivers

For more information, see the Java Security Manager section in the How to Configure Server Security guide.

The system administrator for the operation of the certified system is expected to configure the security permissions for all enterprise applications that are deployed on the certified system, when the certified system runs in the security manager enabled mode.

For more information, refer the Define a Java Security Policy section in the How to Configure Server Security guide.

JBoss EAP 7 implements the Java EE 7 Full Platform and Web Profile standards, including:

Typically the application accepts requests from clients, does some processing and responds with results. The enterprise application that is developed by the trusted developer is hereby referred to as a user application.

The trusted software developer must follow the following restrictions when developing secure software for the certified system.

Enterprise Java Beans Specification Developer Restrictions

The restrictions are:

These restrictions are enforced by the Java Security Manager when the certified system runs in the security manager enabled mode. The following measures should also be taken to protect against endangering the security and stability of the certified system:

To configure authentication for an outbound invocation, the AuthenticationContext can be used. For this outbound invocation, SASL authentication will be used.

final AuthenticationContext authenticationContext = AuthenticationContext.empty()
.with(
MatchRule.ALL,
AuthenticationConfiguration.empty()
.useName("username")
.useRealm(null)
.usePassword("password"));

The AuthenticationContext can then wrap an outbound call to ensure this policy is used.

authenticationContext.runCallable(() -> {
     // Make Remote Call
}

JBoss EAP 7 has access control mechanisms to restrict access for the following request types:

For more information see the Configuration Guide.

The management interfaces of JBoss EAP 7, the management CLI and the web-based management console, allow access to the JBoss EAP system configuration in order to manage all configurable aspects of JBoss EAP 7. Administrators can access general system aspects, such as network port configurations, and container configurations. In addition, configuration aspects for services offered by containers are managed as well.

The configuration of applications, such as the application access control, are addressed in the deployment descriptors shipped with the application. Therefore, application configuration is generally not accessible via the management interfaces.

The administrative interfaces can be bound to a specific network interface. This allows for the management interfaces to be restricted to an administration LAN in order to prevent untrusted users from accessing the management interfaces. In order for administrators to interact with administrative interfaces, they must log in. Administration accounts are maintained separately from other user accounts.

Each action on an object that an administrative user can perform is subject to a role-based access control mechanism. The actions are classified into:

A set of object-action capabilities are mapped to a management role. This mapping defines the allowed access for the management role. A set of pre-defined management roles is included with JBoss EAP PROD_VER and is available after installation. The pre-configured roles are detailed below.

Role-based Access Control Pre-configured Management Roles

A role is a named set of permissions. These permissions include constraints, for example the read permissions for the Monitor role is constrained to non-sensitive actions and targets. Redefinition of the permissions and constraints associated with the above mentioned standard roles is not permitted.

A limited form of creation of new roles is allowed. These new roles are equivalent to the standard roles, but with an additional constraint applied to all permission, for example the target must be related to a particular host or server group.

All administrative operations are stored in configuration files (either domain.xml or standalone.xml depending on the startup mode). The administrative interfaces are an in-memory image of the data stored in the configuration file. Once the in-memory image is modified, the modified configuration file is stored.

The role-based access control mechanism can only be enforced if the administrator accesses the JBoss EAP PROD_VER system configuration using the management CLI or management console. If an administrator has shell access to the host, the underlying operating system may grant direct read or write access to the JBoss EAP system configuration files. Such access would imply that the role-based access control mechanism is not enforced. It is assumed that the host is located in a protected environment where direct access to the JBoss EAP system configuration files is not allowed.

JBoss EAP 7 can generate audit records for access control events. Attempts to access web resources, invocation of EJB methods, unauthorized message destinations, and regular web service related access control can all be logged. As the administrator you can select the level of events to audit.

The audit facility is based on the integrated log4j mechanism. log4j has three main components: loggers, appenders, and layouts. These three types of components work together to enable developers to log messages according to message type and level, and to control at run-time how these messages are formatted and where they are reported.

The audit information is recorded in text files which can be reviewed using tools from the underlying operating system, such as pagers or editors. Audit records can also be forwarded to a syslog server for additional audit controls.

User information, principal name, appears only in the first log that records the authentication request, and also in the ERROR log generated if the authentication is unsuccessful. Subsequent log events do not explicitly record the user executing the methods.

User information can be obtained by using the container and thread IDs that are recorded in each audit log and remain during the life of the user session.

A cluster is a set of nodes. In a JBoss EAP 7 cluster, a node is a JBoss EAP 7 server instance. To build a cluster, several JBoss EAP 7 instances have to be grouped together, also known as a partition.

Clustering allows the execution of applications on several parallel nodes. Two cluster concepts are possible with JBoss EAP 7: a failover cluster, and a load-distribution cluster. In both cases, the server state is distributed across different servers, and if any server fails, the application is still accessible via other cluster nodes.

Cluster communication establishes data consistency between different cluster nodes. JGroups and Infinispan provide the underlying communication, node replication, and caching services for JBoss EAP 7 clusters. These services are configured as MBeans. There is a set of Infinispan and JGroups MBeans for each type of clustering applications (for example, the Stateful Session EJBs, the distributed entity EJBs, etc.).

Infinispan provides distributed cache and state replication services for the JBoss EAP 7 cluster. A JBoss EAP 7 cluster can have multiple Infinispan MBeans: one for HTTP session replication, one for stateful session beans, one for cached entity beans, and so on.

The following information is replicated as part of cluster communication:

JBoss EAP 7 does not perform an automated replication of the JNDI state. When applications defining JNDI resources are replicated to different cluster nodes, they are newly deployed at the nodes. With this deployment, the JNDI resources are created similar to a regular deployment. System configuration changes that involve modifications of JNDI resources are replicated to the cluster nodes, and applied similarly to a local reconfiguration. The JNDI registry maintaining the JNDI mappings is managed consistently between the different cluster nodes. As JNDI does not maintain a state other than the JNDI registry, this is sufficient to ensure cluster-wide consistency of the JNDI service.

Users are assigned unique user identifiers which are used as the basis for access control decisions and auditing.

JBoss EAP 7 authenticates the identity of the user before allowing the user to perform any further security-mediated actions.

JBoss EAP 7 internally maintains the identifier associated with the thread spawned for a user after a successful authentication.

JBoss EAP 7 provides different identification and authentication mechanisms for different request types:

JBoss EAP 7 supports the aggregation of operations into transactions, which can be applied and rolled back consistently.

A transaction is a unit of work containing one or more operations involving one or more shared resources having atomicity, consistency, isolation and durability (ACID) properties - the four important properties of transactions.

The default transaction manager for JBoss EAP 7 is JBoss Transactions, a fast in-VM transaction manager implementation.

Traditionally, ACID transaction systems have shared the following characteristics:

The advent of the Internet and web services has given rise to distributed transactions between participants unknown to each other. JBoss Transactions adds native support for web services transactions by providing the components necessary to build interoperable, reliable, multi-party, web services-based applications with minimum effort.

The programming interfaces are based on the Java API for XML Transactions (JAXTX) and include protocol support for the WS-AtomicTransaction and WS-BusinessActivity specifications. JBoss is designed to support multiple coordination protocols.

JBoss EAP 7 supports both local and distributed transactions. A transaction is considered to be distributed if it spans multiple process instances, i.e. virtual machines (VMs). Typically a distributed transaction will contain participants that are located within multiple VMs but the transaction is coordinated in a separate VM, or co-located with one of the participants. If the deployment requires distributed transactions then the web services transactions component can be utilized, which uses SOAP/HTTP.