JBoss Enterprise Application Platform 5 Version
5.1.0 and 5.1.1 Security Target
3.13
Version:
Released
Status:
2011-11-14
Last Update:
Public
Classification:
Trademarks
Red Hat and the Red Hat logo are trademarks or registered trademarks of Red Hat, Inc. in the United
States, other countries, or both.
The following terms are trademarks of Sun Microsystems:
●
Java
●
J2EE
Legal Notice
This document is provided AS IS with no express or implied warranties. Use the information in this
document at your own risk.
This document may be reproduced or distributed in any form without prior permission provided the
copyright notice is retained on all copies. Modified versions of this document may be freely distributed
provided that they are clearly identified as such, and this copyright is included intact.
Revision History
Changes to Previous Revision
Author(s)
Date
Revision
Initial Version based on JBoss EAP 4.3.0 GA CP03 ST
Stephan Mueller
2010-01-14
3.0
Conversion to XML-based document including editorial changes
Stephan Mueller
2010-02-25
3.1
Include comments from evaluator
Stephan Mueller
2010-01-28
3.2
Clarification of SFRs, addition of Seam Access Control Policy, addition of
assumption of trusting the application developer
Stephan Mueller
2010-06-15
3.3
Removal of Seam Access Control Policy, consideration of validator comments
Stephan Mueller
2010-09-16
3.4
Completion of component list
Stephan Mueller
2010-09-20
3.5
Completion of database list, update of FDP_ACC.1(4) and FDP_ACF.1(4).
Alejandro
Masino, Stephan
Mueller
2010-11-03
3.6
Added list of operating systems supported.
Alejandro Masino
2010-12-15
3.7
Update list of operating systems supported.
Alejandro Masino
2011-01-20
3.8
Update list of TOE components.
Alejandro Masino
2011-02-10
3.9
Update JBoss Application Server Structure and TOE boundary sections.
Alejandro Masino
2011-02-25
3.10
Remove JOPR component from the TOE list.
Alejandro Masino
2011-03-01
3.11
Add SFR sufficiency analysis.
Stephan Mueller
2011-06-07
3.12
Add JBoss 5.1.1.
Stephan Mueller
2011-11-14
3.13
Page 2 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Table of Contents
1 Introduction .................................................................................................... 8
1.1 Security Target Identification ......................................................................................... 8
1.2 TOE Identification .......................................................................................................... 8
1.3 TOE Type ........................................................................................................................ 8
1.4 TOE Overview ................................................................................................................ 8
1.4.1 TOE Type ............................................................................................................... 9
1.4.2 Required Non-TOE Hardware and Software ........................................................... 9
1.4.3 Intended Method of Use ...................................................................................... 10
1.4.4 Major Security Features ....................................................................................... 10
1.5 TOE Description ........................................................................................................... 11
1.5.1 Introduction ......................................................................................................... 11
1.5.2 Application Server definition ............................................................................... 11
1.5.3 JBoss Application Server Structure ...................................................................... 11
1.5.3.1 Java Security Manager ................................................................................ 14
1.5.4 TOE boundaries ................................................................................................... 15
1.5.4.1 Physical ...................................................................................................... 15
1.5.4.2 Logical ........................................................................................................ 17
1.5.4.3 Security Policy Model .................................................................................. 18
2 CC Conformance Claim ................................................................................... 19
3 Security Problem Definition ............................................................................ 20
3.1 Threat Environment ..................................................................................................... 20
3.1.1 Threats countered by the TOE ............................................................................ 20
3.2 Assumptions ................................................................................................................ 20
3.2.1 Environment of use of the TOE ........................................................................... 20
3.2.1.1 Physical ...................................................................................................... 20
3.2.1.2 Personnel .................................................................................................... 21
3.2.1.3 Connectivity ............................................................................................... 21
3.3 Organizational Security Policies ................................................................................... 21
4 Security Objectives ........................................................................................ 22
4.1 Objectives for the TOE ................................................................................................. 22
4.2 Objectives for the Operational Environment ................................................................ 22
4.3 Security Objectives Rationale ...................................................................................... 23
4.3.1 Security objectives coverage .............................................................................. 23
4.3.2 Security objectives sufficiency ............................................................................ 24
5 Extended Components Definition .................................................................... 26
5.1 Class FDP: User data protection ................................................................................... 26
5.1.1 (ROL) .................................................................................................................. 26
5.1.1.1 FDP_ROL.2-jb - Automated rollback ............................................................ 26
6 Security Requirements ................................................................................... 27
6.1 TOE Security Functional Requirements ........................................................................ 27
6.1.1 Security audit (FAU) ............................................................................................ 28
Page 3 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.1.1 Audit data generation (FAU_GEN.1) ........................................................... 28
6.1.1.2 User identity association (FAU_GEN.2) ...................................................... 29
6.1.2 User data protection (FDP) .................................................................................. 29
6.1.2.1 HTTP Access Control Policy (FDP_ACC.1(1)) ............................................... 29
6.1.2.2 EJB Access Control Policy (FDP_ACC.1(2)) .................................................. 29
6.1.2.3 JMS Access Control Policy (FDP_ACC.1(3)) ................................................. 29
6.1.2.4 Webservices Access Control Policy (FDP_ACC.1(4)) ................................... 30
6.1.2.5 JMX Invokers Access Control Policy (FDP_ACC.1(5)) ................................... 30
6.1.2.6 HTTP Access Control Functions (FDP_ACF.1(1)) .......................................... 30
6.1.2.7 EJB Access Control Functions (FDP_ACF.1(2)) ............................................. 31
6.1.2.8 JMS Access Control Functions (FDP_ACF.1(3)) ............................................ 32
6.1.2.9 Webservices Access Control Functions (FDP_ACF.1(4)) .............................. 32
6.1.2.10 JMX Invokers Access Control Functions (FDP_ACF.1(5)) ........................... 33
6.1.2.11 Automated rollback (FDP_ROL.2-jb) ......................................................... 34
6.1.3 Identification and authentication (FIA) ................................................................ 34
6.1.3.1 User attribute definition (FIA_ATD.1) ......................................................... 34
6.1.3.2 Timing of authentication (FIA_UAU.1) ........................................................ 34
6.1.3.3 Timing of identification (FIA_UID.1) ........................................................... 35
6.1.3.4 User-subject binding (FIA_USB.1) .............................................................. 35
6.1.4 Security management (FMT) ............................................................................... 36
6.1.4.1 Management of object security attributes (FMT_MSA.1) ........................... 36
6.1.4.2 Static attribute initialisation (FMT_MSA.3(1)) ............................................ 36
6.1.4.3 Static attribute initialisation (FMT_MSA.3(2)) ............................................ 36
6.1.4.4 Static attribute initialization (FMT_MSA.3(3)) ............................................ 36
6.1.4.5 Management of TSF data (FMT_MTD.1(ACC)) ............................................ 36
6.1.4.6 Management of TSF data (FMT_MTD.1(AUTH)) .......................................... 37
6.1.4.7 Specification of management functions (FMT_SMF.1) ................................ 37
6.1.4.8 Security roles (FMT_SMR.1) ....................................................................... 37
6.1.5 Protection of the TSF (FPT) .................................................................................. 37
6.1.5.1 Internal TSF consistency (FPT_TRC.1) ........................................................ 37
6.2 Security Functional Requirements Rationale ................................................................ 38
6.2.1 Security requirements coverage ......................................................................... 38
6.2.2 Security requirements sufficiency ....................................................................... 39
6.2.3 Security requirements dependency analysis ....................................................... 41
6.3 Security Assurance Requirements ............................................................................... 44
6.4 Security Assurance Requirements Rationale ............................................................... 45
7 TOE Summary Specification ............................................................................ 46
7.1 TOE Security Functionality ........................................................................................... 46
7.1.1 Access Control ..................................................................................................... 46
7.1.2 Audit .................................................................................................................... 48
7.1.3 Clustering ............................................................................................................ 48
7.1.4 Identification and authentication ........................................................................ 49
7.1.5 Transaction Rollback ............................................................................................ 50
8 Abbreviations, Terminology and References .................................................... 52
Page 4 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
8.1 Abbreviations ............................................................................................................... 52
8.2 Terminology ................................................................................................................. 53
8.3 References ................................................................................................................... 55
Page 5 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
List of Tables
Table 1: Java EE tier listing and JBoss coverage .................................................................... 12
Table 2: Mapping of security objectives to threats and policies ............................................ 23
Table 3: Mapping of security objectives for the Operational Environment to assumptions,
threats and policies ........................................................................................................ 23
Table 4: Sufficiency of objectives countering threats ........................................................... 24
Table 5: Sufficiency of objectives holding assumptions ........................................................ 24
Table 6: Sufficiency of objectives enforcing Organizational Security Policies ....................... 25
Table 7: Security functional requirements for the TOE ......................................................... 27
Table 8: Mapping of security functional requirements to security objectives ....................... 38
Table 9: Security objectives for the TOE rationale ................................................................ 39
Table 10: TOE SFR dependency analysis .............................................................................. 41
Table 11: Security assurance requirements .......................................................................... 44
Page 6 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
List of Figures
Figure 1: JBoss Components ................................................................................................. 14
Page 7 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
1 Introduction
1.1 Security Target Identification
JBoss Enterprise Application Platform 5 Version 5.1.0 and 5.1.1 Security Target
Title:
3.13
Version:
Released
Status:
2011-11-14
Date:
Red Hat, Inc.
Sponsor:
Red Hat, Inc.
Developer:
BSI-DSZ-CC-BSI-DSZ-CC-0687
Certification ID:
Security Target, Common Criteria, JBoss, Java EE, Application Server, JBoss
Enterprise Application Platform
Keywords:
1.2 TOE Identification
The TOE is JBoss Enterprise Application Platform (EAP) 5 Version 5.1.0, 5.1.1.
1.3 TOE Type
The TOE type is Java EE Application Server.
1.4 TOE Overview
This Security Target documents the security characteristics of the JBoss Enterprise Application
Platform (in the rest of this document the term “JBoss” is used as a synonym for this TOE).
The TOE of JBoss EAP 5.1.0 comprises the following components, security advisories and patches:
●
JBoss Enterprise Application Platform (EAP) 5.1.0
●
Patch: JBoss Remoting 2.5.3 SP1 fix
●
Security Advisory: Add security_cc.policy to EAP 5.1
The TOE of JBoss EAP 5.1.1 comprises the following components, security advisories and patches:
●
JBoss Enterprise Application Platform (EAP) 5.1.1
●
Security Advisory: Add security_cc.policy to EAP 5.1
The TOE does not include the hardware, firmware, operating system or Java virtual machine used
to run the software components.
The TOE is the JBoss Enterprise Application Platform which implements an application server. JBoss
is based on Java Enterprise Edition (Java EE) and therefore supports a large variety of operating
systems. As an application server, JBoss allows client computers or devices to access applications.
Access to these applications is possible through different network protocols, such as HTTP, RMI-IIOP,
and others. JBoss handles the business logic of the application, including accessing and providing
the user data required by the application.
The TOE is defined as a stand-alone JBoss instance. If a cluster of JBoss nodes is defined, then the
entire cluster is considered to be one TOE.
Page 8 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
1.4.1 TOE Type
JBoss is a Java-based application server which provides many advanced product features, including
clustering, failover, load balancing, and Enterprise JavaBeans version 3.
1.4.2 Required Non-TOE Hardware and Software
The Operational Environment for the TOE allows the use of one of the following operating systems:
●
Redhat Enterprise Linux 4 x86
●
Redhat Enterprise Linux 4 x86-64
●
Redhat Enterprise Linux 5 x86
●
Redhat Enterprise Linux 5 x86-64
●
Redhat Enterprise Linux 6 x86
●
Redhat Enterprise Linux 6 x86-64
●
Solaris 9 x86
●
Solaris 9 SPARC (32-bit)
●
Solaris 9 SPARC (64-bit)
●
Solaris 10 x86
●
Solaris 10 x86-64
●
Solaris 10 SPARC 64
●
Microsoft Windows Server 2008 x86
●
Microsoft Windows Server 2008 x86-64
●
Microsoft Windows Server 2003 x86
●
Microsoft Windows Server 2003 x86-64
Additionally, the Operational Environment for the TOE allows the use of one of the following Java
Runtime Environments:
●
Sun JRE 1.6.x
●
IBM JRE 1.6.x
●
OpenJDK JRE 1.6.x
For providing the cryptographic services supporting the SSL/TLS protocol on which the
certificate-based authentication relies on, the TOE uses the standard cryptographic service providers
shipped with the above mentioned Java Runtime Environments.
On Red Hat Enterprise Linux, the TOE uses the native OpenSSL library for implementing the SSL/TLS
protocol. On other environments, the functionality provided by the JREs is used.
As the TOE functionality only relies on the correct operation of the Java virtual machine, the TOE
can be executed on any operating system that is supported by the respective Java virtual machine.
This also means that any hardware supported by the aforementioned operating systems can be
used to execute the TOE.
The following relational databases are allowed to be used with the TOE (the listed databases are
part of the operational environment and therefore not covered with security claims in this Security
Target):
●
IBM DB2 9.7
●
Microsoft SQL Server 2005
●
Microsoft SQL Server 2008
Page 9 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
MySQL 5.0 (5.0.79)
●
MySQL v5.1 (5.1.36)
●
Oracle 10g R2 (10.2.0.4)
●
Oracle 11g R1 (11.1.0.7.0)
●
Oracle 11g R1 RAC (11.1.0.7.0)
●
Oracle 11g R2
●
Oracle 11g R2 RAC
●
PostgreSQL v8.2.17
●
PostgreSQL v8.3
●
Sybase ASE 15.0.3
The internal database (HSQL DB) is not supported in the evaluated configuration.
1.4.3 Intended Method of Use
The TOE is intended to operate in a networked environment with other instantiations of the TOE
as well as other well-behaved client systems operating within the same management domain. All
those systems need to be configured in accordance with a defined common security policy.
Communication links between individual instances of the TOE can be protected against loss of
confidentiality and integrity using separate physical networks or by cryptographic protection
mechanisms supported by the TOE.
The data under the control of the TOE is stored in named objects, and the TOE can associate with
each named object a description of the access rights to that object.
Several TOE systems may be interlinked in a network, and individual networks may be joined by
bridges and/or routers. Each of the TOE systems implements its own security policy. The TOE does
not include any synchronization function for those policies. As a result a single user may have user
accounts on each of those systems with different user IDs. This statement applies only to inter-TOE
consistency as one TOE instance (either the standalone system or the cluster configuration of the
TOE) ensures its internal data consistency.
If other systems are connected to a network they need to be configured and managed by the same
authority using an appropriate security policy that does not conflict with the security policy of the
TOE.
1.4.4 Major Security Features
The primary security features of the TOE are:
●
Access Control covering the objects of URLs, EJB methods, message queues and topics
●
Audit covering the access control decisions
●
Clustering ensuring the consistency of user and TSF data between cluster nodes
●
Identification and Authentication ensuring the proper identification and authentication of
users to facilitate the various access control mechanisms
●
Transaction Rollback ensuring data consistency for user and TSF data
These primary security features are supported by the appropriate use of domain separation and
reference mediation provided by the Java virtual machine if the Java Security Manager is utilized
and the underlying operating system, which ensure that the security features are always invoked
and cannot be bypassed, and that the TOE can protect itself.
Page 10 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
1.5 TOE Description
1.5.1 Introduction
The TOE representing an application server is implemented as an application, which allows users
to access applications over various network protocols. JBoss executes Java applications which are
registered and are executed by the application server.
1.5.2 Application Server definition
The TOE representing an application server is implemented as an application, which allows users
to access applications over various network protocols. JBoss executes Java applications which are
registered and are executed by the application server.
JBoss is written entirely in Java and provides a Java EE-compliant environment which is consistent
with the Java EE 5 specification as defined by JSR-244. Depending on the configuration of the JBoss
server, components required by the Java EE specification can be disabled. The applications developed
for and served by JBoss are to be written in Java. Developers of the Java application implement the
business logic and are free to utilize the supporting functionality of Java EE.
This illustration documents the structure of JBoss. The JBoss microcontainer provides the environment
for the execution of different containers which allow applications to utilize services provided by
these containers. The configuration of JBoss allows selectively enabling or disabling every container.
The distribution of JBoss provides a number of containers that can be utilized, but additional
containers may be implemented by third parties. The evaluated configuration defines the containers
which are covered by the evaluation and therefore may be enabled in a CC-compliant configuration.
As part of the Java EE framework implemented by JBoss, applications can provide their logic to
remote clients through the following network protocols:
●
HTTP protocol: Java servlets provide their functionality based on URLs requested by the
client.
●
Enterprise Java Beans (EJB): Java classes can be made accessible to remote clients by allowing
these clients to access EJB classes and their methods using the RMI protocol.
In addition to these protocols that can be used to access the business logic of an application, various
other protocols may be made accessible by the application server to support the application’s
functionality – these protocols are provided by different JBoss containers and are unavailable if the
containers are disabled. Such additional protocols might be the following:
●
A message queue protocol may be provided as a reliable and possibly asynchronous
communication channel. Such message queues may be used for the communication between
different parts of distributed applications where different parts of an application are
implemented in different instances of the application server. In addition, message queues
may be used for the application to client communication.
●
A JNDI name resolution service may be provided by the application server to allow different
parts of an application or the client to resolve EJB classes and other resources.
1.5.3 JBoss Application Server Structure
JBoss Enterprise Application Platform implements a system for innovative and scalable Java
applications. It includes open source technologies for deploying, and hosting enterprise Java
applications and services.
Page 11 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
JBoss Enterprise Application Platform balances innovation with enterprise class stability by integrating
the most popular clustered Java EE application server with next generation application frameworks.
Built on open standards, JBoss Enterprise Application Platform integrates various containers
implementing the Java EE functionality, and other containers providing mechanisms to applications
which go beyond the Java EE standard into a complete, simple enterprise solution for Java
applications.
The Java EE specification considers the following four layers, also called tiers. Applications utilizing
the Java EE specification may implement any combination of these tiers. In addition to listing the
tiers, the following table specifies which tiers can be implemented and executed using the framework
of JBoss.
JBoss coverage
Java EE Tier
The applet may be stored on the JBoss server in order
for the client to automatically download it when
accessing a web page served by JBoss.
Client tier
The client tier is the layer of the application executed
on the client system in order to display the information
provided by the application server. The client tier can
be implemented by:
However, neither the applet nor the application is
executed by the JBoss application server, but they are
executed by the Java Virtual Machine of the client
system accessing the JBoss information remotely.
● An applet executed by the client’s browser
● A stand-alone Java application executed by
the client’s Java Virtual Machine Therefore, the client tier is considered to be not
covered by JBoss.
● The JMS client
The web tier can be implemented using Java servlets
executing within the JBoss framework.
Web tier
The web tier is the presentation layer of the application
server. It gathers the business information from the
lower EJB tier and converts it to be presented as web
pages.
The web tier is implemented by the
customer-developed application.
The web tier therefore does not implement any
business logic as it can be considered an information
converter from the application-internal data
representation to a user-viewable and
user-interpretable presentation.
Considering a web-shopping application, the web tier
implements the presenting layer with functionality
such as the web pages showing the sold products or
the display of the contents of the user’s shopping cart.
The EJB tier can be implemented using various types
of EJBs executing within the JBoss framework.
Enterprise Java Beans (EJB) tier
The EJB tier implements the business logic of the entire
application. Business logic is considered to be the
functionality implementing the information flow
consistent with the purpose of the application.
The EJB tier is implemented by the
customer-developed application.
Considering a web-shopping application, the EJB tier
implements business logic, such as the management
and maintenance of the sold products, the shopping
cart for each user.
Page 12 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
JBoss coverage
Java EE Tier
The enterprise information system’s tier is provided
by the TOE allowing the application’s EJBs to access
relational databases listed for JDBC.
Enterprise Information System’s tier
The enterprise information system’s tier provides the
logic to allow the EJB tier to access external data
stores. This tier therefore covers database access
mechanisms, such as a JDBC driver.
The enterprise information system’s tier is
implemented by the TOE.
Table 1: Java EE tier listing and JBoss coverage
Fundamentally in the JBoss architecture, the JBoss microcontainer manages the set of pluggable
component services which are either implemented as POJOs or as MBeans. This allows assembling
different configurations and provides the flexibility to tailor the configurations to meet specific
requirements.
The administrator does not have to run a large, monolithic server all the time; as the components
not needed (which can also reduce the server startup time considerably) can be removed. Also
additional services can be integrated into JBoss by writing new MBeans. In addition, POJOs configured
as services can be created for either extending the JBoss functionality or implementing business
logic.
The following illustration depicts the interoperation of the different components of JBoss. The above
mentioned components or services that can be enabled or disabled individually for the JBoss runtime
are the Java EE 5 services and the services beyond Java EE. The following description applies to
the illustration:
●
The Hardware together with the operating system executes the Java Virtual machine which
in turn executes the JBoss microcontainer. This microcontainer provides the foundation on
which all JBoss containers perform their tasks.
●
Each container implements either a service as specified in Java EE 5 or a service providing
additional functionality beyond Java EE 5.
●
Applications execute as part of containers (such as the Web Services container) and utilize
services from other containers.
Page 13 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Figure 1: JBoss Components
The TOE allows the interaction with users through the following services:
●
HTTP web network protocol
●
Webservices
●
Enterprise Java Beans (EJB)
●
Java Messaging Service (JMS)
●
Java Naming and Directory Interface (JNDI)
●
JMX Invokers
Applications utilize the services provided by the different containers by accessing the API exported
by each container. These applications are loaded and executed by either the JSP/Servlet container,
EJB container or other containers. The technical separation the untrusted applications and the TOE
is achieved using the Java Security Manager with an appropriate policy configuration.
1.5.3.1 Java Security Manager
The evaluated configuration of the TOE only allows the following mode of operation which has an
impact on how the TOE can protect itself against the behavior of applications or other untrusted
code. This mode utilizes the Java Security Manager provided by the Java Virtual Machine as part of
the TOE environment.
Page 14 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
The Java Security Manager is utilized with a policy that completely protects the JBoss execution
from any application or other untrusted code (such as the JDBC driver) utilizing the JBoss framework.
The Security Manager together with its policy prohibits that any application can accidentally or
intentionally interferes with the operation of JBoss.
It is not allowed to disable the Java Security Manager or to weaken the security policy delivered
with the TOE which ensures the protection of the TOE. Together with the TOE, the Security Manager
policy that protects the TOE from any application or other untrusted code is provided.
1.5.4 TOE boundaries
1.5.4.1 Physical
The TOE is the JBoss Enterprise Application Platform. Based on the above shown illustration, the
TOE consists of the JBoss microcontainer and the containers/services specified below.
The TOE of JBoss allows the use of the following containers in the evaluated configuration (the
containers are purple boxes shown in the picture above – the illustration above is provided for a
better understanding only and the following list of components is authorative, regardless what the
illustration shows):
●
JBoss Application Server
●
JBossSeam
●
RESTEasy
●
mod_cluster
●
mod_jk
●
JBoss VFS
●
JBoss Reflect
●
JBoss MDR
●
JBoss Man
●
JBoss Kernel
●
JBoss CL
●
JBoss Deployers
●
JBoss Metadata
●
Hibernate Core
●
Hibernate Entity Manager
●
Hibernate Annotations
●
Hibernate Search
●
Hibernate Validator
●
Hibernate Common Annotations
●
Hibernate EJB Persistence 3.0 API
●
JBoss Web
●
JBoss Cache
●
Jboss HA-Server-API
●
JBoss HA-Server-Cache-JBC
●
JGroups
Page 15 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
JBoss Transactions
●
JBoss JAXR
●
JBoss EJB3 BOM EAP5
●
JBoss EJB3 Core
●
JBoss EJB3 Common
●
JBoss EJB3 Context
●
JBoss EJB3 Deployers
●
JBoss EJB3 Interceptors
●
JBoss EJB3 Metrics Deployer
●
JBoss EJB3 Security
●
JBoss EJB3 Timeout
●
JBoss EJB3 VFS
●
JBoss WS Parent
●
JBoss WS SPI
●
JBoss WS Common
●
JBoss WS Framework
●
JBoss WS-Native
●
JBoss WS-CXF
●
JBoss AOP
●
JBoss Messaging
●
JBoss Remoting
●
JBoss Remoting Aspects
●
JBoss Serialization
●
JSF
●
JPA
●
JBoss Security
●
JBoss Negotiation
●
JBossXACML
●
JBoss Profiler-jvmti
●
JBoss Admin Console
●
Netty
●
JBoss Native
●
JBoss Logging
●
RichFaces
●
Apache CXF
●
Javassist
●
Xalan
●
StAX
●
JAXB
●
woodstox
●
sun-jaxws
Page 16 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
cobertura
●
nekohtml
●
quartz
●
Spring
The TOE and its documentation (especially the CC configuration guide acting as the central guidance
document covering the different aspects of the evaluated configuration of the TOE) are supplied
via the Red Hat Network web site allowing a download of electronic copies of the TOE. Updates are
also delivered through the Red Hat Network. The integrity and authenticity of the electronic copies
are ensured by using cryptographic signatures.
Relevant guidance documents for the secure operation of the TOE are:
●
JBoss EAP5 Administration and Configuration Guide
●
JBoss Common Criteria Guide
●
JBoss EAP5 Installation Guide
●
JBoss AS 5.1 Clustering Guide
●
JBoss EAP5 Security Guide
●
JBoss EAP5 Transactions JTA Programmers Guide
1.5.4.2 Logical
Please see the description of the security functionality in chapter for the TOE summary specification.
Evaluated configuration
The evaluated configurations are defined as follows.
●
The JMX Console (implemented in jmx-console.war) allowing users to access the JBoss
microcontainer to perform administrative tasks must be protected against the use by all
users not being trusted administrators. The protection can be achieved by either restricting
access to the web-frontend using the HTTP access control facility provided by the TOE or
by completely removing the console from the TOE.
●
The Web Console (implemented in web-console.war) provides another web-based access
into the JBoss microcontainer. It therefore has to be protected the same way as the JMX
Console.
●
The Enterprise Application Platform Administration Console (implemented in
admin-console.war) provides a set of administrative features to manage the configuration
of JBoss as well as the deployment of applications. This console must be protected against
the use by all users not being trusted administrators. The protection can be achieved by
either restricting access to the web-frontend using the HTTP access control facility provided
by the TOE or by completely removing the console from the TOE.
●
The http-invoker.sar found in the deploy directory is a service that provides RMI/HTTP access
for EJBs and the JNDI Naming service. This includes a servlet that processes posts of
marshaled org.jboss.invocation. Invocation objects that represent invocations that should
be dispatched onto the MBeanServer. Effectively this allows access to MBeans that support
the detached invoker operation via HTTP when sending appropriately formatted HTTP posts.
This servlet has to be protected against the use by unprivileged users. To secure this access
point you would need to secure the JMXInvokerServlet servlet found in the
http-invoker.sar/invoker.war/WEB-INF/web.xml descriptor.
Page 17 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
The jmx-invoker-adaptor-server.sar is a service that exposes the JMX MBeanServer interface
via an RMI compatible interface using the RMI/JRMP detached invoker service. This interface
has to be made unavailable to unprivileged users which can be done by using the
org.jboss.jmx.connector.invoker.AuthenticationInterceptor interceptor for performing
identification and authentication using JAAS. Additionally, access control has to be configured
using the interceptors of either org.jboss.jmx.connector.invoker.RolesAuthorization or
org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization.
●
The JDBC drivers connecting to any of the database servers must be separated from the
TOE using the provided Java Security Manager policy. The Security Manager policy is
distributed with the TOE.
1.5.4.3 Security Policy Model
The security policy for JBoss is defined by the security functional requirements in chapter 6. The
following is a list of the subjects and objects participating in the policy.
Subjects:
●
Users represented by a Principal or Subject object
Objects:
●
Data accessible at an URL
●
EJBs and associated methods
●
Message queue and topic
●
POJOs and session beans
●
JMX invokers
TSF data:
●
Deployment descriptors
●
Security annotations as part of the Java source code
●
User accounts, including the security attributes defined by FIA_ATD.1
●
Audit records
User data:
●
Applications deployed with the TOE and all data controlled by them
Page 18 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
2 CC Conformance Claim
This ST is CC Part 2 extended and CC Part 3 conformant, with a claimed Evaluation Assurance Level
of EAL4, augmented by ALC_FLR.3.
This ST does not claim conformance to any Protection Profile.
Common Criteria [CC] version 3.1 revision 3 is the basis for this conformance claim.
Page 19 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
3 Security Problem Definition
3.1 Threat Environment
This section describes the threat model for the TOE and identifies the individual threats that are
assumed to exist in the TOE environment.
The assets to be protected by the TOE comprise the information stored, processed or transmitted
by the TOE. The term “information” is used here to refer to all data held within the application
server, including data in transit between instances of the application server.
The TOE counters the general threat of unauthorized access to information, where “access” includes
disclosure, modification and destruction.
The threat agents having an interest in manipulating the data model can be categorized as either:
●
Unauthorized users of the TOE, i.e. individuals who have not been granted the right to access
the system.
●
Authorized users of the TOE, i.e. individuals who have been granted the right to access the
system.
The threat agents are assumed to originate from a well managed user community in a non-hostile
working environment, and hence the product protects against threats of security vulnerabilities
that might be exploited in the intended environment for the TOE with medium level of expertise
and effort. The TOE protects against straightforward or intentional breach of TOE security by
attackers possessing an enhanced-basic attack potential.
3.1.1 Threats countered by the TOE
T.UAUSER
An attacker (possibly, but not necessarily, an unauthorized user of the TOE) may impersonate
an authorized user of the TOE. This includes the threat of an authorized user that tries to
impersonate as another authorized user without knowing the authentication information.
T.ACCESS
An authorized user may gain access to resources or perform operations for which no access
rights have been granted.
T.DIFFER
An authorized user may cause user data or TSF data that is stored in multiple places to
become inconsistent and cause either user data loss or circumvention of TSF.
3.2 Assumptions
3.2.1 Environment of use of the TOE
3.2.1.1 Physical
A.PROTECT
The hardware and software executing the TOE as well as the TOE software critical to security
policy enforcement will be protected from unauthorized modification including unauthorized
modifications by potentially hostile outsiders.
Page 20 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
3.2.1.2 Personnel
A.ADMIN
It is assumed that there are one or more competent individuals who are assigned to manage
the TOE and the TOE environment and the security of the information it contains. The system
administrative personnel are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the administrator documentation.
A.DEVEL
The developer of user applications executed by the TOE, including web server applications
and enterprise beans, is trustworthy and will comply with all instructions set forth by the
user guidance and evaluated configuration guidance of the TOE.
3.2.1.3 Connectivity
A.SYSTEM
The operating system and the Java virtual machine operate according to their specification.
These external systems are configured in accordance with the installation guidance and the
evaluated configuration guidance of the TOE.
A.CLUSTER
One or more TOE instances operate in a network segment that is logically separated from
any other network segment using a packet filtering mechanism. This packet filter must only
allow communication to pass through originated outside the TOE network segment if the
network protocol is TCP and has the following destination ports: 8080, 8443. All
communication originating from one of the TOE instances is to be allowed.
A.PEER
Any other system with which the TOE communicates is assumed to be under the same
management control and operate under the same security policy constraints as the TOE
itself.
3.3 Organizational Security Policies
P.ACCOUNTABILITY
The users of the system shall be held accountable for their actions within the system.
Page 21 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
4 Security Objectives
4.1 Objectives for the TOE
O.AUTHORIZATION
The TOE must ensure that only identified and authorized users gain access to the TOE and
its resources.
O.ACCESS
The TSF must control access to resources based on identity of users. The TSF must allow
authorized users to specify which resources may be accessed by which users.
O.AUDITING
The TSF must record security relevant actions of users of the TOE. The information recorded
with security relevant events must be in sufficient detail to help an administrator of the TOE
detect attempted security violations or potential misconfiguration of the TOE security features
that would leave the IT assets open to compromise.
O.CONSISTENCY
The TSF must ensure the consistency of user data as well as TSF data while it is being
processed. Consistency needs to be ensured when data is processed that may be located
in multiple places.
4.2 Objectives for the Operational Environment
OE.ADMIN
Those responsible for the administration of the TOE are competent and trustworthy
individuals, capable of managing the TOE and the security of the information it contains.
OE.SYSTEM
Those responsible for the TOE must ensure that the operating system and the Java virtual
machine are installed and configured in accordance with the guidance of the TOE and that
these mechanisms operate as specified. This also covers that only the Java virtual machines
enumerated in this ST are used as underlying platform to ensure that proper date and time
information is available to the audit facility.
OE.INSTALL
Those responsible for the TOE must establish and implement procedures to ensure that the
software components that comprise the TOE are distributed, installed, configured and
administered in a secure manner.
OE.PHYSICAL
Those responsible for the TOE must ensure that those parts of the TOE critical to security
policy as well as the underlying hardware and software are protected from physical attack
which might compromise IT security objectives.
OE.RECOVER
Those responsible for the TOE must ensure that procedures and/or mechanisms are provided
to assure that, after system failure or other discontinuity, recovery without a protection (i.e.,
security) compromise is obtained.
Page 22 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
OE.DEVEL
Those responsible for the TOE shall ensure that the developers of the applications executed
by the TOE are trustworthy and implement the applications in accordance with the guidance
provided with the TOE.
4.3 Security Objectives Rationale
4.3.1 Security objectives coverage
The following table provides a mapping of TOE objectives to threats and policies, showing that each
objective counters or enforces at least one threat or policy, respectively.
Threats / OSPs
Objective
T.UAUSER
O.AUTHORIZATION
T.ACCESS
O.ACCESS
P.ACCOUNTABILITY
O.AUDITING
T.DIFFER
O.CONSISTENCY
Table 2: Mapping of security objectives to threats and policies
The following table provides a mapping of the objectives for the Operational Environment to
assumptions, threats and policies, showing that each objective holds, counters or enforces at least
one assumption, threat or policy, respectively.
Assumptions / Threats / OSPs
Objective
A.ADMIN
OE.ADMIN
A.SYSTEM
P.ACCOUNTABILITY
OE.SYSTEM
A.ADMIN
A.CLUSTER
A.PEER
OE.INSTALL
A.PROTECT
OE.PHYSICAL
A.ADMIN
OE.RECOVER
A.DEVEL
OE.DEVEL
Table 3: Mapping of security objectives for the Operational Environment to assumptions,
threats and policies
Page 23 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
4.3.2 Security objectives sufficiency
The following rationale provides justification that the security objectives are suitable to counter
each individual threat and that each security objective tracing back to a threat, when achieved,
actually contributes to the removal, diminishing or mitigation of that threat:
Rationale for security objectives
Threat
The threat of impersonization of an authorized user by an attacker is
sufficiently diminished by O.AUTHORIZATION requiring proper
authorization of users gaining access to the TOE. The access control
attributes are protected by the environment to be accessible to the
administrator only.
T.UAUSER
The threat of an authorized user of the TOE accessing information
resources without the permission from the user responsible for the
resource is removed by O.ACCESS requiring access control for resources
T.ACCESS
and the ability for authorized users to specify the access to their
resources. This ensures that a user can access a resource only if the
requested type of access has been granted by the user responsible for
the management of access rights to the resource.
The threat of user data and TSF data being inconsistent among different
parts of the TOE is diminished by the functionality provided by
O.CONSISTENCY requiring that a mechanism is enforced that ensures
the consistency of the data.
T.DIFFER
Table 4: Sufficiency of objectives countering threats
The following rationale provides justification that the security objectives for the environment are
suitable to cover each individual assumption, that each security objective for the environment that
traces back to an assumption about the environment of use of the TOE, when achieved, actually
contributes to the environment achieving consistency with the assumption, and that if all security
objectives for the environment that trace back to an assumption are achieved, the intended usage
is supported:
Rationale for security objectives
Assumption
The assumption on physical protection of all hard- and software as well
as the network and peripheral cabling is covered by the objectives
OE.PHYSICAL requiring physical protection.
A.PROTECT
The assumption on competent administrators is covered by OE.ADMIN
requiring competent and trustworthy administrators and OE.INSTALL
requiring procedures for secure distribution, installation and configuration
A.ADMIN
of systems as well as OE.RECOVER requiring the administrator to perform
all the required actions to bring the TOE into a secure state after a system
failure or discontinuity.
The assumption on developers of applications executed by the TOE to
be trustworthy and to comply with the instructions set forth in the
guidance is covered by OE.DEVEL requiring the administrator to ensure
that these developers are indeed trustworthy.
A.DEVEL
Page 24 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Rationale for security objectives
Assumption
The assumption that the environment the TOE relies on to enforce its
functionality (the OS and the Java virtual machine) is configured
according to the guidance provided by the TOE is covered by OE.SYSTEM
requiring the administrator to comply with that guidance.
A.SYSTEM
The assumption that the cluster network is physically protected is covered
by OE.INSTALL requiring the administrator to install the TOE in a secure
manner.
A.CLUSTER
The assumption on the same management control and security policy
constraints for systems with which the TOE communicates is covered
by OE.INSTALL requiring procedures for secure distribution, installation
and configuration of the networked system.
A.PEER
Table 5: Sufficiency of objectives holding assumptions
The following rationale provides justification that the security objectives are suitable to cover each
individual organizational security policy, that each security objective that traces back to an OSP,
when achieved, actually contributes to the implementation of the OSP, and that if all security
objectives that trace back to an OSP are achieved, the OSP is implemented:
Rationale for security objectives
OSP
The policy to provide a means to hold users accountable for their
activities is implemented by O.AUDITING providing the TOE with such
functionality. To generate appropriate audit entries, OE.SYSTEM ensures
that the underlying system provides the time stamp for any action to
be audited.
P.ACCOUNTABILITY
Table 6: Sufficiency of objectives enforcing Organizational Security Policies
Page 25 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
5 Extended Components Definition
The Security Target defines the extended component FDP_ROL.2-jb as part of the FDP_ROL family
in CC Part 2 for usage within this ST.
5.1 Class FDP: User data protection
5.1.1 (ROL)
Component levelling
The SFR is not hierarchical to any other SFR out of the family of FDP_ROL.
Management: FDP_ROL.2-jb
The following actions could be considered for the management functions in FMT:
a) The boundary limit to which rollback may be performed could be configurable item within
the TOE.
Audit: FDP_ROL.2-jb
The following actions should be auditable if FAU_GEN Security audit data generation is included in
the PP/ST:
a) Minimal: Please see the audit information on the FDP_ROL family in CC Part 2.
b) Basic: Please see the audit information on the FDP_ROL family in CC Part 2.
c) Detailed: Please see the audit information on the FDP_ROL family in CC Part 2.
5.1.1.1 FDP_ROL.2-jb - Automated rollback
No other components.
Hierarchical to:
No dependencies.
Dependencies:
The TSF shall perform an automated rollback of all the operations [assignment: list
of sub-operations belonging to one operation] when [assignment: list of
causes for a rollback of all operations] .
FDP_ROL.2-
JB.1
Rationale
The SFR of FDP_ROL.2-jb is intended to specify an automated rollback of operations by the TOE.
Automated rollback addresses the need to roll back or undo all operations within the defined bounds.
Page 26 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6 Security Requirements
6.1 TOE Security Functional Requirements
The following table shows the Security functional requirements for the TOE, and the operations
performed on the components according to CC part 2: iteration (Iter.), refinement (Ref.), assignment
(Ass.) and selection (Sel.).
Operations
Source
Base
security
functional
component
Security functional requirement
Security
functional
group Sel.
Ass.
Ref.
Iter.
Yes
Yes
No
No
CC Part 2
FAU_GEN.1 Audit data generation
FAU - Security
audit
No
No
No
No
CC Part 2
FAU_GEN.2 User identity association
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(1) HTTP Access Control
Policy
FDP - User data
protection
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(2) EJB Access Control
Policy
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(3) JMS Access Control
Policy
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(4) Webservices Access
Control Policy
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(5) JMX Invokers Access
Control Policy
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(1) HTTP Access Control
Functions
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(2) EJB Access Control
Functions
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(3) JMS Access Control
Functions
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(4) Webservices Access
Control Functions
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(5) JMX Invokers Access
Control Functions
No
Yes
No
No
ECD
FDP_ROL.2-jb Automated rollback
No
Yes
No
No
CC Part 2
FIA_ATD.1 User attribute definition
FIA - Identification
and
authentication No
Yes
Yes
No
CC Part 2
FIA_UAU.1 Timing of authentication
No
Yes
Yes
No
CC Part 2
FIA_UID.1 Timing of identification
No
Yes
No
No
CC Part 2
FIA_USB.1 User-subject binding
Page 27 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Operations
Source
Base
security
functional
component
Security functional requirement
Security
functional
group Sel.
Ass.
Ref.
Iter.
Yes
Yes
No
No
CC Part 2
FMT_MSA.1 Management of object
security attributes
FMT - Security
management
Yes
Yes
Yes
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(1) Static attribute initial
isation
Yes
Yes
Yes
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(2) Static attribute initial
isation
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(3) Static attribute initial
ization
Yes
Yes
No
Yes
CC Part 2
FMT_MTD.1
FMT_MTD.1(ACC) Management of
TSF data
Yes
Yes
No
Yes
CC Part 2
FMT_MTD.1
FMT_MTD.1(AUTH) Management of
TSF data
No
Yes
No
No
CC Part 2
FMT_SMF.1 Specification of manage
ment functions
No
Yes
No
No
CC Part 2
FMT_SMR.1 Security roles
No
Yes
No
No
CC Part 2
FPT_TRC.1 Internal TSF consistency
FPT - Protection of
the TSF
Table 7: Security functional requirements for the TOE
6.1.1 Security audit (FAU)
6.1.1.1 Audit data generation (FAU_GEN.1)
The TSF shall be able to generate an audit record of the following auditable events:
FAU_GEN.1.1
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit; and
c) Each access request for each access control policy;
The TSF shall record within each audit record at least the following information:
FAU_GEN.1.2
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, no additional information.
Application Note: The subject identity is defined by container and thread ID.
Page 28 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.1.2 User identity association (FAU_GEN.2)
For audit events resulting from actions of identified users, the TSF shall be able
to associate each auditable event with the identity of the user that caused the
event.
FAU_GEN.2.1
6.1.2 User data protection (FDP)
6.1.2.1 HTTP Access Control Policy (FDP_ACC.1(1))
The TSF shall enforce the HTTP Access Control policy on
Subject: a user represented by a Principal or Subject object assigned to
a specific role represented by the Group object
FDP_ACC.1.1
Object: data accessible at URL
Operations: all HTTP methods of GET, POST, PUT, TRACE, DELETE, HEAD
.
Application Note: Access control is managed with appropriate settings in the deployment descriptor
of web.xml.
6.1.2.2 EJB Access Control Policy (FDP_ACC.1(2))
The TSF shall enforce the EJB Access Control policy on
Subject: a user represented by a Principal or Subject object assigned to
a specific role represented by the Group object
FDP_ACC.1.1
Objects: EJB and associated method
Operations: calling the method of the EJB
.
Application Note: Access control is managed with appropriate settings in the deployment descriptor
ejb-jar.xml (EJB 2.x and EJB 3) and the “@RolesAllowed”, “@DenyAll”, “@PermitAll” Java Annotations
in the Java source code of the affected EJB (EJB 3).
6.1.2.3 JMS Access Control Policy (FDP_ACC.1(3))
The TSF shall enforce the JMS Access Control policy on
Subject: a user represented by a Principal or Subject object assigned to
a specific role represented by the Group object
FDP_ACC.1.1
Objects: message queue, topic
Operations: read, write, create operations on a message queue or topic
.
Application Note: Access control is managed with appropriate settings in the deployment
descriptors messaging-service.xml (for the global default values applicable to destinations without
specific security configurations) and destinations-service.xml (for individual message queue or
topic destination configurations overriding the global default values).
Page 29 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Application Note: Message queues and topics are communication facilities allowing different
subject to exchange information.
6.1.2.4 Webservices Access Control Policy (FDP_ACC.1(4))
The TSF shall enforce the Webservices Access Control policy on
Subject: a user represented by a Principal or Subject object assigned to
a specific role represented by the Group object
FDP_ACC.1.1
Objects: Plain old Java Objects (POJOs) (deployed as Servlets) and Session
Beans
Operations: all SOAP requests
.
Application Note: Access control is managed with appropriate settings in the deployment descriptor
web.xml (servlets).
6.1.2.5 JMX Invokers Access Control Policy (FDP_ACC.1(5))
The TSF shall enforce the JMX Invokers Access Control policy on
Subjects: a user represented by a Principal or Subject object assigned
to a specific role represented by the Group object
FDP_ACC.1.1
Objects: JMX Invokers
Operations: calling any method of the MBeanServer
.
Application Note: Access control is managed with appropriate settings in the deployment descriptor
jmx-invoker-service.xml.
6.1.2.6 HTTP Access Control Functions (FDP_ACF.1(1))
The TSF shall enforce the HTTP Access Control Policy to objects based on the
following:
FDP_ACF.1.1
a) Subject attributes: Roles
b) Object attributes: URL, roles
.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
Access to the URL with the requested HTTP method is permitted if:
FDP_ACF.1.2
a) the requesting user is associated with a role specified for the URL
and HTTP method in the “security-constraint” element defined
in the deployment descriptor web.xml;
b) the transport layer security used when accessing the URL must
cover at least that security mechanism defined by the
“user-data-constraint” element defined in the deployment
descriptor web.xml for the accessed URL, requiring either no
protection, integrity protection or confidentiality protection
Page 30 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
.
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: permission rules marked with the “unchecked”
element instead of the “role-name” element define that any
authenticated user can access the URL.
FDP_ACF.1.3
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: none.
FDP_ACF.1.4
Application Note: Application developers have the possibility to define additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
defined in this SFR. Therefore, these additional access control mechanisms are allowed to be used
although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
6.1.2.7 EJB Access Control Functions (FDP_ACF.1(2))
The TSF shall enforce the EJB Access Control Policy to objects based on the
following:
FDP_ACF.1.1
a) Subject attributes: Roles
b) Object attributes: EJB name and associated method name, roles
.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
Access to the EJB method is permitted if the requesting user is associated
with a role specified for the EJB method in the “method-permission”
element defined in the deployment descriptor ejb-jar.xml.
FDP_ACF.1.2
For EJB3, the permission may also be specified with the “@Permissions”
Java annotation.
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: permission rules marked with the “unchecked”
element instead of the “role-name” element define that any
FDP_ACF.1.3
authenticated user can access the EJB method. For EJB3, classes,
methods and constants marked with the “@Unchecked” Java annotation
can be accessed by any authenticated users.
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: methods marked with the “exclude-list” element are
always denied access to. For EJB3, methods marked with the “@Exclude”
Java annotation are always denied access to.
FDP_ACF.1.4
Application Note: Application developers have the possibility to define additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
defined in this SFR. Therefore, these additional access control mechanisms are allowed to be used
although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
Page 31 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.2.8 JMS Access Control Functions (FDP_ACF.1(3))
The TSF shall enforce the JMS Access Control Policy to objects based on the
following:
FDP_ACF.1.1
a) Subject attributes: Roles
b) Object attributes: message queue name, topic name, roles
.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: Access to the message
queue or topic is permitted if the requesting user is associated with a
role specified for the respective communication facility based on the
following rules:
FDP_ACF.1.2
a) If the read attribute is true then that role will be able to read
(create consumers, receive messages or browse) this destination.
b) If the write attribute is true then that role will be able to write
(create producers or send messages) to this destination.
c) If the create attribute is true then that role will be able to create
durable subscriptions on this destination.
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.3
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: none.
FDP_ACF.1.4
6.1.2.9 Webservices Access Control Functions (FDP_ACF.1(4))
The TSF shall enforce the Webservices Access Control Policy to objects based
on the following:
FDP_ACF.1.1
a) Subject attributes: Roles
b) Object attributes: URL, POJO method name, roles
.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: Access to the URL with
the requested HTTP method is permitted if:
FDP_ACF.1.2
a) The requesting user is associated with a role specified for the
POJO in the “jboss-ws-security” element defined in the file
jboss-web.xml;
b) The role associated with the user calling the POJO method is
permitted if the role is specified for the POJO method in the
“jboss-ws-security” element defined in the file jboss-web.xml;
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: permission rules marked with the “unchecked”
element instead of the “role-name” element define that:
FDP_ACF.1.3
a) any authenticated user can access the URL
b) any authenticated user can access the POJO method (defined in
jboss-web.xml).
.
Page 32 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: no rules.
FDP_ACF.1.4
Application Note: Application developers have the possibility to define additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
defined in this SFR. Therefore, these additional access control mechanisms are allowed to be used
although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
6.1.2.10 JMX Invokers Access Control Functions (FDP_ACF.1(5))
The TSF shall enforce the JMX Invokers Access Control Policy to objects based
on the following:
FDP_ACF.1.1
a) Subject attributes: Roles
b) Object attributes: none (every MBeanServer method is
unconditionally allowed if the subject is associated with the
appropriate role)
.
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
FDP_ACF.1.2
a) If the “org.jboss.jmx.connector.invoker.RolesAuthorization” class
is configured for the interceptor class
“org.jboss.jmx.connector.invoker.AuthorizationInterceptor”: The
access request to any MBeanServer method is permitted if the
subject is associated with the “JBossAdmin” role.
b) If the
“org.jboss.jmx.connector.invoker.ExternalizableRolesAuthorization”
class is configured for the interceptor class
“org.jboss.jmx.connector.invoker.AuthorizationInterceptor”: The
access request to any MBeanServer method is permitted if the
subject is associated with the one of the roles specified in the
“jmx-invoker-roles.properties”.
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.3
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: none.
FDP_ACF.1.4
Application Note: Application developers have the possibility to define additional access control
rules in the deployment descriptors applicable to their applications. The TOE provides mechanisms
like ACLs which can be used to provide additional access restrictions. However, these additional
access control mechanisms can only add additional restrictions without violating the restrictions
defined in this SFR. Therefore, these additional access control mechanisms are allowed to be used
although not attributed with security claims in this ST and therefore outside the scope of the
evaluation.
Page 33 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.2.11 Automated rollback (FDP_ROL.2-jb)
The TSF shall perform an automated rollback of all the operations defined to
form one transaction when at least one operation part of a transaction
fails.
FDP_ROL.2-jb.1
6.1.3 Identification and authentication (FIA)
6.1.3.1 User attribute definition (FIA_ATD.1)
The TSF shall maintain the following list of security attributes belonging to
individual users:
FIA_ATD.1.1
a) Subject identity;
b) Role;
c) Password, if the services of HTTP (basic, digest and form-based
authentication), EJB, JMS, Webservice are available to the user;
d) X.509 Certificate if the certificate-based authentications services
of HTTP, EJB, JMS, Webservice are available to the user.
.
Application Note: The TOE allows the definition of user attributes, especially the definition of
roles at multiple places: static security domain configuration in login-config.xml, dynamic security
domain configurations in *-jboss-beans.xml, security-role element in jboss.xml or jboss-web.xml,
Java annotations.
6.1.3.2 Timing of authentication (FIA_UAU.1)
The TSF shall allow the following actions on behalf of the user to be performed
before the user is authenticated:
FIA_UAU.1.1
1. All actions allowed by the access control mechanisms for the identity
assigned to unauthenticated users with the element
“DefaultUnauthenticatedPrincipal” configured for the
JaasSecurityManagerService.
2. All actions allowed by the access control mechanism to unsecured EJBs
or EJB methods that are associated with the unchecked permission
constraint for the identity assigned to unauthenticated users with the
“unauthenticatedIdentity” element in the login module configuration.
3. All URLs (i) without a “security-constraint” element defined in the web.xml
deployment descriptor or (ii) without the “@RolesAllowed” and without
the “@DenyAll” Java Annotations defined for EJB 3 servlets are accessible
to unauthenticated users.
The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
FIA_UAU.1.2
Page 34 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.3.3 Timing of identification (FIA_UID.1)
The TSF shall allow the following actions on behalf of the user to be performed
before the user is identified:
FIA_UID.1.1
1. All actions allowed by the access control mechanisms for the identity
assigned to unauthenticated users with the element
“DefaultUnauthenticatedPrincipal” configured for the
JaasSecurityManagerService.
2. All actions allowed by the access control mechanism to unsecured EJBs
or EJB methods that are associated with the unchecked permission
constraint for the identity assigned to unauthenticated users with the
“unauthenticatedIdentity” element in the login module configuration.
3. All URLs (i) without a “security-constraint” element defined in the web.xml
deployment descriptor or (ii) without the “@RolesAllowed” and without
the “@DenyAll” Java Annotations defined for EJB 3 servlets are accessible
to unauthenticated users.
The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
FIA_UID.1.2
6.1.3.4 User-subject binding (FIA_USB.1)
The TSF shall associate the following user security attributes with subjects acting
on the behalf of that user:
FIA_USB.1.1
a) Subject identity associated with auditable events;
b) Role the user is operating with
.
The TSF shall enforce the following rules on the initial association of user security
attributes with subjects acting on the behalf of users:
FIA_USB.1.2
a) Upon successful identification and authentication, the user identity
shall be that specified in the user entry for the user that has
authenticated.
b) The role associated with a subject shall be one of the authorized
roles assigned to the user.
The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users:
FIA_USB.1.3
a) run-as: The security role defined with the run-as element in a
deployment descriptor is used for the execution of the component
defined with that deployment descriptor.
b) run-as-principal: The identity (principal) defined with the
run-as-principal element in a deployment descriptor is used for
the execution of the component defined with that deployment
descriptor.
.
Page 35 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
6.1.4 Security management (FMT)
6.1.4.1 Management of object security attributes (FMT_MSA.1)
The TSF shall enforce the JMS Access Control Policy to restrict the ability to
modify the security attributes of the default value of the SFP to the
authorized administrator.
FMT_MSA.1.1
6.1.4.2 Static attribute initialisation (FMT_MSA.3(1))
The TSF shall enforce the HTTP Access Control Policy, Webservices Access
Control Policy to provide permissive default values for security attributes that
are used to enforce the SFP.
FMT_MSA.3.1
The TSF shall allow thenobody to specify alternative initial values to override
the default values when an object or information is created.
FMT_MSA.3.2
Application Note: The default values are hard-coded and cannot be changed.
6.1.4.3 Static attribute initialisation (FMT_MSA.3(2))
The TSF shall enforce the EJB Access Control Policy, and JMX Invoker Access
Control Policy to provide restrictive default values for security attributes that
are used to enforce the SFP.
FMT_MSA.3.1
The TSF shall allow thenobody to specify alternative initial values to override
the default values when an object or information is created.
FMT_MSA.3.2
Application Note: The default values are hard-coded and cannot be changed.
6.1.4.4 Static attribute initialization (FMT_MSA.3(3))
The TSF shall enforce the JMS Access Control Policy to provide restrictive
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.1
The TSF shall allow the authorized administrator to specify alternative initial
values to override the default values when an object or information is created.
FMT_MSA.3.2
Application Note: The default behavior for message queue or topic destinations is defined with
the JBoss Messaging service deployment descriptor in messaging-service.xml by using the element
“attribute” with the name “DefaultSecurityConfig” which has the same structure as defined in
FDP_ACC.1(3) and FDP_ACF.1(3).
Application Note: This SFR specifies the management of the default value. For protecting the
default value, the TOE relies on the environment to protect the deployment descriptor file holding
the default value. As only authorized administrators are able to access the system hosting the TOE
as assumed with A.PROTECT, the protection of the deployment descriptor is ensured.
6.1.4.5 Management of TSF data (FMT_MTD.1(ACC))
The TSF shall restrict the ability to modify the access control settings for the
HTTP Access Control Policy, EJB Access Control Policy, JMS Access Control
Policy, Webservices Access Control Policy, JMX Invoker Access Control
Policy to the authorized administrator.
FMT_MTD.1.1
Page 36 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Application Note: The access control policies are defined in the deployment descriptor or other
locations for each application as referenced in the application notes for each FDP_ACC.1 iteration.
6.1.4.6 Management of TSF data (FMT_MTD.1(AUTH))
The TSF shall restrict the ability to modify the user account settings for the
HTTP Access Control Policy, EJB Access Control Policy, JMS Access Control
Policy, Webservices Access Control Policy, JMX Invoker Access Control
Policy to the authorized administrator.
FMT_MTD.1.1
Application Note: The access control policies are defined in the deployment descriptor or other
locations for each application as referenced in the application notes for each FDP_ACC.1 iteration.
6.1.4.7 Specification of management functions (FMT_SMF.1)
The TSF shall be capable of performing the following management functions:
FMT_SMF.1.1
a) Management of access control policies;
b) Management of default value for JMS access control policy;
6.1.4.8 Security roles (FMT_SMR.1)
The TSF shall maintain the roles:
FMT_SMR.1.1
a) Authorized administrator
b) Users utilizing the services of applications maintained by the TSF
The TSF shall be able to associate users with roles.
FMT_SMR.1.2
Application Note: Administrative actions can only be performed when access to the host system
with the right to access the TOE files, including the deployment descriptors, is granted to a user.
In addition, access to any TOE service is allowed to authorized administrators only. Users are only
allowed access to applications hosted by the TOE and which are developed by trused developers.
6.1.5 Protection of the TSF (FPT)
6.1.5.1 Internal TSF consistency (FPT_TRC.1)
The TSF shall ensure that TSF data is consistent when replicated between parts
of the TOE.
FPT_TRC.1.1
When parts of the TOE containing replicated TSF data are disconnected, the TSF
shall ensure the consistency of the replicated TSF data upon reconnection before
processing any requests for
FPT_TRC.1.2
a) Identification and authentication
b) Access control
c) Execution of operations for:
1. HTTP requests
2. EJB requests
3. JMS requests
4. Webservices requests
.
Page 37 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Application Note: This SFR covers the cluster communication that synchronizes the runtime state
of the different cluser nodes.
6.2 Security Functional Requirements Rationale
6.2.1 Security requirements coverage
The following table provides a mapping of SFR to the security objectives, showing that each security
functional requirement addresses at least one security objective.
Objectives
Security Functional Requirements
O.AUDITING
FAU_GEN.1
O.AUDITING
FAU_GEN.2
O.ACCESS
FDP_ACC.1(1)
O.ACCESS
FDP_ACC.1(2)
O.ACCESS
FDP_ACC.1(3)
O.ACCESS
FDP_ACC.1(4)
O.ACCESS
FDP_ACC.1(5)
O.ACCESS
FDP_ACF.1(1)
O.ACCESS
FDP_ACF.1(2)
O.ACCESS
FDP_ACF.1(3)
O.ACCESS
FDP_ACF.1(4)
O.ACCESS
FDP_ACF.1(5)
O.CONSISTENCY
FDP_ROL.2-jb
O.ACCESS,
O.AUTHORIZATION
FIA_ATD.1
O.AUTHORIZATION
FIA_UAU.1
O.AUTHORIZATION
FIA_UID.1
O.ACCESS,
O.AUTHORIZATION
FIA_USB.1
O.ACCESS,
O.AUTHORIZATION
FMT_MSA.1
O.ACCESS,
O.AUTHORIZATION
FMT_MSA.3(1)
O.ACCESS,
O.AUTHORIZATION
FMT_MSA.3(2)
Page 38 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Objectives
Security Functional Requirements
O.ACCESS,
O.AUTHORIZATION
FMT_MSA.3(3)
O.ACCESS
FMT_MTD.1(ACC)
O.AUTHORIZATION
FMT_MTD.1(AUTH)
O.ACCESS,
O.AUTHORIZATION
FMT_SMF.1
O.ACCESS,
O.AUTHORIZATION
FMT_SMR.1
O.CONSISTENCY
FPT_TRC.1
Table 8: Mapping of security functional requirements to security objectives
6.2.2 Security requirements sufficiency
The following rationale provides justification for each security objective for the TOE, showing that
the security functional requirements are suitable to meet and achieve the security objectives:
Rationale
Security objectives
The TSF must ensure that only authorized users gain access to the TOE
and its resources. Users authorized to access the TOE have to use an
identification and authentication process [FIA_UID.1, FIA_UAU.1]. To
O.AUTHORIZATION
ensure authorized access to the TOE, authentication data is protected
[FIA_ATD.1]. Proper authorization for subjects acting on behalf of users
is also ensured [FIA_USB.1].
The management of the authorizations is specified in [FMT_MTD.1(AUTH),
FMT_SMF.1, FMT_SMR.1].
The default value for the JMS access control policy is modifiable as
specified with [FMT_MSA.3(3) and FMT_MSA.1]. Nobody is able to control
which default values are configured for the remaining access control
mechanisms [FMT_MSA.3(1), FMT_MSA.3(2)]. Please note that the default
values have an impact on the authorization, as a permissive default
value allows access to the resource without I&A.
The different access control mechanisms must have a defined scope of
control [all iterations of FDP_ACC.1]. The rules of the different access
control mechanisms must be defined [all iterations of FDP_ACF.1]. The
security attributes of subjects used to enforce the different access control
mechanisms must be defined [FIA_ATD.1, FIA_USB.1].
O.ACCESS
The management of the access control settings is specified in
[FMT_MTD.1(ACC), FMT_SMF.1, FMT_SMR.1].
The default value for the JMS access control policy is modifiable as
specified with [FMT_MSA.3(3) and FMT_MSA.1]. Nobody is able to control
which default values are configured for the remaining access control
mechanisms [FMT_MSA.3(1), FMT_MSA.3(2)].
Page 39 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Rationale
Security objectives
The events to be audited must be defined [FAU_GEN.1], and must be
associated with the identity of the user that caused the event
[FAU_GEN.2].
O.AUDITING
To ensure the consistency of user data, the TSF allows the definition of
transactions where each operation of the transaction must succeed for
the transaction to succeed or otherwise all operations already performed
O.CONSISTENCY
for the transaction are rolled back [FDP_ROL.2-jb]. In addition, to ensure
the consistency of TSF data when held in multiple locations of different
cluster nodes, the TSF implements a cluster communication that updates
the TSF data in the appropriate cluster nodes when one node updates
these TSF data [FPT_TRC.1].
Table 9: Security objectives for the TOE rationale
In addition, the following listing demonstrates the internal consistency of the SFRs:
Access Control policies
The different iterations of FDP_ACC.1 require the existence of a different access control for
the different objects present in the TOE. The rules of these policies are described in the
respective iterations of FDP_ACF.1. To be effective an access control mechanism requires
users to be properly identified and authenticated (as required by FIA_UID.1 and FIA_UAU.1),
proper binding of subjects to users (as required by FIA_USB.1). FMT_MSA.3(1), FMT_MSA.3(2),
and FMT_MSA.3(3) define the default permissions for the different access control mechanisms.
The management of access control settings specified in FMT_MSA.1, and FMT_MTD.1(ACC)
as well as account settings with FMT_MTD.1(AUTH) support the access control policies.
Audit
FAU_GEN.1 defines the events that the TOE is required to be able to audit. Those events
are related to other security functional requirements showing which event contributes to
make users accountable for their actions with respect to the requirement. FAU_GEN.2 requires
that the events are associated with the identity of the user that caused the event. Of course
this can only be done if the user is known (which may not be the case for failed login
attempts).
Clustering
FPT_TRC.1 defines the replication mechanism to keep different parts of the TOE (the different
nodes of a cluster) consistent with each other. This SFR ensures that all TSF data, including
that required for the other SFRs are maintained consistently between the cluster nodes.
Identification and Authentication
As stated above Identification and Authentication is required for useful access control policies
based on the identity and roles of individual users. FIA_UAU.1 and FIA_UID.1 require that
users are authenticated before they can perform actions on the TOE requiring the identity
of the user. Since the TOE implements threads acting on behalf of the user, FIA_USB.1
ensures that those processes act within the limits defined for the user they are acting for
(unless they are trusted to perform activities beyond the rights of the user). To allow the
TOE to assign the proper identifiers to subjects acting on behalf of users, FIA_ATD.1 defines
various security attributes for different users.
Page 40 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Transaction Rollback
FDP_ROL.2-jb ensures that an automated rollback of failed transactions is performed by the
TOE. If the TOE identifies that an operation belonging to a transaction fails, all operations
already performed for the transaction are rolled back to the state as if these operations
never happened.
6.2.3 Security requirements dependency analysis
The following table demonstrates the dependencies of SFRs modeled in CC Part 2 and how the SFRs
for the TOE resolve those dependencies:
Resolution
Dependencies
Security
Functional
Requirement
The security functional requirement
FAU_GEN.1 covering audit generation
depends on FPT_STM.1 for gathering the
FPT_STM.1
FAU_GEN.1
date/time stamp for the audit records. This
dependency is uncovered due to CC version
3.1 definition as this version of the CC does
not support the definition of SFRs for the
operational environment. The TOE relies
on the underlying Java virtual machine to
provide the appropriate time stamp. Hence,
due to the definitions of CC 3.1 which does
not allow the specification of SFRs for the
operational environment, this dependency
is unresolved. The functionality of providing
a time stamp is implemented by the
underlying Java virtual machine as defined
by OE.SYSTEM.
FAU_GEN.1
FAU_GEN.1
FAU_GEN.2
FIA_UID.1
FIA_UID.1
FDP_ACF.1(1)
FDP_ACF.1
FDP_ACC.1(1)
FDP_ACF.1(2)
FDP_ACF.1
FDP_ACC.1(2)
FDP_ACF.1(3)
FDP_ACF.1
FDP_ACC.1(3)
FDP_ACF.1(4)
FDP_ACF.1
FDP_ACC.1(4)
FDP_ACF.1(5)
FDP_ACF.1
FDP_ACC.1(5)
FDP_ACC.1(1)
FDP_ACC.1
FDP_ACF.1(1)
FMT_MSA.3(1)
FMT_MSA.3
FDP_ACC.1(2)
FDP_ACC.1
FDP_ACF.1(2)
FMT_MSA.3(2)
FMT_MSA.3
Page 41 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Resolution
Dependencies
Security
Functional
Requirement
FDP_ACC.1(3)
FDP_ACC.1
FDP_ACF.1(3)
FMT_MSA.3(3)
FMT_MSA.3
FDP_ACC.1(4)
FDP_ACC.1
FDP_ACF.1(4)
FMT_MSA.3(1)
FMT_MSA.3
FDP_ACC.1(5)
FDP_ACC.1
FDP_ACF.1(5)
FMT_MSA.3(2)
FMT_MSA.3
No dependencies.
FDP_ROL.2-jb
No dependencies.
FIA_ATD.1
FIA_UID.1
FIA_UID.1
FIA_UAU.1
No dependencies.
FIA_UID.1
FIA_ATD.1
FIA_ATD.1
FIA_USB.1
FDP_ACC.1(3)
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1
FMT_SMR.1
FMT_SMR.1
FMT_SMF.1
FMT_SMF.1
The security functional requirement
FMT_MSA.3 covering the default values for
the different access control policies has a
FMT_MSA.1
FMT_MSA.3(1)
dependency on FMT_MSA.1 and
FMT_SMR.1. The TOE does not implement
the management and the respective
protection of the management of the
access control mechanisms. The access
control mechanisms are configured via XML
files located in the environment. As the
environment is protected against
unauthorized access (A.PROTECT), only
authorized administrators can access these
files to manage the different access control
mechanisms. Therefore, the intent of
FMT_MSA.1 is covered with the setup of the
TOE and its environment.
As explained, the management of the
access control mechanism is not covered
by the TOE. Hence, FMT_SMR.1 is
appropriately excluded.
FMT_SMR.1
Page 42 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Resolution
Dependencies
Security
Functional
Requirement
The security functional requirement
FMT_MSA.3 covering the default values for
the different access control policies has a
FMT_MSA.1
FMT_MSA.3(2)
dependency on FMT_MSA.1 and
FMT_SMR.1. The TOE does not implement
the management and the respective
protection of the management of the
access control mechanisms. The access
control mechanisms are configured via XML
files located in the environment. As the
environment is protected against
unauthorized access (A.PROTECT), only
authorized administrators can access these
files to manage the different access control
mechanisms. Therefore, the intent of
FMT_MSA.1 is covered with the setup of the
TOE and its environment.
As explained, the management of the
access control mechanism is not covered
by the TOE. Hence, FMT_SMR.1 is
appropriately excluded.
FMT_SMR.1
FMT_MSA.1
FMT_MSA.1
FMT_MSA.3(3)
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_MTD.1(ACC)
FMT_SMF.1
FMT_SMF.1
FMT_SMR.1
FMT_SMR.1
FMT_MTD.1(AUTH)
FMT_SMF.1
FMT_SMF.1
No dependencies.
FMT_SMF.1
FIA_UID.1
FIA_UID.1
FMT_SMR.1
Page 43 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Resolution
Dependencies
Security
Functional
Requirement
The security functional requirement
FPT_TRC.1 covering the cluster
communication has a dependency on
FPT_ITT.1
FPT_TRC.1
FPT_ITT.1. The TOE does not rely on the
technical implementation of the protection
of the data channels between different TOE
instances as the network utilized for the
cluster communication covered by
FPT_TRC.1 is physically separated from any
other network. In addition, the base
operating system is configured to not
permit any routing from any attached
network into the physically separated
network used for the cluster
communication. Thus, the requirement of
FPT_ITT.1 is covered with non-technical
means.
Table 10: TOE SFR dependency analysis
6.3 Security Assurance Requirements
The security assurance requirements for the TOE are the Evaluation Assurance Level 4 components
as specified in [CC] part 3, augmented by ALC_FLR.3.
The following table shows the Security assurance requirements, and the operations performed on
the components according to CC part 3: iteration (Iter.), refinement (Ref.), assignment (Ass.) and
selection (Sel.).
Operations
Source
Security assurance requirement
Security
assurance class
Sel.
Ass.
Ref.
Iter.
No
No
No
No
CC Part 3
ADV_ARC.1 Security architecture description
ADV Development
No
No
No
No
CC Part 3
ADV_FSP.4 Complete functional specification
No
No
No
No
CC Part 3
ADV_IMP.1 Implementation representation of the
TSF
No
No
No
No
CC Part 3
ADV_TDS.3 Basic modular design
No
No
No
No
CC Part 3
AGD_OPE.1 Operational user guidance
AGD Guidance
documents
No
No
No
No
CC Part 3
AGD_PRE.1 Preparative procedures
No
No
No
No
CC Part 3
ALC_CMC.4 Production support, acceptance proce
dures and automation
ALC Life-cycle
support
No
No
No
No
CC Part 3
ALC_CMS.4 Problem tracking CM coverage
Page 44 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Operations
Source
Security assurance requirement
Security
assurance class
Sel.
Ass.
Ref.
Iter.
No
No
No
No
CC Part 3
ALC_DEL.1 Delivery procedures
No
No
No
No
CC Part 3
ALC_DVS.1 Identification of security measures
No
No
No
No
CC Part 3
ALC_FLR.3 Systematic flaw remediation
No
No
No
No
CC Part 3
ALC_LCD.1 Developer defined life-cycle model
No
No
No
No
CC Part 3
ALC_TAT.1 Well-defined development tools
No
No
No
No
CC Part 3
ASE_INT.1 ST introduction
ASE Security
Target evaluation
No
No
No
No
CC Part 3
ASE_CCL.1 Conformance claims
No
No
No
No
CC Part 3
ASE_SPD.1 Security problem definition
No
No
No
No
CC Part 3
ASE_OBJ.2 Security objectives
No
No
No
No
CC Part 3
ASE_ECD.1 Extended components definition
No
No
No
No
CC Part 3
ASE_REQ.2 Derived security requirements
No
No
No
No
CC Part 3
ASE_TSS.1 TOE summary specification
No
No
No
No
CC Part 3
ATE_COV.2 Analysis of coverage
ATE Tests
No
No
No
No
CC Part 3
ATE_DPT.1 Testing: basic design
No
No
No
No
CC Part 3
ATE_FUN.1 Functional testing
No
No
No
No
CC Part 3
ATE_IND.2 Independent testing - sample
No
No
No
No
CC Part 3
AVA_VAN.3 Focused vulnerability analysis
AVA Vulnerability
assessment
Table 11: Security assurance requirements
6.4 Security Assurance Requirements Rationale
The evaluation assurance level commensurate with the threat environment that is experienced by
typical consumers of the TOE. In addition, the evaluation assurance level augmented with ALC_FLR.3
commensurate with the augmented flaw remediation capabilities offered by the developer beyond
those required by the evaluation assurance level.
Page 45 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
7 TOE Summary Specification
7.1 TOE Security Functionality
The following section explains how the security functions are implemented. The different TOE
security functions cover the various SFR classes.
The primary security features of the TOE are:
●
Access Control
●
Audit
●
Clustering
●
Identification and Authentication
●
Transaction Rollback
7.1.1 Access Control
Using access control, the TOE is able to restrict access for the following request types with the
following access control mechanisms:
●
HTTP: URLs and paths provided with URLs can be protected from access by subjects:
❍
Obtain the names of the roles allowed to access the URL. The role names are
determined by the “security-constraint” elements defined for the invoked URL and
optionally the HTTP request method (one or more of the following: GET, POST, PUT,
TRACE, DELETE, HEAD) as part of the HTTP deployment descriptor. In addition to the
specification of the URL and HTTP request method, the access control mechanism
can optionally require cryptographic protection of the user’s connection (either none,
integrity-protected, confidentiality-protected).
❍
If no roles have been assigned, or the method is specified in an exclude-list element,
then access to the URL is allowed. Otherwise, the doesUserHaveRole method is
invoked on the JBossSX security manager by the security interceptor to see if the
caller has one of the assigned role names. This method iterates through the role
names and checks if the authenticated user's Subject Roles group contains a
SimplePrincipal with the assigned role name. Access is allowed if any role name is a
member of the Roles group. Access is denied if none of the role names are members.
●
EJB: EJBs and associated method names can be protected from being called by subjects:
❍
Obtain the names of the roles allowed to access the EJB method from the EJB
container. The role names are determined by the “role-name” elements of all
“method-permission” elements containing the invoked method as defined in the EJB
deployment descriptor.
❍
If no roles have been assigned, or the method is specified in an exclude-list element,
then access to the method is denied. Otherwise, the doesUserHaveRole method is
invoked on the JBossSX security manager by the security interceptor to see if the
caller has one of the assigned role names. This method iterates through the role
names and checks if the authenticated user's Subject Roles group contains a
SimplePrincipal with the assigned role name. Access is allowed if any role name is a
member of the Roles group. Access is denied if none of the role names are members.
Page 46 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
❍
If the EJB was configured with a custom security proxy, the method invocation is
delegated to it. If the security proxy wants to deny access to the caller, it will throw
a java.lang.SecurityException. If no SecurityException is thrown, access to the EJB
method is allowed and the method invocation passes to the next container interceptor.
Note that the SecurityProxyInterceptor handles this check.
●
JMS: Message queue destinations and topic destinations can be protected from access by
subjects:
❍
Obtain the names of the roles allowed to access the message queue destination or
topic destination. The role names are determined by the “SecurityConfig” elements
defined for the message queue destination or topic destination deployment descriptor.
❍
The TSF permits to specify a global default access control rule which governs the
access to the destinations if no access control rule is specified for the individual
destination. If no roles have been assigned, or the destinations are not covered by
an access control rule (including no global access control rule is specified), then
access to the method is denied. Otherwise, the doesUserHaveRole method is invoked
on the JBossSX security manager by the security interceptor to see if the caller has
one of the assigned role names. This method iterates through the role names and
checks if the authenticated user's Subject Roles group contains a SimplePrincipal
with the assigned role name. Access is allowed if any role name is a member of the
Roles group. Access is denied if none of the role names are members.
●
Webservices: Plain old Java Objects (POJOs) (deployed as Servlets) and Session Beans can
be protected from access by subjects:
❍
POJOs deployed as servlets are protected the same way as specified for the HTTP
access control. Session Beans are protected the same way as EJB methods.
●
JMX: The JMX invokers can be protected by validating the role of the authenticated user:
❍
Every user who has successfully identified and authenticated and is associated with
one of the roles required to access the JMX invoker is allowed to access the entire
JMX invoker.
❍
The validation of the user being associated with a role can be configured in the XML
descriptor for JMX. The TOE provides two classes where one needs to be selected
configured by the administrator to protect the JMX invokers. One of these classes
validates whether the requesting user is associated with the “JBossAdmin” role. The
other class validates whether the user is associated at least with one role specified
in a configuration file.
The above mentioned network protocols tunnel the client requests to the TOE. After the TOE
performed the I/A and access control checks, the request is forwarded to the intended application.
As the TOE only uses the credential information from the network request, only the aspect of
communicating the user credentials as well as the requested object and the request type is relevant
for the enforcement of the access control policy.
The TOE allows the management of the access control policy independently for each application
and independently and for each policy. The mentioned deployment descriptors, and annotations
can be used by authorized administrators (and developers which belong to the category of authorized
administrators as specified in A.DEVEL) to configure the access control. Note that the TOE provides
the interfaces for managing the access control policies. However, it does not restrict the use of the
interfaces - the restriction is enforced by the environment based on A.PROTECT which ensures that
only authorized administrators are allowed to access the host system.
This security function covers all SFRs mapped to O.ACCESS.
Page 47 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
7.1.2 Audit
The TOE implements an audit mechanism that allows generating audit records for security-relevant
events concerning access control. The administrative user is able to select the events which are
to be audited.
The audit facility is based on the log4j mechanism which is integrated into the TOE. Log4j has three
main components: loggers, appenders and layouts. These three types of components work together
to enable developers to log messages based on message type and level, and to control how these
messages are formatted and where they are reported at runtime.
The audit information is recorded in text files which can be reviewed using tools from the underlying
operating system, such as pagers or editors.
This security function covers all SFRs mapped to O.AUDITING.
7.1.3 Clustering
A cluster is a set of nodes. In a JBoss cluster, a node is a JBoss server instance. Thus, to build a
cluster, several JBoss instances have to be grouped together (known as a "partition").
Clustering allows the execution of applications on several parallel servers (a.k.a cluster nodes).
Two different cluster concepts are possible with JBoss: a failover cluster and a load-distribution
cluster. In both cases, the server state is distributed across different servers, and even if any of
the servers fails, the application is still accessible via other cluster nodes.
The cluster communication establishes the data consistency between the different cluster nodes
of the following information:
●
Replication of applications across the cluster which allows to deploy one application on one
node and the cluster replicates the application to all nodes (farming deployment)
●
Replication of the state of a node covering the replication of HTTP sessions, EJB 3.0 session
beans, EJB 3.0 entity beans, as well as Hibernate persistence objects (distributed state
replication service using JBoss Cache).
JGroups and JBoss Cache provide the underlying communication, node replication and caching
services, for JBoss clusters. Those services are configured as MBeans. There is a set of
JBossCache and JGroups MBeans for each type of clustering applications (e.g., the Stateful
Session EJBs, the distributed entity EJBs etc.).
The JGroups framework provides services to enable peer-to-peer communications between
nodes in a cluster. It is built on top a stack of network communication protocols that provide
transport, discovery, reliability and failure detection, and cluster membership management
services.
JBoss Cache provides distributed cache and state replication services for the JBoss cluster.
A JBoss cluster can have multiple JBoss Cache MBeans (known as the TreeCache MBean),
one for HTTP session replication, one for stateful session beans, one for cached entity beans,
etc.
●
Replication of the state of a node covering the replication of HTTP sessions, and EJB 2.x
session beans (distributed state replication service using HASessionState MBean).
●
Replication of the JNDI state (JBoss HA-JNDI)
Page 48 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
The JBoss clustered JNDI service is based on the client-side interceptor architecture. The
client must obtain a JNDI stub object (via the InitialContext object) and invoke JNDI lookup
services on the remote server through the stub. Furthermore, JNDI is the basis for many
other interceptor-based clustering services: those services register themselves with the JNDI
so that the client can lookup their stubs and make use of their services.
The JBoss HA-JNDI (High Availability JNDI) service maintains a cluster-wide context tree. The
cluster wide tree is always available as long as there is one node left in the cluster. Each
JNDI node in the cluster also maintains its own local JNDI context. The server side application
can bind its objects to either tree.
●
Replication of JMS queues
JBoss Messaging clusters JMS queues and topics transparently across the cluster. Messages
sent to a distributed queue or topic on one node are consumable on other nodes.
This security function covers the SFR FPT_TRC.1.
7.1.4 Identification and authentication
Users are assigned unique user identifiers which is used as the basis for access control decisions
and auditing. The TOE authenticates the claimed identity of the user before allowing the user to
perform any further TSF-mediated actions. The TOE internally maintains the identifier associated
with the thread spawned for the user after a successful authentication.
The TOE provides different identification and authentication mechanisms for the different request
types:
●
HTTP and webservices: HTTP-basic authentication, HTTP-digest authentication, form-based
authentication, client certificate based authentication
●
EJB: username and password based authentication, client certificate based authentication
●
JMS: username and password based authentication
●
JMX invokers: username and password based authentication
JBoss implements identification and authentication using Java Authentication and Authorization
Service (JAAS) with the JBossSX framework. The JAAS framework is provided by the Java virtual
machine in the operational environment. The JBossSX framework uses only the authentication
capabilities of JAAS to implement the declarative role-based Java EE security model.
JAAS authentication is performed in a pluggable fashion. This permits Java applications to remain
independent from underlying authentication technologies and allows the JBossSX security manager
to work in different security infrastructures. Integration with a security infrastructure can be achieved
without changing the JBossSX security manager implementation. All that needs to change is the
configuration of the authentication stack that JAAS uses. The TOE provides the JAAS modules which
are called by the JAAS framework to perform the identification and authentication.
Although the JBossSX framework is heavily dependent on JAAS, the basic security interfaces required
for implementation of the JAVA EE security model are not. The JBossSX framework is simply an
implementation of the basic security plug-in interfaces that are based on JAAS. JBossSX provides
an abstraction layer which is based on JAAS to other containers of JBoss. The implication of this
plug-in architecture is that the administrator is free to replace the JAAS-based JBossSX
implementation classes with an individual custom security manager implementation that does not
make use of JAAS. The evaluated configuration, however, prohibits the replacement of JBossSX.
The following authentication backends are allowed to be configured with the JAAS modules:
Page 49 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
File-based storage
●
BaseCertLoginModule
●
LDAP
●
Databases accessible through JDBC
The passwords quality used can be enforced with configuration options for the JAAS modules
provided by the TOE.
If the JAAS login authenticates the user, a JAAS Subject is created that contains the following in its
PrincipalsSet:
●
A java.security.Principal that corresponds to the client identity as known in the deployment
security environment.
●
A java.security.acl.Group named Roles that contains the role names from the application
domain to which the user has been assigned. org.jboss.security.SimplePrincipal objects are
used to represent the role names; SimplePrincipal is a simple string-based implementation
of Principal. These roles are used to validate the roles assigned to methods in ejb-jar.xml
and the EJBContext.isCallerInRole(String) method implementation.
●
An optional java.security.acl.Group named CallerPrincipal, which contains a single
org.jboss.security.SimplePrincipal that corresponds to the identity of the application domain's
caller. The CallerPrincipal sole group member will be the value returned by the
EJBContext.getCallerPrincipal() method. The purpose of this mapping is to allow a Principal
as known in the operational security environment to map to a Principal with a name known
to the application. In the absence of a CallerPrincipal mapping the deployment security
environment principal is used as the getCallerPrincipal method value. That is, the operational
principal is the same as the application domain principal.
The above mentioned network protocols tunnel the client requests to the TOE. After the TOE
performed the I/A checks, the request is forwarded to the intended application. As the TOE only
uses the credential information from the network request, only the aspect of communicating the
user credentials is relevant for the enforcement of the I/A policy.
The TOE allows the management of the authorization independently for each application and
independently and for each service. The mentioned deployment descriptors, and annotations can
be used by authorized administrators (and developers which belong to the category of authorized
administrators as specified in A.DEVEL) to configure the I&A mechanism. Note that the TOE provides
the interfaces for managing the I&A policy. However, it does not restrict the use of the interfaces
- the restriction is enforced by the environment based on A.PROTECT which ensures that only
authorized administrators are allowed to access the host system.
This security function covers all SFRs mapped to O.AUTHORIZATION.
7.1.5 Transaction Rollback
JBoss includes a fast in-VM implementation of a JBoss Transactions compatible transaction manager
that is used as the default transaction manager. A transaction is defined as a unit of work containing
one or more operations involving one or more shared resources having ACID properties. ACID is an
acronym for atomicity, consistency, isolation and durability, the four important properties of
transactions. The meanings of these terms are:
●
Atomicity: A transaction must be atomic. This means that either all the work done in the
transaction must be performed, or none of it must be performed. Doing part of a transaction
is not allowed.
Page 50 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
●
Consistency: When a transaction is completed, the system must be in a stable and consistent
condition.
●
Isolation: Different transactions must be isolated from each other. This means that the partial
work done in one transaction is not visible to other transactions until the transaction is
committed, and that each process in a multi-user system can be programmed as if it was
the only process accessing the system.
●
Durability: The changes made during a transaction are made persistent when it is committed.
When a transaction is committed, its changes will not be lost, even if the server crashes
afterwards.
In traditional ACID transaction systems, transactions are short lived, resources (such as databases)
are locked for the duration of the transaction and participants have a high degree of trust with each
other. With the advent of the Internet and Web services, the scenario that is now emerging requires
involvement of participants unknown to each other in distributed transactions. JBoss Transactions
adds native support for Web services transactions by providing all of the components necessary
to build interoperable, reliable, multi-party, Web services-based applications with the minimum of
effort. The programming interfaces are based on the Java API for XML Transactioning (JAXTX) and
the product includes protocol support for the WS-AtomicTransaction and WS-BusinessActivity
specifications. JBoss is designed to support multiple coordination protocols.
JBoss 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 participant 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.
This security function covers the SFR FDP_ROL.2-jb.
Page 51 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
8 Abbreviations, Terminology and References
8.1 Abbreviations
ACL
Access Control List
API
Application Programming Interface
EJB
Enterprise Java Beans
HA
High Availability
HTTP
Hypertext Transfer Protocol
IIOP
Internet Inter-ORB Protocol
J2EE
See Java EE
JAAS
Java Authentication and Authorization Services
JATAX
Java API for XML Transationing
Java EE
Java Enterprise Edition
JDBC
Java Database Connectivity
JDK
Java Development Kit
JMS
Java Messaging Service
JMX
Java Management Extensions
JNDI
Java Naming and Directory Interface
JRE
Java Runtime Environment
Page 52 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
JRMP
Java Remote Method Protocol
JVM
Java Virtual Machine
LDAP
Lightweight Directory Access Protocol
ORB
Object Request Broker
POJO
Plain Old Java Object
SFR
Security Functional Requirement
SOAP
originally defined as Simple Object Access Protocol
SSL
Secure Sockets Layer
ST
Security Target
TCP/IP
Transmission Control Protocol / Internet Protocol
TLS
Transport Layer Security
TOE
Target of Evaluation
TSF
TOE Security Functionality
VM
Virtual Machine
VPN
Virtual Private Network
XML
Extensible Markup Language
8.2 Terminology
This section contains definitions of technical terms that are used with a meaning specific to this
document. Terms defined in the [CC] are not reiterated here, unless stated otherwise.
Page 53 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Administrative User
This term refers to a user in one of the defined administrative roles of a JBoss system. The TOE
defines a set of administrative roles where each role has specific administrative authorities.
Splitting the administrative authorities among different roles allows for a more controlled
operational environment without the need for a single user to have all administrative authorities.
Authentication Data
This includes the password and X.509 certificates for each user of the product. Authentication
mechanisms using other authentication data are not supported in the evaluated configuration.
Data
Arbitrary bit sequences in computer memory or on storage media.
Group
After a user is successfully identified and authenticated, JBoss instantiates a “Group” Java object
containing the groups the authenticated subject is associated with.
Information
Any data held within a JBoss instance, including data in transit between systems.
JBoss Container
A JBoss container, or in short container, is a part of JBoss that provides services to user-written
programs. For example, the EJB functionality is implemented by the EJB container, the JSP/servlet
functionality is implemented by the Tomcat container. The JBoss architecture implements various
functional aspects as self-contained containers which can be selectively enabled.
Named Object
In JBoss, those objects that are subject to access control. This includes all objects except memory
objects. Please note, named objects are not to be mixed with the implementation of Java objects.
Object
For JBoss, objects are defined by the different iterations of FDP_ACC.1.
Principal
After a user is successfully identified and authenticated, JBoss instantiates a “Principal” Java
object as a token for the user. This object contains multiple information, including the users
identityand the roles associated with the user. A Principal is an authenticated user requesting
services from JBoss.
Product
The term product is used to define software components that comprise the JBoss Enterprise
Application Platform.
Role
A role represents a set of actions that an authorized user, upon assuming the role, is allowed
to perform.
Subject
See Principal (similar information found in a Principal object for a user can be kept in a Subject
object).
Page 54 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target
Target Of Evaluation (TOE)
The TOE is defined as the JBoss application server, running and tested on the hardware, operating
systems and Java virtual machines specified in this Security Target.
User
Any individual/person who has a unique user identifier and who interacts with the JBoss product.
Unauthorized users do not possess a valid user identifier.
User Security Attributes
Defined by functional requirement FIA_ATD.1, every user is associated with a number of security
attributes which allow the TOE to enforce its security functions on this user.
8.3 References
Common Criteria for Information Technology Security Evaluation
CC
3.1R3
Version
July 2009
Date
http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R3.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R3.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R3.pdf
Location
Page 55 of 55
Classification: Public
Version: 3.13
Copyright © 2011 by Red Hat and atsec information security
Last update: 2011-11-14
Red Hat, Inc.
JBoss Enterprise Application Platform 5 Version 5.1.0
and 5.1.1 Security Target