Security Target for z/OS Version 2 Release 5
Version: 2.27
Status: Released
Last Update: 2025-06-27
IBM Corporation
Security Target for z/OS Version 2 Release 5
Trademarks
The following terms are trademarks or registered trademarks of the International Business Machines
Corporation in the United States, other countries, or both:
● ESCON®
● FICON®
● HiperSockets
● IBM®
● IBM® zEnterprise System
● OS/390®
● Processor Resource/Systems Manager
● PR/SM
● ResourceLink®
● RETAIN®
● S/360®
● S/370®
● S/390®
● System z®
● VM/ESA®
● VSE/ESA
● zEnterprise®
● z/Architecture®
● z/OS®
● z/VM®
● zSeries®
● z System
● Linux on z Systems
● IBM LinuxONE(tm)
● LinuxONE
● IBM z16
● z/TPF
Those trademarks followed by ® are registered trademarks of IBM in the United States; all others are
trademarks or common law marks of IBM in the United States.
More details on IBM UNIX hardware, software and solutions may be found at ibm.com/servers/unix/.
InfiniBand is a registered trademark of the InfiniBand Trade Association.
Linux is a registered trademark of Linus Torvalds.
UNIX is a registered trademark of The Open Group in the United States and other countries.
IBM, the IBM logo, the e-business logo, LinuxONE, AIX, DB2, DB2 Universal Database, pSeries,
RS/6000, SP and WebSphere are registered trademarks or trademarks of the International Business
Machines Corporation in the United States and/or other countries.
Version: 2.27 Page 2 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Other company, product and service names may be trademarks or service marks of others. IBM may
not offer the products, programs, services or features discussed herein in other countries, and the
information may be subject to change without notice.
Legal Notice
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Produced in the United States of America, All Rights Reserved
General availability may vary by geography.
IBM hardware products are manufactured from new parts, or new and used parts. Regardless, our
warranty terms apply.
All statements regarding IBM's future direction and intent are subject to change or withdrawal
without notice, and represent goals and objectives only. Any reliance on these statements is at the
relying party's sole risk and will not create any liability or obligation for IBM.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not give you any license to these patents. You can
send license inquiries, in writing to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
Revision History
Version Date Author(s) Changes to Previous Revision
2.27 2025-06-27 Author: Mark Nelson Public Release.
Version: 2.27 Page 3 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Table of Contents
1 Introduction ...................................................................................................... 11
1.1 Security Target Identification .......................................................................................... 11
1.2 TOE Identification ............................................................................................................ 11
1.3 TOE Type ......................................................................................................................... 11
1.4 TOE Overview .................................................................................................................. 11
1.5 TOE Description ............................................................................................................... 12
1.5.1 Intended Method of Use .......................................................................................... 13
1.5.2 Summary of Security Features ................................................................................ 14
1.5.2.1 Identification and authentication .................................................................... 14
1.5.2.2 Discretionary access control ........................................................................... 15
1.5.2.2.1 z/OS standard DAC mechanism ............................................................. 15
1.5.2.2.2 z/OS UNIX DAC mechanism .................................................................... 15
1.5.2.3 Auditing .......................................................................................................... 15
1.5.2.4 Object reuse functionality .............................................................................. 16
1.5.2.5 Security management .................................................................................... 16
1.5.2.6 Cryptographic Support ................................................................................... 16
1.5.2.7 Communications Security ............................................................................... 17
1.5.2.8 TSF protection ................................................................................................ 17
1.5.2.9 Confidentiality Protection of Data Sets ........................................................... 18
1.5.3 Configurations ......................................................................................................... 18
1.5.3.1 Software Configuration ................................................................................... 18
1.5.3.2 Hardware Configuration .................................................................................. 18
2 CC Conformance Claim ...................................................................................... 20
3 Security Problem Definition ............................................................................... 21
3.1 Construction Rationale .................................................................................................... 21
3.1.1 Information obtained from [PP_OS_V4.3] ................................................................. 21
3.1.2 Information obtained from [OSPP] .......................................................................... 22
3.1.3 Information from this Security Target ..................................................................... 22
3.2 Threat Environment ......................................................................................................... 23
3.2.1 Assets ..................................................................................................................... 23
3.2.2 Threat agents ......................................................................................................... 23
3.2.3 Threats countered by the TOE ................................................................................ 23
3.3 Assumptions .................................................................................................................... 24
3.3.1 Intended usage of the TOE ..................................................................................... 25
3.4 Organizational Security Policies ....................................................................................... 25
4 Security Objectives ........................................................................................... 26
4.1 Objectives for the TOE .................................................................................................... 26
4.2 Objectives for the Operational Environment .................................................................... 27
4.3 Security Objectives Rationale .......................................................................................... 28
4.3.1 Security Objectives Coverage ................................................................................. 28
4.3.2 Security Objectives Sufficiency ............................................................................... 29
5 Extended Components Definition ....................................................................... 32
5.1 Class FCS: Cryptographic support ................................................................................... 32
Version: 2.27 Page 4 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
5.1.1 TLS Protocol (FCS_TLS_PLUS) .................................................................................. 32
5.1.1.1 FCS_TLS_PLUS.1 TLS Protocol ......................................................................... 32
5.1.2 TLS Client Protocol (FCS_TLSC_PLUS) ...................................................................... 32
5.1.2.1 FCS_TLSC_PLUS.1 TLS Client Protocol ............................................................. 33
5.1.2.2 FCS_TLSC_PLUS.2 TLS Client Support for Mutual Authentication ..................... 34
5.1.2.3 FCS_TLSC_PLUS.5 TLS Client Support for Supported Groups Extension ........... 34
5.1.3 TLS Server Protocol (FCS_TLSS_PLUS) ..................................................................... 35
5.1.3.1 FCS_TLSS_PLUS.1 TLS Server Protocol ............................................................ 35
5.1.3.2 FCS_TLSS_PLUS.2 TLS Server Support for Mutual Authentication .................... 36
5.2 Class FIA: Identification and authentication ..................................................................... 37
5.2.1 X.509 Certificate Validation (FIA_X509_PLUS) ......................................................... 37
5.2.1.1 FIA_X509_PLUS.1 X.509 Certificate Validation ................................................ 37
5.2.1.2 FIA_X509_PLUS.2 X.509 Certificate Authentication ......................................... 38
6 Security Requirements ...................................................................................... 39
6.1 TOE Security Functional Requirements ............................................................................ 39
6.1.1 Security audit (FAU) ................................................................................................ 42
6.1.1.1 FAU_GEN.1 Audit Data Generation ................................................................ 42
6.1.1.2 FAU_GEN.2 User identity association ............................................................. 43
6.1.1.3 FAU_SAR.1 Audit review ................................................................................ 43
6.1.1.4 FAU_SAR.2 Restricted audit review ............................................................... 43
6.1.1.5 FAU_SAR.3 Selectable audit review ............................................................... 44
6.1.1.6 FAU_SEL.1 Selective audit ............................................................................. 44
6.1.1.7 FAU_STG.1 Protected audit trail storage ........................................................ 44
6.1.1.8 FAU_STG.3 Action in case of possible audit data loss .................................... 44
6.1.1.9 FAU_STG.4 Prevention of audit data loss ....................................................... 44
6.1.2 Cryptographic support (FCS) ................................................................................... 45
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation .................................................... 45
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment ................................................ 45
6.1.2.3 FCS_CKM_EXT.4 Cryptographic Key Destruction ............................................ 45
6.1.2.4 FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/Decryption ......... 45
6.1.2.5 FCS_COP.1/HASH Cryptographic Operation - Hashing .................................... 46
6.1.2.6 FCS_COP.1/SIGN Cryptographic Operation - Signing ...................................... 46
6.1.2.7 FCS_COP.1/KEYHMAC Cryptographic Operation - Keyed-Hash Message
Authentication .............................................................................................................. 46
6.1.2.8 FCS_COP.1/IPSEC Cryptographic operation - IPSec ......................................... 47
6.1.2.9 FCS_RBG_EXT.1 Random Bit Generation ........................................................ 47
6.1.2.10 FCS_STO_EXT.1 Storage of Sensitive Data ................................................... 48
6.1.2.11 FCS_TLS_PLUS.1 TLS Protocol ...................................................................... 48
6.1.2.12 FCS_TLSC_PLUS.1 TLS Protocol .................................................................... 48
6.1.2.13 FCS_TLSC_PLUS.2 TLS Client Support for Mutual Authentication .................. 48
6.1.2.14 FCS_TLSC_PLUS.5 TLS Protocol .................................................................... 48
6.1.2.15 FCS_TLSS_PLUS.1 TLS Server Protocol ......................................................... 49
6.1.2.16 FCS_TLSS_PLUS.2 Server Support for Mutual Authentication ........................ 49
6.1.2.17 FCS_SSH_EXT.1 SSH Protocol ...................................................................... 50
6.1.2.18 FCS_SSHC_EXT.1 SSH Protocol - Client ........................................................ 51
Version: 2.27 Page 5 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.2.19 FCS_SSHS_EXT.1 SSH Protocol - Server ....................................................... 51
6.1.3 User data protection (FDP) ..................................................................................... 51
6.1.3.1 FDP_ACF_EXT.1 Access Controls for Protecting User Data .............................. 51
6.1.3.2 FDP_ACC.1(PSO-MVS) Subset access control: MVS ......................................... 51
6.1.3.3 FDP_ACC.1(PSO-UNIX) Subset access control: UNIX ....................................... 51
6.1.3.4 FDP_ACC.1(TSO) Subset access control ......................................................... 52
6.1.3.5 FDP_ACF.1(PSO-MVS) Security attribute based access control: MVS ............... 52
6.1.3.6 FDP_ACF.1(PSO-UNIX) Security attribute based access control: UNIX ............. 53
6.1.3.7 FDP_ACF.1(TSO) Security attribute based access control: UNIX IPC ................ 54
6.1.3.8 FDP_RIP.2 Full residual information protection of resources ........................... 54
6.1.4 Identification and authentication (FIA) .................................................................... 54
6.1.4.1 FIA_AFL.1 Authentication failure handling ...................................................... 54
6.1.4.2 FIA_ATD.1 User attribute definition ............................................................... 55
6.1.4.3 FIA_SOS.1 Verification of secrets ................................................................... 55
6.1.4.4 FIA_UAU.1 Timing of authentication .............................................................. 55
6.1.4.5 FIA_UAU.5 Multiple Authentication Mechanisms ............................................. 56
6.1.4.6 FIA_UAU.7 Protected authentication feedback ............................................... 56
6.1.4.7 FIA_UID.1 Timing of identification .................................................................. 56
6.1.4.8 FIA_USB.1 User-subject binding ..................................................................... 56
6.1.4.9 FIA_X509_PLUS.1 X.509 Certificate Validation ............................................... 57
6.1.4.10 FIA_X509_PLUS.2 X.509 Certificate Authentication ...................................... 58
6.1.5 Security management (FMT) ................................................................................... 58
6.1.5.1 FMT_MOF_EXT.1 Management of security functions behavior ........................ 58
6.1.5.2 FMT_SMF_EXT.1 Specification of Management Functions ............................... 58
6.1.5.3 FMT_MSA.1(PSO-MVS) Management of object security attributes ................... 59
6.1.5.4 FMT_MSA.1(PSO-UNIX) Management of object security attributes .................. 59
6.1.5.5 FMT_MSA.1(TSO) Management of object security attributes .......................... 59
6.1.5.6 FMT_MSA.3(PSO-MVS) Static attribute initialisation ........................................ 59
6.1.5.7 FMT_MSA.3(PSO-UNIX) Static attribute initialisation ....................................... 60
6.1.5.8 FMT_MSA.3(TSO) Static attribute initialisation ............................................... 60
6.1.5.9 FMT_MTD.1 Management of TSF data ........................................................... 60
6.1.5.10 FMT_SMR.1 Security management roles ...................................................... 60
6.1.6 Protection of the TSF (FPT) ..................................................................................... 61
6.1.6.1 FPT_ACF_EXT.1 Access controls ..................................................................... 61
6.1.6.2 FPT_ASLR_EXT.1 Address Space Layout Randomization ................................. 62
6.1.6.3 FPT_SBOP_EXT.1 Stack Buffer Overflow Protection ........................................ 62
6.1.6.4 FPT_TST_EXT.1 Boot Integrity ........................................................................ 62
6.1.6.5 FPT_TUD_EXT.1 Trusted Update .................................................................... 62
6.1.6.6 FPT_TUD_EXT.2 Trusted Update for Application Software .............................. 62
6.1.6.7 FPT_STM.1 Reliable time stamps ................................................................... 63
6.1.7 TOE access (FTA) .................................................................................................... 63
6.1.7.1 FTA_TAB.1 Default TOE access banners ........................................................ 63
6.1.7.2 FTA_SSL.1 TSF-initiated session locking ......................................................... 63
6.1.7.3 FTA_SSL.2 User-initiated locking .................................................................... 63
6.1.8 Trusted path/channels (FTP) ................................................................................... 64
Version: 2.27 Page 6 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.8.1 FTP_ITC_EXT.1 Trusted channel communication ............................................ 64
6.1.8.2 FTP_ITC.1 Trusted channel communication .................................................... 64
6.1.8.3 FTP_TRP.1 Trusted Path ................................................................................ 64
6.2 Security Functional Requirements Rationale .................................................................... 65
6.2.1 Security Requirements Coverage ............................................................................ 65
6.2.2 Security Requirements Sufficiency .......................................................................... 67
6.2.3 Security Requirements Dependency Analysis .......................................................... 70
6.3 Security Assurance Requirements ................................................................................... 73
6.4 Security Assurance Requirements Rationale .................................................................... 73
7 TOE Summary Specification ............................................................................... 74
7.1 Mapping SFR to TSS ........................................................................................................ 74
7.2 TOE Security Functionality ............................................................................................... 76
7.2.1 z/OS Basic Principles ............................................................................................... 76
7.2.1.1 Hardware Platform ......................................................................................... 76
7.2.1.2 System Initialization (IPL) ............................................................................... 77
7.2.1.2.1 Initial System Address Space Creation ................................................... 78
7.2.1.2.2 Master Scheduler Initialization (MSTR) ................................................... 78
7.2.1.2.3 z/OS Subsystem Initialization ................................................................. 78
7.2.1.2.4 Trusted Boot/IPL ..................................................................................... 78
7.2.1.3 Address Spaces in z/OS .................................................................................. 79
7.2.1.4 System Call Interface ..................................................................................... 79
7.2.1.5 Subjects .......................................................................................................... 80
7.2.1.6 Security Services ............................................................................................ 80
7.2.1.7 User interaction with z/OS .............................................................................. 80
7.2.1.8 Persistent Storage .......................................................................................... 80
7.2.1.9 Authorized Programs ...................................................................................... 80
7.2.2 Security Functionality ............................................................................................. 82
7.2.2.1 Identification and Authentication (FIA, FTA) .................................................... 82
7.2.2.1.1 Authentication Functions ........................................................................ 83
7.2.2.2 Access Control (FDP) ...................................................................................... 91
7.2.2.2.1 Access Control Overview ....................................................................... 91
7.2.2.2.2 Discretionary Access Control ................................................................. 93
7.2.2.3 Audit (FAU) ................................................................................................... 108
7.2.2.3.1 Generation of audit records ................................................................. 108
7.2.2.3.2 Protection of the audit trail .................................................................. 109
7.2.2.4 Cryptographic Functions (FCS) ..................................................................... 110
7.2.2.4.1 General Cryptography .......................................................................... 110
7.2.2.4.2 Cryptographic Key Destruction ............................................................ 112
7.2.2.4.3 Random Number Generation ................................................................ 113
7.2.2.5 Security Management (FMT) ......................................................................... 113
7.2.2.5.1 RACF User and Group Management ..................................................... 113
7.2.2.5.2 Resource management ........................................................................ 117
7.2.2.5.3 RACF configuration and management .................................................. 118
7.2.2.5.4 RACF Certificate and Key Management ................................................ 119
7.2.2.5.5 Audit configuration and management .................................................. 120
Version: 2.27 Page 7 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.6 Object Re-Use ............................................................................................... 120
7.2.2.7 Self Protection .............................................................................................. 120
7.2.2.7.1 Time Management ............................................................................... 120
7.2.2.7.2 Automatic Logout of Sessions .............................................................. 121
7.2.2.7.3 Address Space Layout Randomization .................................................. 121
7.2.2.7.4 Stack Buffer Overflow Protection ......................................................... 121
7.2.2.7.5 Trusted Update Process ....................................................................... 126
7.2.2.8 Communication Security ............................................................................... 127
7.2.2.8.1 Methods of remote Administration ....................................................... 127
7.2.2.8.2 Communications Server ....................................................................... 127
7.2.2.8.3 System SSL .......................................................................................... 128
7.2.2.8.4 OpenSSH .............................................................................................. 129
7.2.2.8.5 IPSec .................................................................................................... 130
7.2.2.8.6 Management of Communications Server Functions .............................. 131
7.2.2.9 Confidentiality Protection of Data Sets ......................................................... 131
7.2.2.9.1 Enabling data set encryption ............................................................... 133
8 Abbreviations, Terminology, and References ..................................................... 134
8.1 Abbreviations ................................................................................................................. 134
8.2 Terminology ................................................................................................................... 135
8.3 References ..................................................................................................................... 138
Version: 2.27 Page 8 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
List of Tables
Table 1: Mapping of security objectives to threats and policies ................................................ 28
Table 2: Mapping of security objectives for the Operational Environment to assumptions, threats
and policies ......................................................................................................................... 28
Table 3: Sufficiency of objectives countering threats ............................................................... 29
Table 4: Sufficiency of objectives holding assumptions ............................................................ 30
Table 5: Sufficiency of objectives enforcing Organizational Security Policies ............................ 31
Table 6: SFRs for the TOE ........................................................................................................ 39
Table 7: Mapping of security functional requirements to security objectives ............................ 65
Table 8: Security objectives for the TOE rationale .................................................................... 67
Table 9: TOE SFR dependency analysis .................................................................................... 70
Table 10: Mapping SFRs to TSS Sections .................................................................................. 74
Table 11: Cryptographic Keys used by the TOE ..................................................................... 113
Table 12: Data Set Profile Structure and Content ................................................................... 117
Table 13: List of Executables with Stack-buffer Overflow Protection ....................................... 121
Version: 2.27 Page 9 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
List of Figures
Figure 1: RACF Request Flow ................................................................................................... 91
Version: 2.27 Page 10 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
1 Introduction
1.1 Security Target Identification
Title: Security Target for z/OS Version 2 Release 5
Version: 2.27
Status: Released
Date: 2025-06-27
Author: Mark Nelson, IBM
Sponsor: IBM Corporation
Developer: IBM Corporation
Certification Body: OCSI
Certification ID: OCSI/CERT/ATS/07/2024
Keywords: operating system, access control, identification, authentication, audit, object
reuse
1.2 TOE Identification
The TOE is IBM z/OS Version 2 Release 5.
1.3 TOE Type
The TOE type is Operating System.
1.4 TOE Overview
This Security Target (ST) documents the security characteristics of the IBM z/OS Version 2 Release 5
operating system with the additional required licensed programs (see section Software Configuration
of this ST) configured in a secure manner as described in z/OS Planning for Multilevel Security and the
Common Criteria ([MLSGUIDE]).
IBM z/OS, a highly-secure, robust, scalable, high-performance enterprise operating system on which
to build and deploy mission-critical applications, provides a comprehensive and diverse application
execution environment. IBM z/OS is the flagship operating system for IBM z System™ mainframe
computers, empowering the use of their most advanced features, such as the 64-bit z/Architecture™. It
delivers the highest qualities of service for enterprise transactions and data and extends these qualities
to new applications using the latest software technologies. IBM z/OS serves as the heart of customers'
IT infrastructures, helping to integrate their information strategy and business strategy.
IBM z/OS can be used on a single IBM z System mainframe computer, or several systems or logical
partitions running the evaluated version of IBM z/OS can be connected to form a loosely-coupled
complex of systems called a sysplex.
IBM z/OS provides such software technologies as Enterprise Java™ Beans, eXtensible Markup Language
(XML), HyperText Markup Language (HTML), Unicode and distributed Internet Protocol (IP) networking.
z/OS UNIX System Services allows customers to develop and run UNIX programs on z/OS and exploit
the reliability and scalability of the z System processors. z/OS also incorporates cryptographic services,
distributed print services, workload management, storage management, parallel sysplex availability,
Version: 2.27 Page 11 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
and automation capabilities. Not all of these functions have been analyzed in this evaluation; see
section Software Configuration for the software configuration of z/OS used in this evaluation. The
security functions subject to this evaluation are described in chapter 7 of this document.
IBM z/OS provides identification and authentication of users using different authentication mechanisms,
discretionary access control to a large number of different objects, confidentiality protection of
datasets, a configurable audit functionality, protection of communication services, sophisticated
security management functions, preparation of objects for reuse, cryptographic support, TSF protection
and functionality used internally to protect z/OS from interference and tampering by untrusted users
or subjects.
1.5 TOE Description
The Target of Evaluation (TOE) is the z/OS operating system with the software components as described
in section Software Configuration. z/OS is a general-purpose, multi-user, multi-tasking operating system
for enterprise computing systems. Multiple users can use z/OS simultaneously to perform a variety of
functions that require controlled, shared access to the information stored on the system.
In this ST, the TOE is seen as one instance of z/OS running on an abstract machine as the sole operating
system and exercising full control over this abstract machine. This abstract machine can be provided
by one of the following:
● a logical partition provided by a certified version of PR/SM on an IBM z System™ processor
(System z16).
● a certified version of z/VM® executing in a logical partition provided by PR/SM on one of the
above-listed z System™ processors.
The underlying abstract machine itself is not part of the TOE, rather, it belongs to the TOE environment,
in particular this applies to the following functions:
● Privileged processor instructions are only available to programs running in the processor's
supervisor state
● Semi-privileged instructions are only available to programs running in an execution
environment that is established and authorized by the TSF
● While in operation, all address spaces, as well as the data and tasks contained therein, are
protected by the memory protection mechanisms of the underlying abstract machine
The correctness of these functions implemented in the abstract machine is analyzed as part of
the evaluation since those functions are crucial for the security of the TOE. Also, the abstract's
machine cryptographic functions, as implemented by the z/Architecture's CPACF or the cryptographic
coprocessors are used by the TOE to perform cryptographic operations.
Cryptographic functions implemented by the Crypto Express 8 coprocessors are used to perform
cryptographic operations as well to handle cryptographic keys. It should be noted, that a cryptographic
coprocessor is required to operate the TOE in its evaluated configuration. The same applies to the z/
Architecture's feature 3863 providing CPACF functions, these are required to operate the TOE as well.
See also Hardware Configuration.
A user who wants to use cryptographic functions provided by a coprocessor should be aware that
although those functions have been tested during the evaluation for functional correctness, no further
analysis of the design and implementation of those cryptographic functions implemented on the
coprocessors has been performed. Especially no analysis for potentially exploitable side channels of
the implementation of the cryptographic functions of the coprocessors has been performed.
The platforms selected for the evaluation consist of IBM products that are available when the evaluation
has been completed and will remain available for a substantial period of time afterward.
Version: 2.27 Page 12 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
The individual TOEs can be run alone or within a network as a set of cooperating hosts, operating under
and implementing the same set of security policies. They also can be connected to form a loosely-
coupled complex of systems called a sysplex
Most of the TOE security functions (TSF) are provided by the z/OS operating system Base Control
Program (BCP) and the Resource Access Control Facility (RACF), a z/OS component that is used by
different services as the central instance for identification and authentication and for access control
decisions. z/OS comes with management functions that allow configuring of the TOE security functions
to tailor them to the customer's needs.
Some elements have been included in the TOE that do not provide security functions. These elements
run in authorized mode, so they could compromise the TOE if they do not behave properly. Because
these elements are essential for the operation of many customer environments, the inclusion of these
elements subjects them to the process of scrutiny during the evaluation and ensures that they may be
used by customers without affecting the TOE's security status.
1.5.1 Intended Method of Use
z/OS provides a general computing environment that allows users to gain controlled access to its
resources in different ways:
● online interaction with users through Time Sharing Option Extensions (TSO/E) or z/OS UNIX
System Services
● batch processing (JES2)
● services provided by started procedures or tasks
● daemons and servers utilizing z/OS UNIX System Services that provide similar functions as
started procedures or tasks but based on UNIX interfaces
These services can be accessed by users local to the computer systems or accessing the systems via
network services supported by the evaluated configuration.
All users of the TOE are assigned a unique user identifier (user ID). This user ID, which is used as
the basis for access control decisions and for accountability, associates the user with a set of security
attributes. In most cases the TOE authenticates the claimed identity of a user before allowing this user
to perform any further security-relevant actions. Exceptions to this authentication policy include:
i. Pre-specified identities:
a. The authorized administrator can specify an identity to be used by server or daemon
processes or system address spaces, which may be started either automatically or
via system operator commands;
ii. Users are allowed to execute programs that accept network connections on ports the user
has access to. In this case the untrusted program has no knowledge about the external
"user" and cannot perform authentication. The program executes with the rights of the z/OS
user that started it, and any data access occurs using this user's authenticated identity.
All TOE resources are under the control of the TOE. The TOE mediates the access of subjects to TOE-
protected objects. Subjects in the TOE are called tasks. Tasks are the active entities that can act on
the user's behalf. Data is stored in named objects.
Objects are owned by users, who are assumed to be capable of assigning discretionary access rights to
their objects in accordance with the organizational security policies. Ownership of named objects can
be transferred under the control of the access control policy.
Apart from normal users, z/OS recognizes administrative users with special authorizations. These users
are trusted to perform system administration and maintenance tasks, which includes configuration
of the security policy enforced by the z/OS system and attributes related to it. Authorizations can be
delegated to other administrative users by updating their security attributes.
Version: 2.27 Page 13 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
The TOE also recognizes the role of an auditor, who uses the auditing system provided by z/OS to
monitor the system usage according to the organizational security policies. An additional role of a 'read-
only auditor' can be assigned for an auditor that shall not have the capability to manage the audit but
only be able to read audit records and audit related configuration options.
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 of those
systems need to be configured in accordance with a defined common security policy.
1.5.2 Summary of Security Features
The primary security features of the product are:
● identification and authentication
● discretionary access control
● auditing
● object reuse
● security management
● cryptographic support
● communications security
● TSF protection
● confidentiality protection of datasets
These primary security features are supported by domain separation and reference mediation, which
ensure that the features are always invoked and cannot be bypassed.
1.5.2.1 Identification and authentication
z/OS provides identification and authentication of users by the means of
● an alphanumeric RACF user ID and a system-encrypted password or (for applications that
support it) password phrase.
● an alphanumeric RACF user ID and a PassTicket, which is a cryptographically-generated
password substitute encompassing the user ID, the requested application name, and the
current date/time.
● an SSH key that is configured to be trusted by the user and that is presented to the SSH
server during the authentication process.
In the evaluated configuration, all human users are assigned a unique user ID. This user ID supports
individual accountability. The TOE security functions authenticate the claimed identity of the user
by verifying the password/phrase (or other mechanism, as listed above) before allowing the user to
perform any actions that require TSF mediation, other than actions that aid an authorized user in gaining
access to the TOE.
In some cases of external access to the system, such as the HTTP server, or LDAP server, an installation
may decide to define a user ID that is used for access checking of selected resources for users that
have not been authenticated. This allows an installation to define resources unauthenticated users
may access using that server via an appropriate client program. Users may still authenticate to the
server using their user ID and password/phrase (or other authentication mechanism as above) to access
additional resources they have been assigned access to.
The password quality can be tailored to the installation's policies using various parameters. When
creating users, administrators are required to choose an initial password and optionally a password
phrase, that must usually be changed by the user during the initial logon that uses the password/phrase.
Version: 2.27 Page 14 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Administrators may configure the number of unsuccessful authentication attempts that can be met
before the account is disabled.
1.5.2.2 Discretionary access control
z/OS supports access controls that are capable of enforcing access limitations on individual users and
data objects. Discretionary access control (DAC) allows individual users to specify how such resources
as direct access storage devices (DASDs), DASD and tape data sets, and tape volumes that are under
their control are to be shared.
RACF makes access control decisions based on the user's identity, security attributes, group authorities,
and the access authority specified with respect to the resource profile.
The TOE provides the following DAC mechanisms:
i. The z/OS standard DAC mechanism is used for most traditional (non-UNIX) protected objects.
ii. The z/OS UNIX DAC mechanism is used for z/OS UNIX objects (files, directories, etc.)
1.5.2.2.1 z/OS standard DAC mechanism
Access types that can be granted are NONE, EXECUTE, READ, UPDATE, CONTROL, and ALTER, which
form a hierarchical set of increasing access authorities.
Access authorities to resources are stored in profiles. Discrete profiles are valid for a single, named
resource and generic profiles are applicable to a group of resources, typically with similar names. For
access permission checks, RACF always chooses the most specific profile for a resource. Profiles can
have an access control list associated with them that contains a potentially large number of entries for
different groups and users, thus allowing the modeling of complex, fine-grained access controls.
Profiles are assigned to a number of resources within z/OS. This Security Target defines the resource
types analyzed during the evaluation. RACF profiles are also used to manage and control privileges in z/
OS and resources of subsystems that are not part of the evaluated configuration (e. g. DB2, CICS, JES3).
Access rights for subjects to resources can be set by the profile owner and by the system administrator.
The TOE allows access decisions by this mechanism for local applications or remote applications. For
local applications the application, or the TOE, uses the RACROUTE programming interface to perform
the access check.
1.5.2.2.2 z/OS UNIX DAC mechanism
z/OS implements POSIX-conformant access control for such named objects in the UNIX realm as UNIX
file system objects and UNIX inter-process communication (IPC) objects. Access types for UNIX file
system objects are read, write, and execute/search, and read and write for UNIX IPC objects. z/OS file
system objects provide either access control based on the permission bits associated with a file, or
based on access control lists, which are upward-compatible with the permission bits algorithm and
implement the recommendations from Portable Operating System Interface for UNIX (POSIX) 1003.1e
draft 17.
1.5.2.3 Auditing
The TOE provides an auditing capability that allows generating audit records for security-critical events.
RACF provides a number of logging and reporting functions that allow resource owners and auditors to
identify users who attempt to access resources. Audit records are collected by the System Management
Facilities (SMF) into an audit trail, which is protected from unauthorized modification or deletion by the
DAC mechanisms. This audit trail can reside directly in MVS data sets, or in an MVS log stream (which
can be automatically off-loaded into MVS data sets), as configured by the administrator.
Version: 2.27 Page 15 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
The system can be configured to halt on exhaustion of audit trail space to prevent audit data loss.
Operators are warned when audit trail space consumption reaches a predefined threshold.
RACF always generates audit records for such events as unauthorized attempts to access the system
or changes to the status of the RACF database. The security administrator, auditors, and other users
with appropriate authorization can configure which additional optional security events are to be logged.
In addition to writing records to the audit trail, messages can be sent to the security console to
immediately alert operators of detected policy violations. RACF provides SMF records for all RACF-
protected resources (either “traditional” or z/OS UNIX-based) .
For reporting, auditors can unload all or selected parts of the SMF data for further analysis in a human-
readable formats and can then upload the data to a query or reporting package, such as DFSORT™
if desired.
1.5.2.4 Object reuse functionality
Reuse of protected objects and of storage is handled by various hardware and software controls, and
by administrative practices.
All memory content of non-shared page frames is cleared before making it accessible to other address
spaces or data spaces. DASD data sets can be purged during deletion with the RACF ERASE option and
tape volumes can be erased on return to the scratch pool. All resources allocated to UNIX objects are
cleared before reuse. Other data pools are under strict TOE control and cannot be accessed directly
by normal users.
1.5.2.5 Security management
z/OS provides a set of commands and options to adequately manage the TOE's security functions.
Additionally, the TOE provides the capability of managing users, groups of users as well as general
resource profiles.
The TOE recognizes several authorities that are able to perform the different management tasks related
to the TOE's security:
● General security options are managed by security administrators.
● Management of users and their security attributes is performed by security administrators.
Management of groups (and to some extent users) can be delegated to group security
administrators.
● Users can change their own passwords or password phrases, their default groups, and their
user names (but not their user IDs).
● Auditors manage the parameters of the audit system (a list of audited events, for example)
and can analyze the audit trail.
● Security administrators can define what audit records are captured by the system.
● Discretionary access rights to protected resources are managed by the owners of the
applicable profiles (or UNIX objects) or by security administrators.
1.5.2.6 Cryptographic Support
The TOE provides cryptographic functions by the ICSF subsystem. ICSF uses cryptographic hardware
provided by the operational environment to provide and support cryptographic functions. The TOE
implements TLS Version 1.2 and Version 1.3 as well SSH version 2 for communication and remote
access (see also below).
The TOE uses cryptographic support provided by the processor by means of the CPU's CPAF function.
Version: 2.27 Page 16 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
All key material used for cryptographic functions described in this Security Target when in volatile
memory are in memory that is assigned to and is accessible by the TSF only.
1.5.2.7 Communications Security
z/OS provides means of secure communication between systems sharing the same security policy.
In its evaluated configuration, z/OS supports trusted communication channels for TCP/IP connections.
The confidentiality and integrity of network connections are assured by Transport Layer Security (TLS)
encrypted communication for TCP/IP connections (Version 1.2 [RFC5246]☝ and Version 1.3 [RFC8446]☝),
which can be used explicitly by applications or applied transparently to their communications (AT-TLS)
without changing the applications using it (assuming the applications that do not make use of the
TLS capabilities that allow clients to authenticate to the system using a client-supplied X.509 digital
certificate. If applications accept client certificates then they do need to have specific TLS-related
processing within the applications).
z/OS also supports the SSH v2 protocol and the ssh-daemon provided services of ssh (secure shell),
scp (secure copy), and sftp (secure ftp) ([RFC4253]☝)
In addition to the TLS connection, z/OS also supports the IP Security (IPSec) protocol with Internet Key
Exchange (IKE) as the key exchange method. This is an additional way to set up a trusted channel to
another trusted IT product for IP-based connections. z/OS also provides centralized policy management
for IPSec policies across multiple z/OS systems in the network. It also provides centralized management
for digital certificates, message signing, and message verification for IPSec across multiple z/OS
systems in the network.
1.5.2.8 TSF protection
TSF protection is based on several protection mechanisms that are provided by the underlying abstract
machine:
● Privileged processor instructions are only available to programs running in the processor's
supervisor state
● Semi-privileged instructions are only available to programs running in an execution
environment that is established and authorized by the TSF
● While in operation, all address spaces, as well as the data and tasks contained therein, are
protected by the memory protection mechanisms of the underlying abstract machine
The TOE's address space management ensures that programs running in problem state cannot access
protected memory or resources that belong to other address spaces.
Access to system services - through supervisor call (SVC) or program call (PC) instructions, for example
- is controlled by the system, which requires that subjects who want to perform security-relevant tasks
be authorized appropriately.
The hardware and firmware components that provide the abstract machine for the TOE are required to
be physically protected from unauthorized access. The z/OS Base Control Program mediates all access
to the TOE's hardware resources themselves, other than program-visible CPU instruction functions.
Tools are provided in the TOE environment to allow authorized administrators to check the correct
operation of the underlying abstract machine.
In addition to the protection mechanism of the underlying abstract machine, the TOE also uses software
mechanisms like the authorized program facility (APF) or specific privileges for programs in the UNIX
system services environment to protect the TSF.
In addition the TOE provides the following mechanisms to protect its TSF:
Version: 2.27 Page 17 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Address space layout randomization (ASLR)
● Stack buffer overflow protection
● Verification of integrity of the IPL process
● Trusted software updates using digital signatures
1.5.2.9 Confidentiality Protection of Data Sets
With z/OS confidentiality protection of data sets, users can encrypt data at rest without requiring
application changes. z/OS data set encryption through RACF commands and SMS policies allows the
administrator to identify the data sets or groups of data sets that require encryption. The administrator
can specify an encryption key label, which refers to an encryption key. Both the key label and encryption
key must exist in the ICSF key repository (CKDS). With data set encryption, the administrator is able to
protect viewing the data in the clear. This is based on access to the key label that is associated with
the data set and used by the access methods to encrypt and decrypt the data.
1.5.3 Configurations
1.5.3.1 Software Configuration
The Target of Evaluation, IBM z/OS Version 2 Release 5, consists of:
● IBM z/OS Version 2 Release 5 (V2R5) Common Criteria Evaluated Base Package:
❍ IBM z/OS Version 2 Release 5 (z/OS V2R5, program number 5650-ZOS),
● The following APARs (or their associated PTFs):
❍ APAR OA64593 (DOC APAR)
❍ APAR OA66552 (DOC APAR)
❍ APAR OA56911
❍ APAR OA57975
❍ APAR OA60095
❍ APAR OA62371
❍ APAR OA66005
The z/OS V2R5 Common Criteria Evaluated Base package must be installed according to the directions
delivered with the media and configured according to the instructions in Chapter 7, “The evaluated
configuration for the Common Criteria” in z/OS Planning for Multilevel Security and the Common Criteria
([MLSGUIDE]).
For information in the required and optional software and additional required and mandatory
configuration guidance, please refer to [MLSGUIDE], chapter 7.
1.5.3.2 Hardware Configuration
The following assumptions about the technical environment in which the TOE is intended to be used
are made: The TOE is running a logical partition provided by PR/SM or a certified version of z/VM on
one of the following z System™ processors:
● IBM z16 with CPACF DES/TDES Enablement Feature 3863 active, with Crypto Express8S
(CEX8) cards.
The following peripherals can be used with the TOE:
● All terminals that are supported by the TOE.
● Printers:
Version: 2.27 Page 18 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ Any printer that is supported by the TOE.
● All storage devices and backup devices supported by the TOE, such as:
❍ Direct access storage devices (DASDs), except RVA devices.
❍ Tape drives (including encrypting tape drives, though this evaluation has not
specifically examined those cryptographic functions).
● All Ethernet and token-ring network adapters that are supported by the TOE.
Note: The peripherals may be virtualized in the case of the TOE executing within a logical partition or
z/VM. The logical partitioning software and z/VM software is part of the abstract machine and therefore
part of the TOE environment. The logical partitioning software documentation as well as the z/VM
documentation provides the required guidance on how to set up and configure the logical partitioning
software or z/VM and how to define the logical peripheral devices so the TOE operates securely in the
logical partitioning or z/VM environment.
Version: 2.27 Page 19 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
2 CC Conformance Claim
This Security Target is CC Part 2 extended and CC Part 3 conformant, with a claimed Evaluation
Assurance Level of EAL4, augmented by ALC_FLR.3.
This Security Target does not claim conformance to any Protection Profile.
Common Criteria [CC] version 3.1 revision 5 is the basis for this conformance claim.
Version: 2.27 Page 20 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
3 Security Problem Definition
3.1 Construction Rationale
This security problem definition is constructed out of two well known protection profiles. This security
target does not claim conformance to any PP, however it draws many concepts and structures out of
them.
Threats, assumptions and objectices used in this security target come out of the following sources:
1. The NIAP "Protection Profile for General Purpose Operating Systems, Version 4.3"
[PP_OS_V4.3]☝
2. The "Operating System Protection Profile, Version 2.0" [OSPP]
Both PPs are accepted, evaluated and are being and have been used in many operating system
evaluation. This security target aims to combine the aspects relevant for the TOE from both of them.
Further the following functional package is used as input for this ST:
● Functional Package for Secure Shell (SSH), Version 1.0, [PKG_SSH_V1.0]☝.
Note: The following should be considered:
● [PP_OS_V4.3]☝ uses the term "The OS" to refer to the TOE. This term is used in the
statements used from that PP, verbatim as indicated. Within this document, the terms "The
OS" and "The TOE" are considered to be equivalent with a preference to use the latter term.
Following is an enumeration of assumptions, threats and objectives together with their sources. This
should rationalize that within the security problem definition slightly different terminology is used,
as the elements are copied over verbatim and unaltered from the respective source PP. This also
covers the content of the section Security Objectives Rationale, where the rationale for sufficiency and
coverage is provided; this section combines information obtained from both sources. It should be noted
that [PKG_SSH_V1.0]☝ does not provide any contribution to he SPD.
3.1.1 Information obtained from [PP_OS_V4.3]
Threats
● T.NETWORK_ATTACK
● T.NETWORK_EAVESDROP
● T.LOCAL_ATTACK
● T.LIMITED_PHYSICAL_ACCESS
Assumptions
● A.PLATFORM
● A.PROPER_USER
● A.PROPER_ADMIN
Objectives
● O.ACCOUNTABILITY
● O.INTEGRITY
● O.MANAGEMENT
● O.PROTECTED_STORAGE
Version: 2.27 Page 21 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● O.PROTECTED_COMMS
Objectives for the Environment
● OE.PLATFORM
● OE.PROPER_USER
● OE.PROPER_ADMIN
3.1.2 Information obtained from [OSPP]
Threats
● T.ACCESS.TSFDATA
● T.ACCESS.USERDATA
● T.ACCESS.TSFFUNC
● T.IA.MASQUERADE
● T.IA.USER
Assumptions
● A.PHYSICAL
● A.PEER.MGT
● A.PEER.FUNC
● A.CONNECT
Organizational Security Policies
● P.ACCOUNTABILITY
● P.USER
Objectives
● O.AUDITING
● O.DISCRETIONARY.ACCESS
● O.IA
Objectives for the Environment
● OE.REMOTE
● OE.PHYSICAL
● OE.RECOVER
● OE.TRUSTED.IT.SYSTEM
3.1.3 Information from this Security Target
Threats
● T.ACCESS.CP.USERDATA
Objectives
● O.IA.MULTIPLE
Version: 2.27 Page 22 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Threats to be countered by the TOE are characterized by the combination of an asset being subject to
a threat, a threat agent and an adverse action.
3.2 Threat Environment
Threats to be countered by the TOE are characterized by the combination of an asset being subject to
a threat, a threat agent and an adverse action.
3.2.1 Assets
Assets to be protected are:
● Persistent storage objects used to store user data and/or TSF data, where this data needs to
be protected from any of the following operations:
❍ Unauthorized read access
❍ Unauthorized modification
❍ Unauthorized deletion of the object
❍ Unauthorized creation of new objects
❍ Unauthorized management of object attributes
● Transient storage objects, including network data
● TSF functions and associated TSF data
● The resources managed by the TSF that are used to store the above-mentioned objects,
including the metadata needed to manage these objects
● Applications or services processing user and TSF data
3.2.2 Threat agents
Threat agents are external entities that potentially may attack the TOE. They satisfy one or more of
the following criteria:
● External entities not authorized to access assets may attempt to access them either by
masquerading as an authorized entity or by attempting to use TSF services without proper
authorization.
● External entities authorized to access certain assets may attempt to access other assets
they are not authorized to either by misusing services they are allowed to use or by
masquerading as a different external entity.
● Untrusted subjects may attempt to access assets they are not authorized to either by
misusing services they are allowed to use or by masquerading as a different subject.
Threat agents are typically characterized by a number of factors, such as expertise, available resources,
and motivation, with motivation being linked directly to the value of the assets at stake. The TOE
protects against intentional and unintentional breach of TOE security by attackers possessing an
enhanced-basic attack potential.
3.2.3 Threats countered by the TOE
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network
infrastructure. Attackers may engage in communications with applications and services
running on or part of the OS with the intent of compromise. Engagement may consist of
altering existing legitimate communications.
Version: 2.27 Page 23 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the network
infrastructure. Attackers may monitor and gain access to data exchanged between
applications and services that are running on or part of the OS.
T.LOCAL_ATTACK
An attacker may compromise applications running on the OS. The compromised application
may provide maliciously formatted input to the OS through a variety of channels including
unprivileged system calls and messaging via the file system.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access data on the OS while having a limited amount of time with
the physical device.
T.ACCESS.TSFDATA
A threat agent might read or modify TSF data without the necessary authorization when the
data is stored or transmitted.
T.ACCESS.USERDATA
A threat agent might gain access to user data stored, processed or transmitted by the TOE
without being appropriately authorized according to the TOE security policy.
T.ACCESS.TSFFUNC
A threat agent might use or modify functionality of the TSF without the necessary privilege to
grant itself or others unauthorized access to TSF data or user data.
T.IA.MASQUERADE
A threat agent might masquerade as an authorized entity including the TOE itself or a part of
the TOE in order to gain unauthorized access to user data, TSF data, or TOE resources.
T.IA.USER
A threat agent might gain access to user data, TSF data or TOE resources with the exception
of public objects without being identified and authenticated.
T.ACCESS.CP.USERDATA
A threat agent might gain access to user data at rest, which is confidentiality protected,
without possessing the authorization of the owner, either at runtime of the TOE or when the
TSF are inactive.
3.3 Assumptions
Please refer to Construction Rationale for information on the content and presentation of the following
information about the objectives for the TOE.
This section describes the security aspects of the environment in which the TOE is intended to be
used. It includes information about the physical, personnel, procedural, and connectivity aspects of
the environment.
The TOE is assured to provide effective security measures in a cooperative non-hostile environment
only if it is installed, managed, and used correctly. The operational environment must be managed
in accordance with user/administrator guidance documentation. The following specific conditions are
assumed to exist in an environment where the TOE is employed.
Version: 2.27 Page 24 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
3.3.1 Intended usage of the TOE
A.PLATFORM
The OS relies upon a trustworthy computing platform for its execution. This underlying
platform is out of scope of this PP.
A.PROPER_USER
The user of the OS is not willfully negligent or hostile, and uses the software in compliance
with the applied enterprise security policy. At the same time, malicious software could act as
the user, so requirements which confine malicious subjects are still in scope.
A.PROPER_ADMIN
The administrator of the OS is not careless, willfully negligent or hostile, and administers the
OS within compliance of the applied enterprise security policy.
A.PHYSICAL
It is assumed that the IT environment provides the TOE with appropriate physical security,
commensurate with the value of the IT assets protected by the TOE.
A.PEER.MGT
All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE,
or to support the TSF in the enforcement of security policy decisions are assumed to be under
the same management control and operate under security policy constraints compatible with
those of the TOE.
A.PEER.FUNC
All remote trusted IT systems trusted by the TSF to provide TSF data or services to the TOE,
or to support the TSF in the enforcement of security policy decisions are assumed to correctly
implement the functionality used by the TSF consistent with the assumptions defined for this
functionality.
A.CONNECT
All connections to and from remote trusted IT systems and between physically-separate parts
of the TSF not protected by the TSF itself are physically or logically protected within the TOE
environment to ensure the integrity and confidentiality of the data transmitted and to ensure
the authenticity of the communication end points.
Application Note: In a data center environment a system running the TOE software may be
connected to other systems and require a high-speed data connection to those systems.
Example are links between elements of a cluster or links to locally attached storage systems.
Those are the cases addressed by this assumption.
3.4 Organizational Security Policies
P.ACCOUNTABILITY
The users of the TOE shall be held accountable for their security-relevant actions within the
TOE.
P.USER
Administrative privileges shall only be given to users who are trusted to perform the actions
correctly.
Version: 2.27 Page 25 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
4 Security Objectives
This section defines the security objectives of the TSF and its supporting environment. Security
objectives, categorized as either IT security objectives or non-IT security objectives, reflect the stated
intent to counter identified threats, comply with any organizational security policies identified, or
both. All of the identified threats and organizational policies are addressed under one of the following
categories.
4.1 Objectives for the TOE
O.ACCOUNTABILITY
Conformant OSes ensure that information exists that allows administrators to discover
unintentional issues with the configuration and operation of the operating system and
discover its cause. Gathering event information and immediately transmitting it to another
system can also enable incident response in the event of system compromise.
O.INTEGRITY
Conformant OSes ensure the integrity of their update packages. OSes are seldom if ever
shipped without errors, and the ability to deploy patches and updates with integrity is
critical to enterprise network security. Conformant OSes provide execution environment-
based mitigations that increase the cost to attackers by adding complexity to the task of
compromising systems.
O.MANAGEMENT
To facilitate management by users and the enterprise, conformant OSes provide consistent
and supported interfaces for their security-relevant configuration and maintenance. This
includes the deployment of applications and application updates through the use of platform-
supported deployment mechanisms and formats, as well as providing mechanisms for
configuration and application execution control.
O.PROTECTED_STORAGE
To address the issue of loss of confidentiality of credentials in the event of loss of physical
control of the storage medium, conformant OSes provide data-at-rest protection for
credentials. Conformant OSes also provide access controls which allow users to keep their
files private from other users of the same system.
O.PROTECTED_COMMS
To address both passive (eavesdropping) and active (packet modification) network attack
threats, conformant OSes provide mechanisms to create trusted channels for CSP and
sensitive data. Both CSP and sensitive data should not be exposed outside of the platform.
O.AUDITING
The TSF must be able to record defined security-relevant events (which usually include
security-critical actions of users of the TOE). The TSF must protect this information and
present it to authorized users if the audit trail is stored on the local system. The information
recorded for security-relevant events must contain the time and date the event happened
and, if possible, the identification of the user that caused the event, and must be in
sufficient detail to help the authorized user detect attempted security violations or potential
misconfiguration of the TOE security features that would leave the IT assets open to
compromise.
Version: 2.27 Page 26 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
O.DISCRETIONARY.ACCESS
The TSF must control access of subjects and/or users to named resources based on identity of
the object. The TSF must allow authorized users to specify for each access mode which users/
subjects are allowed to access a specific named object in that access mode.
O.IA
The TOE must ensure that users have been successfully authenticated before allowing any
action the TOE has defined to provide to authenticated users only.
O.IA.MULTIPLE
The TOE shall allow the concurrent use of multiple identification and authentication
mechanisms implementing the identification and authentication policy.
4.2 Objectives for the Operational Environment
The following objectives are to be met by the operational environment of the TOE.
OE.PLATFORM
The OS relies on being installed on trusted hardware.
OE.PROPER_USER
The user of the OS is not willfully negligent or hostile, and uses the software within
compliance of the applied enterprise security policy. Standard user accounts are provisioned
in accordance with the least privilege model. Users requiring higher levels of access should
have a separate account dedicated for that use.
OE.PROPER_ADMIN
The administrator of the OS is not careless, willfully negligent or hostile, and administers the
OS within compliance of the applied enterprise security policy.
OE.REMOTE
If the TOE relies on remote trusted IT systems to support the enforcement of its policy, those
systems provide the functions required by the TOE and are sufficiently protected from any
attack that may cause those functions to provide false results.
OE.PHYSICAL
Those responsible for the TOE must ensure that those parts of the TOE critical to enforcement
of the security policy are protected from physical attack that might compromise IT security
objectives. The protection must be commensurate with the value of the IT assets protected by
the TOE.
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
(security) compromise is achieved.
OE.TRUSTED.IT.SYSTEM
The remote trusted IT systems implement the protocols and mechanisms required by the TSF
to support the enforcement of the security policy.
Version: 2.27 Page 27 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
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.
Table 1: Mapping of security objectives to threats and policies
Objective Threats / OSPs
O.ACCOUNTABILITY T.NETWORK_ATTACK
T.LOCAL_ATTACK
P.ACCOUNTABILITY
O.INTEGRITY T.NETWORK_ATTACK
T.LOCAL_ATTACK
O.MANAGEMENT T.NETWORK_ATTACK
T.NETWORK_EAVESDROP
T.ACCESS.TSFDATA
T.ACCESS.USERDATA
T.ACCESS.TSFFUNC
T.IA.MASQUERADE
T.IA.USER
P.ACCOUNTABILITY
P.USER
O.PROTECTED_STORAGE T.LIMITED_PHYSICAL_ACCESS
T.ACCESS.CP.USERDATA
O.PROTECTED_COMMS T.NETWORK_ATTACK
T.NETWORK_EAVESDROP
O.AUDITING P.ACCOUNTABILITY
O.DISCRETIONARY.ACCESS T.ACCESS.TSFDATA
T.ACCESS.USERDATA
T.ACCESS.TSFFUNC
O.IA T.IA.MASQUERADE
T.IA.USER
O.IA.MULTIPLE T.IA.MASQUERADE
T.IA.USER
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.
Table 2: Mapping of security objectives for the Operational Environment to assumptions, threats and policies
Objective Assumptions / Threats / OSPs
OE.PLATFORM A.PLATFORM
OE.PROPER_USER A.PROPER_USER
OE.PROPER_ADMIN A.PROPER_ADMIN
OE.REMOTE A.CONNECT
Version: 2.27 Page 28 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Objective Assumptions / Threats / OSPs
OE.PHYSICAL A.PHYSICAL
OE.RECOVER A.PROPER_ADMIN
OE.TRUSTED.IT.SYSTEM A.PEER.MGT
A.PEER.FUNC
A.CONNECT
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.
Table 3: Sufficiency of objectives countering threats
Threat Rationale for security objectives
T.NETWORK_ATTACK The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as
this provides for integrity of transmitted data.
The threat T.NETWORK_ATTACK is countered by O.INTEGRITY as this
provides for integrity of software that is installed onto the system from the
network.
The threat T.NETWORK_ATTACK is countered by O.MANAGEMENT as this
provides for the ability to configure the OS to defend against network
attack.
The threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this
provides a mechanism for the OS to report behavior that may indicate a
network attack has occurred.
T.NETWORK_EAVESDROP The threat T.NETWORK_EAVESDROP is countered by
O.PROTECTED_COMMS as this provides for confidentiality of transmitted
data.
The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as
this provides for the ability to configure the OS to protect the confidentiality
of its transmitted data.
T.LOCAL_ATTACK The objective O.INTEGRITY protects against the use of mechanisms that
weaken the TOE with regard to attack by other software on the platform.
The objective O.ACCOUNTABILITY protects against local attacks by
providing a mechanism to report behavior that may indicate a local attack
is occurring or has occurred.
T.LIMITED_PHYSICAL_ACCESS The objective O.PROTECTED_STORAGE protects against unauthorized
attempts to access physical storage used by the TOE.
T.ACCESS.TSFDATA The threat T.ACCESS.TSFDATA of accessing TSF data without proper
authorization is countered by the objective O.DISCRETIONARY.ACCESS
which requires the TOE to provide discretionary access control for TSF data
that should be accessible to properly authorized users and the objective
O.MANAGEMENT which requires the existence of functionality that allows
to assign and manage access rights to those users.
Version: 2.27 Page 29 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Threat Rationale for security objectives
T.ACCESS.USERDATA The threat T.ACCESS.USERDATA of accessing user data without proper
authorization is countered by the objective O.DISCRETIONARY.ACCESS
which requires the TOE to provide discretionary access control for user data
that should be accessible to properly authorized users and the objective
O.MANAGEMENT which requires the existence of functionality that allows
to assign and manage access rights to those users.
T.ACCESS.TSFFUNC The threat T.ACCESS.TSFFUNC of accessing TSF functions without proper
authorization is countered by the objective O.DISCRETIONARY.ACCESS
which requires the TOE to provide some kind of discretionary access control
for TSF functions that should be accessible to properly authorized users and
the objective O.MANAGEMENT which requires the existence of functionality
that allows to assign and manage access rights to those users.
T.IA.MASQUERADE The threat T.IA.MASQUERADE is addressed by the security objectives
O.IA which requires users to be successfully identified and authenticated
eventually using multiple authentication mechanisms (O.IA.MULTIPLE). It
is also addressed by O.MANAGEMENT requiring to manage the users
including their identities and authentication credentials.
T.IA.USER The threat of accessing user data, TSF data or TOE resources without
being identified and authenticated is removed by O.I_A requiring that each
entity interacting with the TOE is properly identified and authenticated
eventually using multiple authentication mechanisms (O.IA_MULTIPLE)
before allowing any action the TOE has defined to provide to authenticated
users only. It is also addressed by O.MANAGEMENT requiring to manage
the users including their identities and authentication credentials.
T.ACCESS.CP.USERDATA The threat of gaining access to user data at rest, which is confidentiality
protected without possessing the authorization of the owner, either
at runtime of the TOE or when the TSF are inactive is removed by
O.PROTECTED_STORAGE requiring the TOE to be able to protect the
confidentiality of user data at rest separately for each user.
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.
Table 4: Sufficiency of objectives holding assumptions
Assumption Rationale for security objectives
A.PLATFORM The operational environment objective OE.PLATFORM is realized through
A.PLATFORM.
A.PROPER_USER The operational environment objective OE.PROPER_USER is realized
through A.PROPER_USER.
A.PROPER_ADMIN The operational environment objective OE.PROPER_ADMIN is realized
through A.PROPER_ADMIN.
A.PHYSICAL The assumption on the IT environment to provide the TOE with appropriate
physical security, commensurate with the value of the IT assets protected
by the TOE is covered by OE.PHYSICAL requiring physical protection.
Version: 2.27 Page 30 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Assumption Rationale for security objectives
A.PEER.MGT The assumption on all remote trusted IT systems to be under the
same management control and operate under security policy constraints
compatible with those of the TOE is covered by OE.TRUSTED.IT.SYSTEM
requiring that these remote trusted IT systems are under the same
management domain as the TOE, and are managed based on the same
rules and policies applicable to the TOE.
A.PEER.FUNC The assumption on all remote trusted IT systems to correctly implement
the functionality used by the TSF consistent with the assumptions defined
for this functionality is covered by OE.TRUSTED.IT.SYSTEM requiring that
the remote trusted IT systems implement the protocols and mechanisms
required by the TSF to support the enforcement of the security policy.
A.CONNECT The assumption on all connections to and from remote trusted IT systems
and between physically separate parts of the TSF not protected by the
TSF itself are physically or logically protected is covered by OE.REMOTE
requiring that remote trusted IT systems provide the functions required
by the TOE and are sufficiently protected from any attack that may
cause those functions to provide false results, and OE.TRUSTED.IT.SYSTEM
demanding the physical and logical protection equivalent to the TOE.
The following rationale provides justification that the security objectives are suitable to cover each
individual organizational security policy (OSP), 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.
Table 5: Sufficiency of objectives enforcing Organizational Security Policies
OSP Rationale for security objectives
P.ACCOUNTABILITY The policy P.ACCOUNTABILITY is addressed by the security objective
O.ACCOUNTABILITY, which requires the TOE to provide functions that allow
administrators to discover issues with the configuration and operation of
the TOE and discover its cause, by the security objective O.AUDITING which
requires that the TSF collects sufficient information that allows to detect
the originator of a problem, and by the security objective O.MANAGEMENT,
which addresses the management of the data collected for accountability.
P.USER The policy P.USER is addressed by the security objective O.MANAGEMENT
which includes also the management of the users (including
administrators) that are allowed to access the TOE.
Version: 2.27 Page 31 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
5 Extended Components Definition
The definition of all SFRs with the appendix of "_EXT" as used in section 6.1"TOE Security Functional
Requirements" is supplied by [PP_OS_V4.3]☝ and [PKG_SSH_V1.0]☝. These SFRs are not defined in this
section.
5.1 Class FCS: Cryptographic support
The presented families extends families of the FCS class in CC part 2.
5.1.1 TLS Protocol (FCS_TLS_PLUS)
Family behaviour
This family states the explicit support for server and/or client support for the TLS family of protocols.
This family differs from the families defined in CC part 2 in a way that it's focus is on the server and/
or client support for the TLS family of protocols.
Component levelling
FCS_TLS_PLUS.1 is not hierarchical to any other component in the FCS_TLS_PLUS family.
Management: FCS_TLS_PLUS.1
There are no management activities foreseen.
Audit: FCS_TLS_PLUS.1
There are no audit events foreseen.
5.1.1.1 FCS_TLS_PLUS.1 TLS Protocol
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLS_PLUS.1.1 The product shall implement [selection:
● TLS as a client,
● TLS as a server.
].
Rationale
This component is used to provide choice of client and/or server support for TLS.
5.1.2 TLS Client Protocol (FCS_TLSC_PLUS)
Family behaviour
This family states explicit cryptographic requirements for the TLS family of protocols. This family differs
from the families defined in CC part 2 in a way that it's focus is the TLS family of protocols as well as
the supported ciphers.
Component levelling
Version: 2.27 Page 32 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
FCS_TLSC_PLUS.1 is not hierarchical to any other component in the FCS_TLSC_PLUS family. There are
are multiple components within this family which are are not hierarchical.
FCS_TLSC_PLUS.2 is not hierarchical to any other component in the FCS_TLSC_PLUS family. There are
are multiple components within this family which are are not hierarchical.
FCS_TLSC_PLUS.5 is not hierarchical to any other component in the FCS_TLSC_PLUS family. There are
are multiple components within this family which are are not hierarchical.
Management: FCS_TLSC_PLUS.1
There are no management activities foreseen.
Management: FCS_TLSC_PLUS.2
There are no management activities foreseen.
Management: FCS_TLSC_PLUS.5
There are no management activities foreseen.
Audit: FCS_TLSC_PLUS.1
There are no audit events foreseen.
Audit: FCS_TLSC_PLUS.2
There are no audit events foreseen.
Audit: FCS_TLSC_PLUS.5
There are no audit events foreseen.
5.1.2.1 FCS_TLSC_PLUS.1 TLS Client Protocol
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLSC_PLUS.1.
1
The product shall implement [selection:
● TLS 1.2 ([RFC5246]☝) supporting the following cipher suites:
[selection:
❍ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝
]
● TLS 1.3 ([RFC8446]☝) supporting the following cipher suites:
[selection:
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]☝
]
] and also supports functionality for [selection:
● mutual authentication,
Version: 2.27 Page 33 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● session renegotiation,
● none
].
FCS_TLSC_PLUS.1.
2
The product shall verify that the presented identifier matches the
reference identifier according to [RFC6125]☝.
FCS_TLSC_PLUS.1.
3
The product shall not establish a trusted channel if the server
certificate is invalid [selection:
● with no exceptions,
● except when override is authorized
].
Rationale
This component is used to provide choice for cipher suites, certificate validation and TLS protocol
versions.
5.1.2.2 FCS_TLSC_PLUS.2 TLS Client Support for Mutual Authentication
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLSC_PLUS.2.
1
The product shall support mutual authentication using X.509v3 certificates.
Rationale
This component is used to provide choice the support of mutual authentication.
5.1.2.3 FCS_TLSC_PLUS.5 TLS Client Support for Supported Groups
Extension
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLSC_PLUS.5.
1
The product shall [selection:
● for TLS 1.2 present the Supported Groups (Elliptic Curves)
Extension in the Client Hello with the following supported groups:
[selection:
❍ secp384r1
❍ secp521r1
]
Version: 2.27 Page 34 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● for TLS 1.3 support the following key exchange modes: ECDHE with
the following key shares: [selection:
❍ secp384r1
❍ secp521r1
]
].
Rationale
This component is used to provide choice for key exchange mechanisms as well as TLS protocol
versions.
5.1.3 TLS Server Protocol (FCS_TLSS_PLUS)
Family behaviour
This family states explicit cryptographic requirements for the TLS family of protocols. This family differs
from the families defined in CC part 2 in a way that it's focus is the TLS family of protocols as well as
the supported ciphers.
Component levelling
FCS_TLSS_PLUS.1 is not hierarchical to any other component in the FCS_TLSS_PLUS family. There are
are multiple components within this family which are are not hierarchical.
FCS_TLSS_PLUS.2 is not hierarchical to any other component in the FCS_TLSS_PLUS family. There are
are multiple components within this family which are are not hierarchical.
Management: FCS_TLSS_PLUS.1
There are no management activities foreseen.
Management: FCS_TLSS_PLUS.2
There are no management activities foreseen.
Audit: FCS_TLSS_PLUS.1
There are no audit events foreseen.
Audit: FCS_TLSS_PLUS.2
There are no audit events foreseen.
5.1.3.1 FCS_TLSS_PLUS.1 TLS Server Protocol
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLSS_PLUS.1.
1
The product shall implement [selection:
● TLS 1.2 ([RFC5246]☝) supporting the following cipher suites:
[selection:
❍ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝
Version: 2.27 Page 35 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝
]
● TLS 1.3 ([RFC8446]☝) supporting the following cipher suites:
[selection:
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]☝
]
] and also supports functionality for [selection:
● mutual authentication,
● session renegotiation,
● none
].
FCS_TLSS_PLUS.1.
2
The product shall deny connections from clients requesting SSL 2.0,
SSL 3.0, TLS 1.0 and [selection: TLS 1.1, none].
FCS_TLSS_PLUS.1.
3
The product shall perform key establishment for TLS using [selection:
● ECDHE parameters using elliptic curves [selection: secp384r1,
secp521r1] and no other curves ,
● no other key establishment methods
].
Rationale
This component is used to provide choice for cipher suites, certificate validation and TLS protocol
versions.
5.1.3.2 FCS_TLSS_PLUS.2 TLS Server Support for Mutual Authentication
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_TLSS_PLUS.2.
1
The product shall support mutual authentication using X.509v3 certificates.
FCS_TLSS_PLUS.2.
2
The product shall not establish a trusted channel if the client certificate is invalid.
FCS_TLSS_PLUS.2.
3
The product shall not establish a trusted channel if the Distinguished Name (DN)
or Subject Alternative Name (SAN) contained in a certificate does not match one
of the expected identifiers for the client.
Rationale
This component is used to provide choice the support of mutual authentication.
Version: 2.27 Page 36 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
5.2 Class FIA: Identification and authentication
The presented families extends families of the FIA class in CC part 2.
5.2.1 X.509 Certificate Validation (FIA_X509_PLUS)
Family behaviour
This family states the explicit support for X.509 certificate based authentication. This family differs
from the families defined in CC part 2 in a way that it's focus is on the the requirements for X.509
certificates and their infrastructure.
Component levelling
FIA_X509_PLUS.1 is not hierarchical to any other component in the FIA_X509_PLUS family.
FIA_X509_PLUS.2 is not hierarchical to any other component in the FIA_X509_PLUS family.
Management: FIA_X509_PLUS.1
There are no management activities foreseen.
Management: FIA_X509_PLUS.2
There are no management activities foreseen.
Audit: FIA_X509_PLUS.1
There are no audit events foreseen.
Audit: FIA_X509_PLUS.2
There are no audit events foreseen.
5.2.1.1 FIA_X509_PLUS.1 X.509 Certificate Validation
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_X509_PLUS.1.
1
The product shall implement functionality to validate certificates in
accordance with the following rules:
● RFC 5280 certificate validation and certificate path validation
● The certificate path must terminate with a trusted CA certificate
● The product shall validate a certificate path by ensuring the
presence of the basicConstraints extension, that the CA flag is set
to TRUE for all CA certificates.
● The product shall validate that any CA certificate includes
"Certificate Signing" as a purpose the key usage field
● The product shall validate the revocation status of the certificate
using [selection: OCSP as specified in RFC 6960, CRL as specified in
RFC 8603, an OCSP TLS Status Request Extension (OCSP stapling)
as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request
Version: 2.27 Page 37 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961 ] with
[selection: no exceptions, [assignment: exceptional use cases and
alternative status check] ]
● The product shall validate the extendedKeyUsage field according to
the following rules:
❍ Server certificates presented for TLS shall have the Server
Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in
the extendedKeyUsage field.
❍ Client certificates presented for TLS shall have the Client
Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in
the EKU field.
❍ OCSP certificates presented for OCSP responses shall have the
OCSP Signing Purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in
the EKU field.
FIA_X509_PLUS.1.
2
The product shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
Rationale
This component is used to state the requirements for X.509 certificate validation in the context of
authentication.
5.2.1.2 FIA_X509_PLUS.2 X.509 Certificate Authentication
Component
relationships
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_X509_PLUS.2.
1
The product shall use X.509v3 certificates as defined by RFC 5280
to support authentication for TLS and [selection: DTLS, HTTPS,
[assignment: other protocols], no other protocols ] connections.
Rationale
This component is used to state the requirements for X.509 certificate based authentication.
Version: 2.27 Page 38 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6 Security Requirements
6.1 TOE Security Functional Requirements
The following SFRs are derived from the following evaluated PPs and their related packages:
● The NIAP "Protection Profile for General Purpose Operating Systems, Version 4.3"
[PP_OS_V4.3]☝ and "Functional Package for Secure Shell (SSH)" [PKG_SSH_V1.0]☝ - SFRs
were reproduced unmodified from this PP and the named functional packages before any
left-open operations have been performed in this document. However, as this ST does not
claim conformance to this PP, their source is left empty.
The ST defines extended components, which are distinguishable from CC Part 2 SFRs by the
ending "_PLUS".
Some of the extended requirements in this ST have been drawn from the [PP_OS_V4.3]☝
and [PKG_SSH_V1.0]☝. The [PP_OS_V4.3]☝ and [PKG_SSH_V1.0]☝ defines the following
extended requirements and since they are not redefined in this ST, the [PP_OS_V4.3]☝ and
[PKG_SSH_V1.0]☝ should thus be consulted for more information in regard to those CC
extensions.
Finally, the SFRs originating from [PP_OS_V4.3]☝, are distinguishable from CC Part 2 SFRs by
the ending _EXT.
● The remainder of the SFRs is taken from [CC] Part 2 and their source is marked as such.
The table below summarizes the SFRs for the TOE and the operations performed on the components
according to CC part 1. Operations in the SFRs use the following convention:
● Iterations (Iter.) are identified by appending a suffix to the original SFR.
● Refinements (Ref.) added to the text are shown in italic text, deletions are shown as
strikethrough text.
● Assignments (Ass.) are shown in bold text.
● Selections (Sel.) are shown in bold text.
Table 6: SFRs for the TOE
Operations
Security
functional
class
Security functional requirement Base
security
functional
component
Source
Iter. Ref. Ass. Sel.
FAU_GEN.1 Audit Data Generation CC Part 2 No Yes Yes Yes
FAU_GEN.2 User identity association CC Part 2 No No No No
FAU_SAR.1 Audit review CC Part 2 No No Yes No
FAU_SAR.2 Restricted audit review CC Part 2 No No No No
FAU_SAR.3 Selectable audit review CC Part 2 No No Yes No
FAU_SEL.1 Selective audit CC Part 2 No No Yes Yes
FAU_STG.1 Protected audit trail
storage
CC Part 2 No No No Yes
FAU - Security
audit
FAU_STG.3 Action in case of
possible audit data loss
CC Part 2 No No Yes No
Version: 2.27 Page 39 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Operations
Security
functional
class
Security functional requirement Base
security
functional
component
Source
Iter. Ref. Ass. Sel.
FAU_STG.4 Prevention of audit data
loss
CC Part 2 No Yes Yes Yes
FCS_CKM.1 Cryptographic Key
Generation
CC Part 2 No Yes Yes No
FCS_CKM.2 Cryptographic Key
Establishment
CC Part 2 No Yes Yes No
FCS_CKM_EXT.4 Cryptographic Key
Destruction
No No No Yes
FCS_COP.1/ENCRYPT Cryptographic
Operation - Encryption/Decryption
FCS_COP.1 CC Part 2 Yes Yes Yes No
FCS_COP.1/HASH Cryptographic
Operation - Hashing
FCS_COP.1 CC Part 2 Yes Yes Yes No
FCS_COP.1/SIGN Cryptographic
Operation - Signing
FCS_COP.1 CC Part 2 Yes Yes Yes No
FCS_COP.1/KEYHMAC Cryptographic
Operation - Keyed-Hash Message
Authentication
FCS_COP.1 CC Part 2 Yes Yes Yes No
FCS_COP.1/IPSEC Cryptographic
operation - IPSec
FCS_COP.1 CC Part 2 Yes Yes Yes No
FCS_RBG_EXT.1 Random Bit
Generation
No No No Yes
FCS_STO_EXT.1 Storage of Sensitive
Data
No No No No
FCS_TLS_PLUS.1 TLS Protocol ECD No No No Yes
FCS_TLSC_PLUS.1 TLS Protocol ECD No No No Yes
FCS_TLSC_PLUS.2 TLS Client
Support for Mutual Authentication
ECD No No No No
FCS_TLSC_PLUS.5 TLS Protocol ECD No No No Yes
FCS_TLSS_PLUS.1 TLS Server
Protocol
ECD No No No Yes
FCS_TLSS_PLUS.2 Server Support
for Mutual Authentication
ECD No No No No
FCS_SSH_EXT.1 SSH Protocol No No Yes Yes
FCS_SSHC_EXT.1 SSH Protocol -
Client
No No No Yes
FCS -
Cryptographic
support
FCS_SSHS_EXT.1 SSH Protocol -
Server
No No No Yes
FDP - User data
protection
FDP_ACF_EXT.1 Access Controls for
Protecting User Data
No No No No
Version: 2.27 Page 40 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Operations
Security
functional
class
Security functional requirement Base
security
functional
component
Source
Iter. Ref. Ass. Sel.
FDP_ACC.1(PSO-MVS) Subset access
control: MVS
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACC.1(PSO-UNIX) Subset
access control: UNIX
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACC.1(TSO) Subset access
control
FDP_ACC.1 CC Part 2 Yes No Yes No
FDP_ACF.1(PSO-MVS) Security
attribute based access control: MVS
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_ACF.1(PSO-UNIX) Security
attribute based access control:
UNIX
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_ACF.1(TSO) Security attribute
based access control: UNIX IPC
FDP_ACF.1 CC Part 2 Yes No Yes No
FDP_RIP.2 Full residual information
protection of resources
CC Part 2 No No No Yes
FIA_AFL.1 Authentication failure
handling
CC Part 2 No Yes Yes Yes
FIA_ATD.1 User attribute definition CC Part 2 No Yes Yes No
FIA_SOS.1 Verification of secrets CC Part 2 No No Yes No
FIA_UAU.1 Timing of authentication CC Part 2 No No Yes No
FIA_UAU.5 Multiple Authentication
Mechanisms
CC Part 2 No Yes Yes No
FIA_UAU.7 Protected authentication
feedback
CC Part 2 No No Yes No
FIA_UID.1 Timing of identification CC Part 2 No No Yes No
FIA_USB.1 User-subject binding CC Part 2 No No Yes No
FIA_X509_PLUS.1 X.509 Certificate
Validation
ECD No No Yes Yes
FIA -
Identification
and
authentication
FIA_X509_PLUS.2 X.509 Certificate
Authentication
ECD No No No Yes
FMT_MOF_EXT.1 Management of
security functions behavior
No Yes No No
FMT_SMF_EXT.1 Specification of
Management Functions
No No No Yes
FMT_MSA.1(PSO-MVS) Management
of object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
FMT - Security
management
FMT_MSA.1(PSO-UNIX) Management
of object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
Version: 2.27 Page 41 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Operations
Security
functional
class
Security functional requirement Base
security
functional
component
Source
Iter. Ref. Ass. Sel.
FMT_MSA.1(TSO) Management of
object security attributes
FMT_MSA.1 CC Part 2 Yes No Yes Yes
FMT_MSA.3(PSO-MVS) Static
attribute initialisation
FMT_MSA.3 CC Part 2 Yes No Yes Yes
FMT_MSA.3(PSO-UNIX) Static
attribute initialisation
FMT_MSA.3 CC Part 2 Yes No Yes Yes
FMT_MSA.3(TSO) Static attribute
initialisation
FMT_MSA.3 CC Part 2 Yes No Yes Yes
FMT_MTD.1 Management of TSF
data
CC Part 2 No No Yes Yes
FMT_SMR.1 Security management
roles
CC Part 2 No No Yes No
FPT_ACF_EXT.1 Access controls No No Yes No
FPT_ASLR_EXT.1 Address Space
Layout Randomization
No No Yes Yes
FPT_SBOP_EXT.1 Stack Buffer
Overflow Protection
No No No Yes
FPT_TST_EXT.1 Boot Integrity No No Yes Yes
FPT_TUD_EXT.1 Trusted Update No No No Yes
FPT_TUD_EXT.2 Trusted Update for
Application Software
No No No No
FPT - Protection
of the TSF
FPT_STM.1 Reliable time stamps CC Part 2 No No No No
FTA_TAB.1 Default TOE access
banners
CC Part 2 No No No No
FTA_SSL.1 TSF-initiated session
locking
CC Part 2 No No Yes No
FTA - TOE access
FTA_SSL.2 User-initiated locking CC Part 2 No No Yes No
FTP_ITC_EXT.1 Trusted channel
communication
No No Yes Yes
FTP_ITC.1 Trusted channel
communication
CC Part 2 No Yes Yes Yes
FTP - Trusted
path/channels
FTP_TRP.1 Trusted Path CC Part 2 No Yes Yes Yes
6.1.1 Security audit (FAU)
6.1.1.1 FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The OS TSF shall be able to generate an audit record of the following auditable
events:
Version: 2.27 Page 42 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) ● Authentication events (Success/Failure);
● Use of privileged/special rights events (Successful and
unsuccessful security, audit, and configuration changes);
● Privilege or role escalation events (Success/Failure);
● ❍ File and object events (Successful and unsuccessful
attempts to create, access, delete, modify, modify
permissions)
❍ User and Group management events (Successful and
unsuccessful add, delete, modify, disable, enable, and
credential change)
❍ Audit and log data access events (Success/Failure)
❍ Administrator or root-level access events (Success/Failure)
❍ FCS_SSH_EXT.1: None
.
FAU_GEN.1.2 The OS TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if applicable),
and 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, user identity, if applicable
.
6.1.1.2 FAU_GEN.2 User identity association
FAU_GEN.2.1 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.
6.1.1.3 FAU_SAR.1 Audit review
FAU_SAR.1.1 The TSF shall provide the authorized administrators with the capability to
read all audit information from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Application Note: In this case, the term "authorized administrators" maps to the AUDITOR or
ROAUDIT role of z/OS or a user with SPECIAL.
6.1.1.4 FAU_SAR.2 Restricted audit review
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those
users that have been granted explicit read-access.
Version: 2.27 Page 43 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.1.5 FAU_SAR.3 Selectable audit review
FAU_SAR.3.1 The TSF shall provide the ability to apply searches of audit data based on the
following attributes:
a) user identity;
b) object type and object name;
6.1.1.6 FAU_SEL.1 Selective audit
FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from the set of all
auditable events based on the following attributes:
a) user identity
b) and the following additional attributes:
1. Outcome (success or failure) of the audit event;
2. object type and object name;
3. Named object identity;
Application Note: RACF allows inclusion of auditable events based on the criteria defined above.
6.1.1.7 FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the audit records
in the audit trail.
Application Note: RACF data set protection needs to be used to protect the files containing audit
records from unauthorized access and modification.
6.1.1.8 FAU_STG.3 Action in case of possible audit data loss
FAU_STG.3.1 The TSF shall generate an alarm to the z/OS operator if the audit trail
exceeds the capacity of the current SMF data set .
Application Note: The TOE switches to the next available SMF data set. Saving the SMF data set
that got filled up can be done automatically or manually.
6.1.1.9 FAU_STG.4 Prevention of audit data loss
FAU_STG.4.1 The TSF shall prevent audited events, except those taken by the
authorised user with special rights authorized administrator and inform
a z/OS operator if the audit trail is full.
Version: 2.27 Page 44 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.2 Cryptographic support (FCS)
6.1.2.1 FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.1.1 The OS TSF shall generate asymmetric cryptographic keys in accordance
with a specified cryptographic key generation algorithm ECC schemes using
and specified cryptographic key sizes "NIST curves" P-384 and P-521 that
meet the following FIPS PUB 186-4, "Digital Signature Standard (DSS)",
Appendix B.4
6.1.2.2 FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The OS TSF shall implement functionality to perform cryptographic keys
establishment in accordance with a specified cryptographic key establishment
distribution method Elliptic curve-based key establishment schemes
that meets the following NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”
6.1.2.3 FCS_CKM_EXT.4 Cryptographic Key Destruction
FCS_CKM_EXT.4.1 The OS shall destroy cryptographic keys and key material in accordance with a
specified cryptographic key destruction method
● For volatile memory, the destruction shall be executed by a
❍ removal of power to the memory
● For non-volatile memory that consists of the invocation of an
interface provided by the underlying platform that
❍ instructs the underlying platform to destroy the abstraction
that represents the key
.
FCS_CKM_EXT.4.2 The OS shall destroy all keys and key material when no longer needed.
6.1.2.4 FCS_COP.1/ENCRYPT Cryptographic Operation - Encryption/
Decryption
FCS_COP.1.1/ENCR
YPT
The OS TSF shall perform encryption/decryption services for data in
accordance with a specified cryptographic algorithm
● AES-XTS
● AES-CBC
● AES-CTR
● AES-GCMP-256
and cryptographic key sizes 256 bit that meet the following
● NIST SP 800-38E for AES-XTS
● NIST SP 800-38A for AES-CBC
Version: 2.27 Page 45 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● NIST SP 800-38A for AES-CTR
● NIST SP 800-38D and IEEE 802.11ac-2013 for AES-GCMP-256
6.1.2.5 FCS_COP.1/HASH Cryptographic Operation - Hashing
FCS_COP.1.1/HASH The OS TSF shall perform cryptographic hashing services in accordance with
a specified cryptographic algorithm
● SHA-256
● SHA-384
● SHA-512
and message digest cryptographic key sizes
● 256 bits
● 384 bits
● 512 bits
that meet the following FIPS Pub 180-4
6.1.2.6 FCS_COP.1/SIGN Cryptographic Operation - Signing
FCS_COP.1.1/SIGN The OS TSF shall perform cryptographic signature services (generation
and verification) in accordance with a specified cryptographic algorithm
● RSA schemes
● ECDSA schemes
and cryptographic key sizes/curves
● 3072-bit or greater for the RSA schemes
● NIST curves P-384 and P-521 for the ECDSA schemes
that meet the following
● FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 5 for
the RSA schemes
● FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 6 for
the ECDSA schemes
Application Note: The TOE in its evaluated configuration and operation does not generate RSA
based signatures.
Application Note: The TOE verifies RSA based signatures in the context of trusted update. ECDSA
signatures are used for communication security and trusted boot.
6.1.2.7 FCS_COP.1/KEYHMAC Cryptographic Operation - Keyed-Hash
Message Authentication
FCS_COP.1.1/KEYH
MAC
The OS TSF shall perform keyed-hash message authentication services in
accordance with a specified cryptographic algorithm
● SHA-256
● SHA-384
● SHA-512
Version: 2.27 Page 46 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
with and cryptographic key sizes
● between 112 and 2048 bits
and and message digest sizes
● 256 bits
● 384 bits
● 512 bits
that meet the following
● FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and
FIPS Pub 180-4 Secure Hash Standard
Application Note: '
The HMAC key is generated by the 'KeyGenerate2' (CSNBKGN2) function of ICSF which allows for key
sizes between 112 and 2048 bit. System SSL generates HMACs during TLS processing.
6.1.2.8 FCS_COP.1/IPSEC Cryptographic operation - IPSec
FCS_COP.1.1 The TSF shall perform encryption, decryption, integrity verification, peer
authentication in accordance with a specified the following cryptographic
algorithm s, [assignment: cryptographic algorithm] cryptographic key
[assignment: cryptographic key sizes] that meet the following sizes and
applicable standards: IPSec with IKE using the following mechanisms:
a) IPSec with IKEv2 allowing the use of AES in CBC mode with 256 bits
key size, and HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512, as
defined by [RFC4301]☝ , [RFC4302]☝ , [RFC4303]☝ , [RFC4304]☝ ,
[RFC4308]☝ , [RFC4754]☝ , [RFC4809]☝ , [RFC4868]☝ , [RFC3602]☝ ,
[RFC3566]☝ , [RFC4753]☝ , [RFC5114]☝ .
b) IPSec with IKEv2 allowing the use of AES in GCM mode with 256
bits key size for confidentiality and data origin authentication, as
defined by [RFC4301]☝ , [RFC4302]☝ , [RFC4303]☝ , [RFC4304]☝ ,
[RFC4308]☝ , [RFC4754]☝ , [RFC4809]☝ , [RFC4868]☝ , [RFC4106]☝ ,
[RFC4753]☝ , [RFC5114]☝ .
6.1.2.9 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The OS shall perform all deterministic random bit generation (DRBG) services in
accordance with NIST Special Publication 800-90A using
● Hash_DRBG (any)
.
FCS_RBG_EXT.1.2 The deterministic RBG used by the OS shall be seeded by an entropy source that
accumulates entropy from a
● platform-based noise source
with a minimum of 256 bits of entropy at least equal to the greatest security
strength (according to NIST SP 800-57) of the keys and hashes that it will
generate.
Version: 2.27 Page 47 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.2.10 FCS_STO_EXT.1 Storage of Sensitive Data
FCS_STO_EXT.1.1 The OS shall implement functionality to encrypt sensitive data stored in
non-volatile storage and provide interfaces to applications to invoke this
functionality.
6.1.2.11 FCS_TLS_PLUS.1 TLS Protocol
FCS_TLS_PLUS.1.1 The product shall implement
● TLS as a client
● TLS as a server
.
6.1.2.12 FCS_TLSC_PLUS.1 TLS Protocol
FCS_TLSC_PLUS.1.
1
The product shall implement
● TLS 1.2 ( [RFC5246]☝ ) supporting the following cipher suites:
❍ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝
● TLS 1.3 ( [RFC8446]☝ ) supporting the following cipher suites:
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]
and also supports functionality for
● mutual authentication
.
FCS_TLSC_PLUS.1.
2
The product shall verify that the presented identifier matches the reference
identifier according to [RFC6125]☝.
FCS_TLSC_PLUS.1.
3
The product shall not establish a trusted channel if the server certificate is
invalid
● with no exceptions
6.1.2.13 FCS_TLSC_PLUS.2 TLS Client Support for Mutual Authentication
FCS_TLSC_PLUS.2.
1
The product shall support mutual authentication using X.509v3 certificates.
6.1.2.14 FCS_TLSC_PLUS.5 TLS Protocol
FCS_TLSC_PLUS.5.
1
The product shall
● for TLS 1.2 present the Supported Groups (Elliptic Curve) Extension
in the Client Hello with the following supported groups:
Version: 2.27 Page 48 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ secp384r1
❍ secp521r1
● for TLS 1.3 support the following key exchange modes: ECDHE with
the following key shares:
❍ secp384r1
❍ secp521r1
.
6.1.2.15 FCS_TLSS_PLUS.1 TLS Server Protocol
FCS_TLSS_PLUS.1.
1
The product shall implement
● TLS 1.2 ( [RFC5246]☝ ) supporting the following cipher suites
❍ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝ ,
❍ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝ ,
● TLS 1.3 ( [RFC8446]☝ ) supporting the following cipher suites:
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]
and also supports functionality for
● mutual authentication
.
FCS_TLSS_PLUS.1.
2
The product shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS
1.0 and TLS 1.1.
FCS_TLSS_PLUS.1.
3
The product shall perform key establishment for TLS using
● ECDHE parameters using elliptic curves
❍ secp384r1
❍ secp521r1
and no other curves ,
.
6.1.2.16 FCS_TLSS_PLUS.2 Server Support for Mutual Authentication
FCS_TLSS_PLUS.2.
1
The product shall support authentication of TLS clients using X.509v3
certificates.
FCS_TLSS_PLUS.2.
2
The product shall not establish a trusted channel if the client certificate is invalid.
FCS_TLSS_PLUS.2.
3
The product shall not establish a trusted channel if the Distinguished Name (DN)
or Subject Alternative Name (SAN) contained in a certificate does not match one
of the expected identifiers for the client.
Version: 2.27 Page 49 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.2.17 FCS_SSH_EXT.1 SSH Protocol
FCS_SSH_EXT.1.1 The TOE shall implement SSH acting as a client, server in accordance with that
complies with RFCs 4251, 4252, 4253, 4254 and 4344, 5647, 5656, no other
RFCs and no other standard.
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods:
● "password" ( [RFC4252]☝ )
● "publickey" ( [RFC4252]☝ ):
❍ ecdsa-sha2-nistp384 ( [RFC5656]☝ ),
❍ ecdsa-sha2-nistp521 ( [RFC5656]☝ ),
and no other methods.
FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in [RFC4253]☝, packets greater than
262144 bytes in an SSH transport connection are dropped.
FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised disclosure using the
following mechanisms:
● aes256-ctr ( [RFC4344]☝ )
● aes256-cbc ( [RFC4253]☝ )
● AEAD_AES_256_GCM ( [RFC5647]☝ )
and no other mechanisms.
FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification, deletion, and insertion
using:
● hmac-sha2-256 ( [RFC6668]☝ )
● hmac-sha2-512 ( [RFC6668]☝ )
● AEAD_AES_256_GCM ( [RFC5647]☝ )
● implicit
and no other mechanisms.
FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using:
● ecdh-sha2-nistp384 ( [RFC5656]☝ )
● ecdh-sha2-nistp521 ( [RFC5656]☝ )
and no other mechanisms.
FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in
● [RFC5656]☝ (Section 4)
to derive the following cryptographic keys from a shared secret: session keys.
FCS_SSH_EXT.1.8 The TSF shall ensure that
● a rekey of the session keys
occurs when any of the following thresholds are met:
Version: 2.27 Page 50 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● one hour connection time
● no more than one gigabyte of transmitted data
● or no more than one gigabyte of received data.
6.1.2.18 FCS_SSHC_EXT.1 SSH Protocol - Client
FCS_SSHC_EXT.1.1 The TSF shall authenticate its peer (SSH server) using:
● using a local database by associating each host name with a public
key corresponding to the following list:
❍ ecdsa-sha2-nistp384 ( [RFC5656]☝ ),
❍ ecdsa-sha2-nistp521 ( [RFC5656]☝ ),
as described in RFC 4251 section 4.1.
6.1.2.19 FCS_SSHS_EXT.1 SSH Protocol - Server
FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client) using:
● ecdsa-sha2-nistp384 ( [RFC5656]☝ ),
● ecdsa-sha2-nistp521 ( [RFC5656]☝ ),
.
6.1.3 User data protection (FDP)
6.1.3.1 FDP_ACF_EXT.1 Access Controls for Protecting User Data
FDP_ACF_EXT.1.1 The OS shall implement access controls which can prohibit unprivileged users
from accessing files and directories owned by other users.
6.1.3.2 FDP_ACC.1(PSO-MVS) Subset access control: MVS
FDP_ACC.1.1 The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy on
a) jobs, started tasks, UNIX processes, and TSO sessions acting on
behalf of users;
b) Objects: Persistent Storage Objects of the following type
1. MVS objects: data sets, programs, System Logger objects
c) Operations: all operations among subjects and objects covered by
the MVS Persistent Storage Object Access Control Policy.
Application Note: A persistent storage object establishes a data storage or data exchange link
between two or more subjects. Examples of persistent storage objects are: datasets, devices,
volumes.
6.1.3.3 FDP_ACC.1(PSO-UNIX) Subset access control: UNIX
Version: 2.27 Page 51 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
FDP_ACC.1.1 The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy on
a) jobs, started tasks, UNIX processes, and TSO sessions acting on
behalf of users;
b) Objects: Persistent Storage Objects of the following type
1. UNIX objects: z/OS UNIX file system objects (regular files,
directories and symbolic links, character special files, UNIX
domain sockets and named pipes (FIFOs);
c) Operations: all operations among subjects and objects covered by
the UNIX Persistent Storage Object Access Control Policy.
Application Note: A persistent storage object establishes a data storage or data exchange link
between two or more subjects. Examples of persistent storage objects are: files, directories.
6.1.3.4 FDP_ACC.1(TSO) Subset access control
FDP_ACC.1.1 The TSF shall enforce the Transient Storage Object Access Control Policy
on
a) jobs, started tasks, UNIX processes , and TSO sessions acting on
behalf of users
b) Objects: Transient Storage Objects of the following type
1. z/OS UNIX IPC objects:
i. shared memory segments, message queues, semaphores
c) Operations: all operations among subjects and objects covered by
the Transient Storage Object Access Control Policy.
Application Note: A transient storage object establishes a data exchange link between two or
more subjects or users. Examples of transient storage objects are: shared memory, semaphores,
message queues, named/unnamed pipes.
6.1.3.5 FDP_ACF.1(PSO-MVS) Security attribute based access control: MVS
FDP_ACF.1.1 The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy to objects based on the following:
a) The user identity and group memberships associated with a
subject;
b) The following access control attributes associated with an object:
1. an access control list capable of defining the access rights
read, update, execute, alter, control, and none for individual
users and groups
2. a default access right (defined by the UACC attribute in the
resource profile) for users who are not addressed in the access
control list
3. an entry for the resource containing the object in the global
access checking table.
Application Note: The semantics of "read", "update", "execute", "alter", and "control" are defined
by the resource manager and follow the intuitive semantics of those terms.
Version: 2.27 Page 52 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Application Note: Any access right hierarchical to read for the profile protecting this data will
therefore still result only in read access to this data. In the case of Operator Commands, the
semantics of the different access rights is defined as part of the description of the command.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: See the description
provided in the TOE Summary Specification , especially sections
Discretionary Access Control and Algorithm to check DAC Access to MVS
Resources .
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: See the description provided in the TOE
Summary Specification , especially sections Discretionary Access Control
and Algorithm to check DAC Access to MVS Resources .
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to named objects based on the
following rules: data sets that are not protected by a discrete or generic
profile can only be accessed by users with the SPECIAL role.
6.1.3.6 FDP_ACF.1(PSO-UNIX) Security attribute based access control:
UNIX
FDP_ACF.1.1 The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy to objects based on the following:
a) The z/OS UNIX user identity and group membership(s) associated
with a subject; and
b) The following access control attributes associated with an object:
permission bits and (for file system objects) an access control
list capable of defining access rights read, write, execute, or
search. Default access rights are defined by a system management
attribute.
Access rights for file system objects are:
a) read
b) write
c) execute (ordinary files)
d) search (directories)
Access is defined by POSIX ACLs and permission bits. ACLs are
evaluated only when the FSSEC class is active in RACF. Users who
have the AUDITOR attribute have implicit SEARCH and READ access for
directories, without needing explicit permission via the permission bits
or ACLs.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: See the description
provided in the TOE Summary Specification , especially sections
Discretionary Access Control and Algorithm to check DAC access to UNIX file
system objects .
Version: 2.27 Page 53 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: See the description provided in the TOE
Summary Specification , especially sections Discretionary Access Control
and Algorithm to check DAC access to UNIX file system objects .
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to named objects based on the
following rules: the SUPERUSER.FILESYS.DIRSRCH profile in the UNIXPRIV
class can be used to deny execute access to all files in a file system.
6.1.3.7 FDP_ACF.1(TSO) Security attribute based access control: UNIX IPC
FDP_ACF.1.1 The TSF shall enforce the Transient Storage Object Access Control Policy to
objects based on the following:
a) The z/OS UNIX user identity and group membership(s) associated
with a subject; and
b) The following access control attributes associated with an object:
permission bits. Default access rights are defined by a system
management attribute.
Access rights for z/OS UNIX IPC objects are:
a) read
b) write
Access is defined by permission bits only.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: See the description
provided in the TOE Summary Specification , especially sections
Discretionary Access Control and Algorithm to check DAC access to UNIX IPC
objects .
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to named objects based on the
following rules: none.
6.1.3.8 FDP_RIP.2 Full residual information protection of resources
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the allocation of the resource to all objects.
6.1.4 Identification and authentication (FIA)
6.1.4.1 FIA_AFL.1 Authentication failure handling
FIA_AFL.1.1 The OS TSF shall detect when
Version: 2.27 Page 54 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● an administrator configurable positive integer within a range of
positive integers from 1 to 255
unsuccessful authentication attempts occur related to events with
authentication based on user name and password
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts for an
account has been met, the OS TSF shall: Account Disablement.
6.1.4.2 FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual human users:
a) User identifier;
b) Group memberships;
c) User password or password phrase;
d) Security roles;
e) default access rights for objects created by the user (UACC);
f) classes in which the user can define profiles (CLAUTH);
g) indicator that global access checking, the ID(*) entry on the access
list, and the UACC will not be used to allow this user access to a
protected resource (RESTRICTED);
h) z/OS UNIX UID (for users also defined to UNIX System Services);
i) z/OS UNIX group memberships;
j) X.509v3 certificate(s).
6.1.4.3 FIA_SOS.1 Verification of secrets
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the following
quality metric: the probability that a secret can be obtained by an
attacker during the lifetime of the secret is less than 2^-20.
Application Note: Some authentication functions depend on cryptographic functions, such as
certificate-based client authentication. No strength of function analysis is provided in this ST for
these, nor for any cryptographic key generation functions that may be a part of the identification and
authentication mechanisms.
6.1.4.4 FIA_UAU.1 Timing of authentication
FIA_UAU.1.1 The TSF shall allow
a) all functions allowed to be performed by the individual pseudo-user
assigned by the authorized administrator for started procedures
(started tasks)
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
Version: 2.27 Page 55 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.4.5 FIA_UAU.5 Multiple Authentication Mechanisms
FIA_UAU.5.1 The OS TSF shall provide the following authentication mechanisms
● authentication based on user name and password
● for use in SSH only, SSH public key-based authentication as
specified by the Functional Package for Secure Shell (SSH), version
1.0
to support user authentication.
FIA_UAU.5.2 The OS TSF shall authenticate any user's claimed identity according to the
following rule:
● authentication on (virtual 3270) terminals and the operating
system console is based on user name and password or
passphrase,
● authentication via the SSHv2 protocol using:
❍ user name and password authentication;
❍ public key based authentication
.
6.1.4.6 FIA_UAU.7 Protected authentication feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the user while the
authentication is in progress.
6.1.4.7 FIA_UID.1 Timing of identification
FIA_UID.1.1 The TSF shall allow
a) no actions
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
6.1.4.8 FIA_USB.1 User-subject binding
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting
on the behalf of that user:
a) The RACF user identity that is associated with auditable events;
b) The RACF or UNIX user security attributes that are used to
(respectively) enforce the MVS and UNIX Persistent Storage Object
Access Control Policies;
c) The RACF or UNIX user security attributes that are used to enforce
the Transient Storage Object Access Control Policy;
d) Active roles;
Version: 2.27 Page 56 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
e) Active groups;
f) the RACF attributes/roles SPECIAL, group-SPECIAL, AUDITOR,
ROAUDIT, group-AUDITOR, CLAUTH, OPERATIONS, and group-
OPERATIONS.
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security
attributes with subjects acting on the behalf of users:
a) A started task executes with the user ID defined in the started
class or started procedures table defining the started task.
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users:
a) A z/OS administrator may define specific z/OS applications to
execute with an administrator defined user ID.
b) A z/OS administrator may use the SURROGAT authority mechanism
to allow a user to switch his identity to another defined user (e.
g. submitting jobs or changing the ID with the su command in the
z/OS UNIX System Services environment) without specifying the
password/phrase for this user.
In z/OS UNIX, the following additional rules apply:
a) The su command provides the ability to create a new session
with a new set of credentials (to be inherited by subjects created
within this session). The credentials are set to the UID (RUID and
EUID), GID (RGID and EGID), and supplementary groups of the
user requested. The user issuing the su command must have the
authority to use this command, have the authority to switch to the
specified UID and either authenticates properly for this UID with
the password/phrase , has the SURROGAT authority for the new
UID or has BPX.SUPERUSER authority allowing him to switch to UID 0
without supplying a password/phrase.
b) If the BPX.DAEMON profile exists in the FACILITY class of RACF, a
user with UID 0 needs to have authority other than NONE to this
profile to change his UID using the setuid or seteuid system calls.
Application Note: In the z/OS BCP, a temporary change of the user ID is not implemented. In z/
OS UNIX System Services this is possible with a slightly-modified semantic compared to other UNIX
systems.
6.1.4.9 FIA_X509_PLUS.1 X.509 Certificate Validation
FIA_X509_PLUS.1.
1
The product shall implement functionality to validate certificates in accordance
with the following rules:
● [RFC5280]☝ certificate validation and certificate path validation.
● The certificate path must terminate with a trusted CA certificate.
● The product shall validate a certificate path by ensuring the presence of
the basicConstraints extension and that the CA flag is set to TRUE for all CA
certificates.
Version: 2.27 Page 57 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● The product shall validate that any CA certificate includes "Certificate
Signing" as a purpose the key usage field
● The product shall validate the revocation status of the certificate using
OCSP as specified in [RFC6960]☝ , with the exception of the TOE's
TCP/IP stack being configured to not validate certificates using an
OCSP service.
● The product shall validate the extendedKeyUsage field according to the
following rules:
❍ Server certificates presented for TLS shall have the Server
Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the
extendedKeyUsage field.
❍ Client certificates presented for TLS shall have the Client
Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the EKU
field.
❍ OCSP certificates presented for OCSP responses shall have the OCSP
Signing Purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the EKU field.
.
FIA_X509_PLUS.1.
2
The product shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
6.1.4.10 FIA_X509_PLUS.2 X.509 Certificate Authentication
FIA_X509_PLUS.2.
1
The OS shall use X.509v3 certificates as defined by [RFC5280]☝ to support
authentication for TLS and no other protocols connections.
6.1.5 Security management (FMT)
6.1.5.1 FMT_MOF_EXT.1 Management of security functions behavior
FMT_MOF_EXT.1.1 The OS shall restrict the ability to perform the function indicated in the
"Administrator" column in FMT_SMF_EXT.1 to the administrator.
6.1.5.2 FMT_SMF_EXT.1 Specification of Management Functions
FMT_SMF_EXT.1.1 The OS shall be capable of performing the following management functions:
a) Enable/disable session timeout
b) Configure session inactivity timeout
c) Configure local audit storage capacity
d) Configure minimum password length
e) Configure minimum number of special characters in password
f) Configure minimum number of numeric characters in password
g) Configure minimum number of uppercase characters in password
Version: 2.27 Page 58 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
h) Configure lockout policy for unsuccessful authentication attempts through
timeouts between attempts, limiting number of attempts during a
time period
i) Configure host-based firewall
j) Configure audit rules
.
6.1.5.3 FMT_MSA.1(PSO-MVS) Management of object security attributes
FMT_MSA.1.1 The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy to restrict the ability to modify the security attributes of the objects
covered by the SFP to
a) the owner of the object;
b) users with the SPECIAL attribute or the appropriate group-SPECIAL
attribute and
c) users who have ALTER authority to the object
.
6.1.5.4 FMT_MSA.1(PSO-UNIX) Management of object security attributes
FMT_MSA.1.1 The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy to restrict the ability to modify the security attributes of the objects
covered by the SFP to
a) the owner of the object;
b) a user with z/OS UNIX superuser privilege
.
6.1.5.5 FMT_MSA.1(TSO) Management of object security attributes
FMT_MSA.1.1 The TSF shall enforce the Transient Storage Object Access Control Policy to
restrict the ability to modify the security attributes of the objects covered by
the SFP to
a) the owner of the object;
b) for z/OS UNIX IPC objects to a user with z/OS UNIX superuser
privilege
.
6.1.5.6 FMT_MSA.3(PSO-MVS) Static attribute initialisation
FMT_MSA.3.1 The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy to provide restrictive default values for security attributes that are used
to enforce the SFP.
Version: 2.27 Page 59 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
FMT_MSA.3.2 The TSF shall allow the users with the SPECIAL attribute and the owner
of the profile protecting the object to specify alternative initial values to
override the default values when an object or information is created.
6.1.5.7 FMT_MSA.3(PSO-UNIX) Static attribute initialisation
FMT_MSA.3.1 The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy to provide restrictive default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the user with the z/OS UNIX superuser privilege and
the owner of the profile protecting the object to specify alternative initial
values to override the default values when an object or information is created.
6.1.5.8 FMT_MSA.3(TSO) Static attribute initialisation
FMT_MSA.3.1 The TSF shall enforce the Transient Storage Object Access Control Policy
to provide restrictive default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the users with the SPECIAL attribute and the owner
of the profile protecting the object to specify alternative initial values to
override the default values when an object or information is created.
6.1.5.9 FMT_MTD.1 Management of TSF data
FMT_MTD.1.1 The TSF shall restrict the ability to query, modify the full set of audited
events to
a) users with the AUDITOR role (query and modify)
b) users with the ROAUDIT role (query only)
c) for events related to a profile: the profile owner.
.
Application Note: This SFR applies to FAU_SEL.1.
6.1.5.10 FMT_SMR.1 Security management roles
FMT_SMR.1.1 The TSF shall maintain the roles:
a) User role with the following rights:
1. Users are authorized to modify their own user password;
2. Users are authorized to modify the access control permissions
for the named objects they own;
b) users authorized by the discretionary access control policy to
modify object security attributes;
c) users authorized to modify their own authentication data;
Version: 2.27 Page 60 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
d) users authorized to perform administrative actions within a defined
group (group-SPECIAL attribute);
e) users authorized to perform administrative actions for user or
group security attributes via ownership;
f) RACF auditors (users who have the RACF AUDITOR attribute in their
profiles);
g) RACF read-only auditors (users who have the RACF ROAUDIT
attribute in their profile);
h) RACF group auditors (users who have the RACF group-AUDITOR
attribute in their profiles);
i) Operations roles (users with the OPERATIONS attribute);
j) z/OS operators (users who are allowed to issue operator
commands);
k) z/OS UNIX superuser;
l) Users authorized to perform other management functions based
on access rights to RACF profiles protecting the individual
management operations
m) authorized administrator (user with the SPECIAL attribute).
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
6.1.6 Protection of the TSF (FPT)
6.1.6.1 FPT_ACF_EXT.1 Access controls
FPT_ACF_EXT.1.1 The OS shall implement access controls which prohibit unprivileged users from
modifying:
a) Kernel and its drivers/modules
b) Security audit logs
c) Shared libraries
d) System executables
e) System configuration files
f) protected MVS data sets and other z/OS objects, protected UNIX
file system objects, protected UNIX IPC objects
.
FPT_ACF_EXT.1.2 The OS shall implement access controls which prohibit unprivileged users from
reading:
a) Security audit logs
b) System-wide credential repositories
c) protected MVS data sets, protected UNIX file system objects
.
Version: 2.27 Page 61 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.6.2 FPT_ASLR_EXT.1 Address Space Layout Randomization
FPT_ASLR_EXT.1.1 The OS shall always randomize process address space memory locations with 8
bits of entropy except for the lower 16 MB of memory .
6.1.6.3 FPT_SBOP_EXT.1 Stack Buffer Overflow Protection
FPT_SBOP_EXT.1.1 The OS shall employ stack-based buffer overflow protections.
6.1.6.4 FPT_TST_EXT.1 Boot Integrity
FPT_TST_EXT.1.1 The OS shall verify the integrity of the bootchain up through the OS kernel and
● all executable code stored in mutable media
● IPL Text (IEAIPL00) (validated by firmware (Z Bootloader))
All load modules through LPA creation:
❍ IRIMs and RIMs (up through LPA creation)
❍ SYS1.NUCLEUS load modules including z/OS Nucleus
(IEANUCxx)
❍ LPA load modules (LPALST concatenation) and MLPA/FLPA load
modules
● no other executable code
prior to its execution through the use of
● a digital signature using a hardware-protected asymmetric key
.
6.1.6.5 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1 The OS shall provide the ability to check for updates to the OS software itself and
shall use a digital signature scheme specified in FCS_COP.1/SIGN to validate the
authenticity of the response.
FPT_TUD_EXT.1.2 The OS shall cryptographically verify updates to itself using a digital signature
prior to installation using schemes specified in FCS_COP.1/SIGN.
6.1.6.6 FPT_TUD_EXT.2 Trusted Update for Application Software
FPT_TUD_EXT.2.1 The OS shall provide the ability to check for updates to application software and
shall use a digital signature scheme specified in FCS_COP.1/SIGN to validate the
authenticity of the response.
FPT_TUD_EXT.2.2 The OS shall cryptographically verify the integrity of updates to applications
using a digital signature specified by FCS_COP.1/SIGN prior to installation.
Version: 2.27 Page 62 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.6.7 FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
6.1.7 TOE access (FTA)
6.1.7.1 FTA_TAB.1 Default TOE access banners
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorized use of the TOE.
6.1.7.2 FTA_SSL.1 TSF-initiated session locking
FTA_SSL.1.1 The TSF shall lock an interactive session after an administrator-configurable
time interval of user inactivity by:
a) clearing or overwriting display devices, making the current contents
unreadable;
b) disabling any activity of the user's data access/display devices other than
unlocking the session.
FTA_SSL.1.2 The TSF shall require the following events to occur prior to unlocking the session:
a) Successful re-authentication with the credentials of the user
owning the session using one of the authentication methods out of
the list of allowed methods specified in FIA_UAU.5 ;
Application Note: This SFR applies to directly attached terminals, not networked sessions.
Application Note: It is possible that the TSF establishes a connection to a session on a remote
trusted IT system, for example when using SSH. This remote trusted IT system maintains the session
established with the communication channel. The locking requirement however applies to the session
maintained by the TSF only as the TSF can only exercise control of the sessions it maintains.
6.1.7.3 FTA_SSL.2 User-initiated locking
FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user's own interactive session,
by:
a) clearing or overwriting display devices, making the current contents
unreadable;
b) disabling any activity of the user's data access/display devices other than
unlocking the session.
FTA_SSL.2.2 The TSF shall require the following events to occur prior to unlocking the session:
a) Successful re-authentication with the credentials of the user
owning the session using one of the authentication methods from
the list of allowed methods specified in FIA_UAU.5 ;
Application Note: This SFR applies to directly attached terminals, not networked sessions.
Version: 2.27 Page 63 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.1.8 Trusted path/channels (FTP)
6.1.8.1 FTP_ITC_EXT.1 Trusted channel communication
FTP_ITC_EXT.1.1 The OS shall use
● SSH as conforming to the Functional Package for Secure Shell
(SSH), version 1.0 as a client, server
to provide a trusted communication channel between itself and authorized IT
entities supporting the following capabilities:
● remote access
that is logically distinct from other communication channels and provides
assured identification of its end points and protection of the channel data from
disclosure and detection of modification of the channel data.
6.1.8.2 FTP_ITC.1 Trusted channel communication
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another
trusted IT product that is logically distinct from other communication channels
and provides assured identification of its end points and protection of
the channel data from modification or and disclosure using the following
mechanisms:
● Cryptographically-protected communication channel using the IPSec
protocol offered by TOE services using cipher suites defined in FCS_COP.1/
ENCRYPT , FCS_COP.1/HASH , FCS_COP.1/SIGN , FCS_COP.1/KEYHMAC ,
FCS_COP.1/IPSEC ;
● Cryptographically protected communication channel using the TLS protocols
versions 1.2 and 1.3 offered by TOE services using cipher and protocol
suites defined in FCS_TLS_PLUS.1 , FCS_TLSC_PLUS.1 , FCS_TLSC_PLUS.2 ,
FCS_TLSC_PLUS.5 , FCS_TLSS_PLUS.1 , FCS_TLSS_PLUS.2 .
FTP_ITC.1.2 The TSF shall permit the TSF, another trusted IT product to initiate
communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for all security
functions specified in the ST that interact with remote trusted IT
systems and no other functions and conditions. .
6.1.8.3 FTP_TRP.1 Trusted Path
FTP_TRP.1.1 The OS TSF shall provide a communication path between itself and remote,
local users that is logically distinct from other communication paths and
provides assured identification of its endpoints and protection of the
communicated data from modification, disclosure.
FTP_TRP.1.2 The OS TSF shall permit the TSF, local users, remote users to initiate
communication via the trusted path.
Version: 2.27 Page 64 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
FTP_TRP.1.3 The OS TSF shall require use of the trusted path for all remote administrative
actions.
6.2 Security Functional Requirements Rationale
The basis for the justification of EAL4 augmented with ALC_FLR.3 is the threat environment experienced
by the typical consumers of the TOE. This matches the package description for EAL4 (enhanced-basic).
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.
Table 7: Mapping of security functional requirements to security objectives
Security functional requirements Objectives
FAU_GEN.1 O.ACCOUNTABILITY,
O.AUDITING
FAU_GEN.2 O.ACCOUNTABILITY,
O.AUDITING
FAU_SAR.1 O.AUDITING
FAU_SAR.2 O.AUDITING
FAU_SAR.3 O.AUDITING
FAU_SEL.1 O.AUDITING
FAU_STG.1 O.AUDITING
FAU_STG.3 O.AUDITING
FAU_STG.4 O.AUDITING
FCS_CKM.1 O.PROTECTED_COMMS
FCS_CKM.2 O.PROTECTED_COMMS
FCS_CKM_EXT.4 O.PROTECTED_COMMS
FCS_COP.1/ENCRYPT O.PROTECTED_COMMS,
O.PROTECTED_STORAGE
FCS_COP.1/HASH O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1/SIGN O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1/KEYHMAC O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1/IPSEC O.PROTECTED_COMMS
FCS_RBG_EXT.1 O.PROTECTED_COMMS,
O.PROTECTED_STORAGE
FCS_STO_EXT.1 O.PROTECTED_STORAGE
FCS_TLS_PLUS.1 O.PROTECTED_COMMS
Version: 2.27 Page 65 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security functional requirements Objectives
FCS_TLSC_PLUS.1 O.PROTECTED_COMMS
FCS_TLSC_PLUS.2 O.PROTECTED_COMMS
FCS_TLSC_PLUS.5 O.PROTECTED_COMMS
FCS_TLSS_PLUS.1 O.PROTECTED_COMMS
FCS_TLSS_PLUS.2 O.PROTECTED_COMMS
FCS_SSH_EXT.1 O.PROTECTED_COMMS
FCS_SSHC_EXT.1 O.PROTECTED_COMMS
FCS_SSHS_EXT.1 O.PROTECTED_COMMS
FDP_ACF_EXT.1 O.PROTECTED_STORAGE
FDP_ACC.1(PSO-MVS) O.DISCRETIONARY.ACCESS
FDP_ACC.1(PSO-UNIX) O.DISCRETIONARY.ACCESS
FDP_ACC.1(TSO) O.DISCRETIONARY.ACCESS
FDP_ACF.1(PSO-MVS) O.DISCRETIONARY.ACCESS
FDP_ACF.1(PSO-UNIX) O.DISCRETIONARY.ACCESS
FDP_ACF.1(TSO) O.DISCRETIONARY.ACCESS
FDP_RIP.2 O.AUDITING,
O.DISCRETIONARY.ACCESS,
O.IA
FIA_AFL.1 O.IA,
O.INTEGRITY
FIA_ATD.1 O.INTEGRITY
FIA_SOS.1 O.IA
FIA_UAU.1 O.IA,
O.INTEGRITY
FIA_UAU.5 O.IA,
O.IA.MULTIPLE,
O.INTEGRITY
FIA_UAU.7 O.IA
FIA_UID.1 O.IA,
O.INTEGRITY
FIA_USB.1 O.IA
FIA_X509_PLUS.1 O.INTEGRITY,
O.PROTECTED_COMMS
FIA_X509_PLUS.2 O.PROTECTED_COMMS
FMT_MOF_EXT.1 O.MANAGEMENT
FMT_SMF_EXT.1 O.MANAGEMENT
FMT_MSA.1(PSO-MVS) O.MANAGEMENT
Version: 2.27 Page 66 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security functional requirements Objectives
FMT_MSA.1(PSO-UNIX) O.MANAGEMENT
FMT_MSA.1(TSO) O.MANAGEMENT
FMT_MSA.3(PSO-MVS) O.MANAGEMENT
FMT_MSA.3(PSO-UNIX) O.MANAGEMENT
FMT_MSA.3(TSO) O.MANAGEMENT
FMT_MTD.1 O.MANAGEMENT
FMT_SMR.1 O.MANAGEMENT
FPT_ACF_EXT.1 O.INTEGRITY
FPT_ASLR_EXT.1 O.INTEGRITY
FPT_SBOP_EXT.1 O.INTEGRITY
FPT_TST_EXT.1 O.INTEGRITY
FPT_TUD_EXT.1 O.INTEGRITY
FPT_TUD_EXT.2 O.INTEGRITY
FPT_STM.1 O.ACCOUNTABILITY
FTA_TAB.1 O.MANAGEMENT
FTA_SSL.1 O.IA
FTA_SSL.2 O.IA
FTP_ITC_EXT.1 O.ACCOUNTABILITY,
O.INTEGRITY,
O.PROTECTED_COMMS
FTP_ITC.1 O.ACCOUNTABILITY,
O.INTEGRITY,
O.PROTECTED_COMMS
FTP_TRP.1 O.MANAGEMENT
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.
Table 8: Security objectives for the TOE rationale
Security objectives Rationale
O.ACCOUNTABILITY FAU_GEN.1 defines the auditable events which result in audit records that
must be generated to diagnose the cause of unexpected system behavior.
FTP_ITC_EXT.1 provides a mechanism for the TSF to transmit the audit data
to a remote system.
Events are associated with the identity of the user that caused the event
(FAU_GEN.2). To support auditing, the TOE is able to maintain proper time
stamps (FPT_STM.1). FTP_ITC.1 provides further mechanisms for the TSF to
transmit the audit data to a remote system.
Version: 2.27 Page 67 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security objectives Rationale
O.INTEGRITY FPT_SBOP_EXT.1 and FPT_ASLR_EXT.1 supports the objective by requiring
that OS applications be hardened against buffer overflow attacks.
FPT_TUD_EXT.1 supports the objective by requiring that the OS be able
to check for critical updates. FPT_TUD_EXT.2 supports the objective by
requiring that the OS verify updates before applying them. FCS_COP.1/
HASH supports the objective by requiring the TSF to implement hash
algorithms that are used in support of protected communications.
FCS_COP.1/SIGN supports the objective by requiring the TSF to implement
digital signature algorithms that are used in support of protected
communications. FCS_COP.1/KEYHMAC supports the objective by requiring
the TSF to implement HMAC algorithms that are used in support of
protected communications. FPT_ACF_EXT.1 supports the objective by
requiring the TSF restrict unprivileged users from changing critical
components. FIA_X509_PLUS.1 supports the objective by requiring the TSF
to validate certificates using industry standards. FPT_TST_EXT.1 supports
the objective by requiring the TSF to verify executable code critical to its
operation. FTP_ITC_EXT.1 supports the objective by requiring the OS to
provide a trusted channel for critical communication. FIA_AFL.1 supports
the objective by requiring the TSF to respond accordingly when the
number of failed authentication attempts reaches a specified threshold.
FIA_UAU.5 supports the objective by requiring the OS to provide standard
authentication mechanisms.
To facilitate the application of any policies, the subject must be
authenticated (FIA_UAU.1) identified (FIA_UID.1) based on security
attributes the TOE can maintain (FIA_ATD.1). FTP_ITC.1 provides further
trusted remote communications which makes a remote authenticated
session less susceptible to compromise.
O.MANAGEMENT FMT_SMF_EXT.1 supports this objective by requiring the TOE to restrict
the ability to perform certain management functions to a privileged user.
FMT_MOF_EXT.1 supports this objective by requiring the TOE to implement
specific management functions. FTP_TRP.1 supports this objective by
requiring the TOE to implement a trusted path between the itself and users.
FTA_TAB.1 supports this objective by requiring a trusted path between
users and the OS.
Audit events as well the policy can be managed (FMT_MTD.1) as
well as the general control of management actions is provided by
the TOE (FMT_MSA.1(PSO-MVS), FMT_MSA.1(PSO-UNIX), FMT_MSA.3(PSO-
MVS), FMT_MSA.3(PSO-UNIX), FMT_MSA.1(TSO), FMT_MSA.3(TSO)). The
TOE's support of roles supports the objective (FMT_SMR.1).
O.PROTECTED_STORAGE FCS_STO_EXT.1 supports this objective by requiring the OS to provide
encrypted storage. FCS_COP.1/ENCRYPT supports this objective by
requiring the OS to generate random bits according to industry standards.
FCS_RBG_EXT.1 supports this objective requiring the OS to generate
random bits according to industry standards. FDP_ACF_EXT.1 supports this
objective by requiring the OS to implement access controls.
O.PROTECTED_COMMS FCS_RBG_EXT.1 supports this objective by requiring the OS to generate
random bits according to industry standards. FCS_CKM.1 supports this
objective by requiring the TSF to generate asymmetric cryptographic keys
to industry standards. FCS_CKM.2 supports this objective by requiring
the TSF to perform key establishment according to industry standards.
FCS_CKM_EXT.4 supports this objective by requiring the TSF to destroy key
material according to industry standards. FCS_COP.1/ENCRYPT supports
this objective by requiring the TSF to encrypt data according to industry
Version: 2.27 Page 68 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security objectives Rationale
standards FCS_COP.1/HASH supports this objective by requiring the TSF
to hash data according to industry standards. FCS_COP.1/SIGN supports
this objective by requiring the TSF to cryptographically sign data according
to industry standards. FCS_COP.1/KEYHMAC supports this objective by
requiring the TSF to perform keyed hashes according to industry standards.
FIA_X509_PLUS.1 supports the objective by requiring the TSF to validate
certificates using industry standards. FIA_X509_PLUS.2 supports this
objective by requiring the TSF to validate TLS and related encrypted
connections with x509 certificates. FTP_ITC_EXT.1 supports the objective
by requiring the OS to provide a trusted channel for critical communication.
FCS_SSH_EXT.1, FCS_SSHC_EXT.1, FCS_SSHS_EXT.1 define the ability of
the TOE to act as an SSH client/server as a method of enforcing protected
communications. FCS_TLS_PLUS.1, FCS_TLSC_PLUS.1, FCS_TLSC_PLUS.2,
FCS_TLSC_PLUS.5, FCS_TLSS_PLUS.1, FCS_TLSS_PLUS.2, FCS_COP.1/IPSEC
defines the TOE's ability to communicate using the IPSec and TLS version
1.2 and 1.3 protocols using the trusted channel defined in FTP_ITC.1.
O.AUDITING The events to be audited are defined in FAU_GEN.1 and are associated
with the identity of the user that caused the event (FAU_GEN.2). Authorized
users are provided the capability to read the audit records (FAU_SAR.1),
while all other users are denied access to the audit records (FAU_SAR.2).
Audit trails can be searched for events belonging to users, objects, or labels
(FAU_SAR.3). The authorized user must have the capability to specify which
audit records are generated (FAU_SEL.1). The TOE prevents the audit log
from being modified or deleted (FAU_STG.1) and ensures that the audit log
is not lost due to resource shortage (FAU_STG.3, FAU_STG.4). To support
auditing, the TOE is able to maintain proper time stamps (FPT_STM.1).
The protection of reused resources ensures that no data leaks from other
protected sources (FDP_RIP.2).
O.DISCRETIONARY.ACCESS The TSF must control access to resources based on the identity of users
that are allowed to specify which resources they want to access for storing
their data.
The access control policy must have a defined scope of control
(FDP_ACC.1(PSO-MVS), FDP_ACC.1(PSO-UNIX), FDP_ACC.1(TSO)). The rules
for the access control policy are defined (FDP_ACF.1(PSO-MVS),
FDP_ACF.1(PSO-UNIX), FDP_ACF.1(TSO)).
The protection of reused resources ensures that no data leaks from other
protected sources (FDP_RIP.2).
O.IA The TSF must ensure that only authorized users gain access to the
TOE and its resources. Users authorized to access the TOE must
use an identification and authentication process (FIA_UID.1, FIA_UAU.1).
Multiple I&A mechanisms are allowed as specified in FIA_UAU.5. To
ensure authorized access to the TOE, authentication data is protected
(FIA_ATD.1, FIA_UAU.7). Proper authorization for subjects acting on behalf
of users is also ensured (FIA_USB.1). The appropriate strength of the
authentication mechanism is ensured (FIA_SOS.1). To support the strength
of authentication methods, the TOE is capable of identifying and reacting
to unsuccessful authentication attempts (FIA_AFL.1). In addition, user-
initiated and TSF-initiated session timeout (FTA_SSL.1, FTA_SSL.2) protect
the authenticated user's session.
The protection of reused resources ensures that no data leaks from other
protected sources (FDP_RIP.2).
Version: 2.27 Page 69 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security objectives Rationale
O.IA.MULTIPLE The TOE shall provide multiple I&A policies, at least one for local and one
for remote I&A which is specified with FIA_UAU.5.
6.2.3 Security Requirements Dependency Analysis
The following table demonstrates the dependencies of the SFRs modeled in CC Part 2 and the extended
component definition in this Security Target, and how the SFRs for the TOE resolve those dependencies.
Table 9: TOE SFR dependency analysis
Security functional
requirement
Dependencies Resolution
FAU_GEN.1 FPT_STM.1 FPT_STM.1
FAU_GEN.1 FAU_GEN.1
FAU_GEN.2
FIA_UID.1 FIA_UID.1
FAU_SAR.1 FAU_GEN.1 FAU_GEN.1
FAU_SAR.2 FAU_SAR.1 FAU_SAR.1
FAU_SAR.3 FAU_SAR.1 FAU_SAR.1
FAU_GEN.1 FAU_GEN.1
FAU_SEL.1
FMT_MTD.1 FMT_MTD.1
FAU_STG.1 FAU_GEN.1 FAU_GEN.1
FAU_STG.3 FAU_STG.1 FAU_STG.1
FAU_STG.4 FAU_STG.1 FAU_STG.1
[FCS_CKM.2 or FCS_COP.1] FCS_CKM.2
FCS_COP.1/ENCRYPT
FCS_COP.1/HASH
FCS_COP.1/SIGN
FCS_COP.1/KEYHMAC
FCS_CKM.1
FCS_CKM.4 FCS_CKM_EXT.4
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_CKM.2
FCS_CKM.4 FCS_CKM_EXT.4
FCS_CKM_EXT.4 No dependencies
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_COP.1/ENCRYPT
FCS_CKM.4 FCS_CKM_EXT.4
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_COP.1/HASH
FCS_CKM.4 FCS_CKM_EXT.4
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_COP.1/SIGN
FCS_CKM.4 FCS_CKM_EXT.4
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_COP.1/KEYHMAC
FCS_CKM.4 FCS_CKM_EXT.4
Version: 2.27 Page 70 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security functional
requirement
Dependencies Resolution
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] FCS_CKM.1
FCS_COP.1/IPSEC
FCS_CKM.4 FCS_CKM_EXT.4
FCS_RBG_EXT.1 No dependencies
FCS_STO_EXT.1 No dependencies
FCS_TLS_PLUS.1 No dependencies
FCS_TLSC_PLUS.1 No dependencies
FCS_TLSC_PLUS.2 No dependencies
FCS_TLSC_PLUS.5 No dependencies
FCS_TLSS_PLUS.1 No dependencies
FCS_TLSS_PLUS.2 No dependencies
FCS_SSH_EXT.1 No dependencies
FCS_SSHC_EXT.1 No dependencies
FCS_SSHS_EXT.1 No dependencies
FDP_ACF_EXT.1 No dependencies
FDP_ACC.1(PSO-MVS) FDP_ACF.1 FDP_ACF.1(PSO-MVS)
FDP_ACC.1(PSO-UNIX) FDP_ACF.1 FDP_ACF.1(PSO-MVS)
FDP_ACC.1(TSO) FDP_ACF.1 FDP_ACF.1(TSO)
FDP_ACC.1 FDP_ACC.1(PSO-MVS)
FDP_ACF.1(PSO-MVS)
FMT_MSA.3 FMT_MSA.3(PSO-MVS)
FDP_ACC.1 FDP_ACC.1(PSO-UNIX)
FDP_ACF.1(PSO-UNIX)
FMT_MSA.3 FMT_MSA.3(PSO-UNIX)
FDP_ACC.1 FDP_ACC.1(PSO-UNIX)
FDP_ACF.1(TSO)
FMT_MSA.3 FMT_MSA.3(PSO-UNIX)
FDP_RIP.2 No dependencies
FIA_AFL.1 FIA_UAU.1 FIA_UAU.1
FIA_ATD.1 No dependencies
FIA_SOS.1 No dependencies
FIA_UAU.1 FIA_UID.1 FIA_UID.1
FIA_UAU.5 No dependencies
FIA_UAU.7 FIA_UAU.1 FIA_UAU.1
FIA_UID.1 No dependencies
FIA_USB.1 FIA_ATD.1 FIA_ATD.1
FIA_X509_PLUS.1 No dependencies
FIA_X509_PLUS.2 No dependencies
Version: 2.27 Page 71 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Security functional
requirement
Dependencies Resolution
FMT_MOF_EXT.1 No dependencies
FMT_SMF_EXT.1 No dependencies
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(PSO-MVS)
FMT_SMR.1 FMT_SMR.1
FMT_MSA.1(PSO-MVS)
FMT_SMF.1 FMT_SMF_EXT.1
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(PSO-UNIX)
FMT_SMR.1 FMT_SMR.1
FMT_MSA.1(PSO-UNIX)
FMT_SMF.1 FMT_SMF_EXT.1
[FDP_ACC.1 or FDP_IFC.1] FDP_ACC.1(TSO)
FMT_SMR.1 FMT_SMR.1
FMT_MSA.1(TSO)
FMT_SMF.1 FMT_SMF_EXT.1
FMT_MSA.1 FMT_MSA.1(PSO-MVS)
FMT_MSA.3(PSO-MVS)
FMT_SMR.1 FMT_SMR.1
FMT_MSA.1 FMT_MSA.1(PSO-UNIX)
FMT_MSA.3(PSO-UNIX)
FMT_SMR.1 FMT_SMR.1
FMT_MSA.1 FMT_MSA.1(TSO)
FMT_MSA.3(TSO)
FMT_SMR.1 FMT_SMR.1
FMT_SMR.1 FMT_SMR.1
FMT_MTD.1
FMT_SMF.1 FMT_SMF_EXT.1
FMT_SMR.1 FIA_UID.1 FIA_UID.1
FPT_ACF_EXT.1 No dependencies
FPT_ASLR_EXT.1 No dependencies
FPT_SBOP_EXT.1 No dependencies
FPT_TST_EXT.1 No dependencies
FPT_TUD_EXT.1 No dependencies
FPT_TUD_EXT.2 No dependencies
FPT_STM.1 No dependencies
FTA_TAB.1 No dependencies
FTA_SSL.1 FIA_UAU.1 FIA_UAU.1
FTA_SSL.2 FIA_UAU.1 FIA_UAU.1
FTP_ITC_EXT.1 No dependencies
FTP_ITC.1 No dependencies
FTP_TRP.1 No dependencies
Version: 2.27 Page 72 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
6.3 Security Assurance Requirements
The security assurance requirements (SARs) for the TOE are defined in [CC] part 3 for the Evaluation
Assurance Level 4, augmented by ALC_FLR.3.
6.4 Security Assurance Requirements Rationale
The basis for the justification of EAL4 augmented with ALC_FLR.3 is the threat environment experienced
by the typical consumers of the TOE. This matches the package description for EAL4 (enhanced-basic).
The augmentation with ALC_FLR.3 is commensurate with the augmented flaw remediation capabilities
offered by the developer beyond those required by the evaluation assurance level.
Version: 2.27 Page 73 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7 TOE Summary Specification
7.1 Mapping SFR to TSS
The Protection Profile mandates various specific information to be supplied in the TSS to cover aspects
of the SFRs. The following table enumerates the SFRs (from the Protection Profile and the extended
packages) and adds references into the TSS to document these SFRs.
SFR Coverage in TSS
FAU_GEN.1 See section Audit (FAU).
FAU_GEN.2 See section Audit (FAU).
FAU_SAR.1 See section Audit (FAU).
FAU_SAR.2 See section Audit (FAU).
FAU_SAR.3 See section Audit (FAU).
FAU_SEL.1 See section Audit (FAU).
FAU_STG.1 See section Audit (FAU).
FAU_STG.3 See section Audit (FAU).
FAU_STG.4 See section Audit (FAU).
FCS_CKM.1 See section General Cryptography.
FCS_CKM.2 See section General Cryptography.
FCS_CKM.4 See sections Cryptographic Key Destruction and Object Re-Use.
FCS_COP.1/ENCRYPT See section General Cryptography.
FCS_COP.1/HASH See section General Cryptography.
FCS_COP.1/SIGN See section General Cryptography.
FCS_COP.1/KEYHMAC See section General Cryptography.
FCS_COP.1/IPSEC See section Communication Security.
FCS_RBG_EXT.1 See section Random Number Generation.
FCS_STO_EXT.1 See section Confidentiality Protection of Data Sets.
FCS_TLSC_PLUS.1 See section Communication Security and in particular section System SSL.
FCS_TLSC_PLUS.2 See section Communication Security and in particular section System SSL..
FCS_TLSC_PLUS.5 See section Communication Security and in particular section System SSL.
FCS_TLSS_PLUS.1 See section Communication Security and in particular section System SSL.
FCS_TLSS_PLUS.2 See section Communication Security and in particular section System SSL.
FCS_SSH_EXT.1 See section Communication Security and in particular section OpenSSH..
FCS_SSHC_EXT.1 See section Communication Security and in particular section OpenSSH.
FCS_SSHS_EXT.1 See section Communication Security and in particular section OpenSSH.
FDP_ACF_EXT.1 See section Discretionary Access Control.
Version: 2.27 Page 74 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
SFR Coverage in TSS
FDP_ACC.1(PSO-MVS) See section Discretionary Access Control.
FDP_ACC.1(PSO-UNIX) See section Discretionary Access Control.
FDP_ACF.1(PSO-MVS) See section Discretionary Access Control.
FDP_ACF.1(PSO-UNIX) See section Discretionary Access Control.
FDP_ACC.1(TSO) See section Discretionary Access Control.
FDP_ACF.1(TSO) See section Discretionary Access Control.
FDP_RIP.2 See section Object Re-Use.
FIA_AFL.1 See section Password Quality.
FIA_ATD.1 See section Identification and Authentication (FIA, FTA).
FIA_SOS.1 See section Identification and Authentication (FIA, FTA).
FIA_UAU.1 See section Identification and Authentication (FIA, FTA) and Authentication via Public/
Private Key (SSH).
FIA_UAU.5 See section Identification and Authentication (FIA, FTA), Authentication via Public/
Private Key (SSH) and OpenSSH.
FIA_UAU.7 See section Identification and Authentication (FIA, FTA) and Authentication via Public/
Private Key (SSH).
FIA_UID.1 See section Identification and Authentication (FIA, FTA) and Authentication via Public/
Private Key (SSH).
FIA_USB.1 See section Identification and Authentication (FIA, FTA) and Authentication via Public/
Private Key (SSH).
FIA_X509_PLUS.1 See section Authentication via Client Digital Certificates.
FIA_X509_PLUS.2 See section Authentication via Client Digital Certificates.
FMT_MOF_EXT.1 See section Security Management (FMT), RACF configuration and management, RACF
Certificate and Key Management, Automatic Logout of Sessions, Management of
Communications Server Functions, Password Quality, Protection of the audit trail and
Time Management.
FMT_SMF_EXT.1 See section Security Management (FMT), RACF configuration and management, RACF
Certificate and Key Management, Automatic Logout of Sessions, Management of
Communications Server Functions, Password Quality, Protection of the audit trail and
Time Management.
FMT_MSA.1(PSO-MVS) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_MSA.1(PSO-UNIX) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_MSA.1(TSO) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_MSA.3(PSO-MVS) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_MSA.3(PSO-UNIX) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
Version: 2.27 Page 75 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
SFR Coverage in TSS
FMT_MSA.3(TSO) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_MTD.1(AE) See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FMT_SMR.1 See section Resource management, Security Management (FMT), RACF configuration
and management and RACF Certificate and Key Management.
FPT_ACF_EXT.1 See section Discretionary Access Control.
FPT_ASLR_EXT.1 See section Address Space Layout Randomization.
FPT_SBOP_EXT.1 See section Stack Buffer Overflow Protection.
FPT_TST_EXT.1 See section Trusted Boot/IPL.
FPT_TUD_EXT.1 See section Trusted Update Process.
FPT_TUD_EXT.2 See section Trusted Update Process.
FPT_STM.1 See section Time Management.
FTA_TAB.1 See section Access Banners.
FTA_SSL.1 See section Automatic Logout of Sessions.
FTA_SSL.2 See section Automatic Logout of Sessions.
FTP_ITC_EXT.1 See section Communication Security.
FTP_ITC.1 See section Communication Security.
FTP_TRP.1 See section Communication Security.
Table 10: Mapping SFRs to TSS Sections
7.2 TOE Security Functionality
7.2.1 z/OS Basic Principles
7.2.1.1 Hardware Platform
The z/OS operating system is designed to operate on a hardware platform that implements the
zArchitecture most of which is defined in the IBM document 'Principles of Operation'. The zArchitecture
provides two different processor states - user (unprivileged) and supervisor (privileged) - as well as
memory protection features that allow to restrict access of programs to such memory to no access,
read-only access, or read and write access. Changing those access attributes of memory can only be
done by privileged instructions, which can only be executed when the processor is in supervisor mode.
The current status of a processor including the address of the program instruction currently executed is
stored in a processor internal register called the 'Program Status Word' (PSW). This PSW also contains
a so called 'Access Key Mask' (AKM) which is used by the processor to determine the access to memory
the currently executed instruction has. Access to memory is controlled by matching the current AKM
in the PSW with the protection bits each page of memory has.
Among the privileged processor instructions of the zArchitecture are also a few instructions related to I/
O operations. Unlike most other hardware platforms the IBM zArchitecture has a well-defined interface
to an I/O subsystem where individual device are addressed via a channel and device address and where
the operations on a device are defined by 'Channel Command Words' (CCW). Several of them can be
Version: 2.27 Page 76 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
combined to a 'Channel Program' that is submitted to the I/O subsystem using the privileged instruction
' START SUBCHANNEL' (SSCH). For an overview on how I/O works on a zSeries platform and which other
I/O related privileged instructions exist, the reader is referred to chapters 13 to 17 of the Principle of
Operations document.
7.2.1.2 System Initialization (IPL)
The system initialization process prepares the system control program and its environment to do work
for the installation. The process essentially consists of:
● System and storage initialization, including the creation of system component address
spaces.
● Master scheduler initialization and subsystem initialization.
When the system is initialized and the job entry subsystem is active, the installation can submit jobs
for processing with the START or MOUNT command.
The initialization process begins when the system operator selects the LOAD function at the system
console. MVS locates all of the usable central storage that is online and available to the system, and
creates a virtual environment for the building of various system areas. IPL includes the following major
initialization functions:
● Loads the DAT-off nucleus into central storage.
● Loads the DAT-on nucleus into virtual storage so that it spans above and below 16
megabytes (except the prefixed storage area (PSA), which IPL loads at virtual zero).
● Builds the nucleus map, NUCMAP, of the DAT-on nucleus. NUCMAP resides in virtual storage
above the nucleus.
● Allocates the system's minimum virtual storage for the system queue area (SQA) and the
extended SQA.
● Allocates virtual storage for the extended local system queue area (extended LSQA) for the
master scheduler address space.
The system continues the initialization process, interpreting and acting on the system parameters
that were specified. NIP (Nucleus Initialization Program) carries out the following major initialization
functions:
● Expands the SQA and the extended SQA by the amounts specified on the SQA system
parameter.
● Creates the pageable link pack area (PLPA) and the extended PLPA for a cold start IPL; resets
tables to match an existing PLPA and extended PLPA for a quick start or a warm start IPL.
● Loads modules into the fixed link pack area (FLPA) or the extended FLPA. Note that NIP
carries out this function only if the FIX system parameter is specified.
● Loads modules into the modified link pack area (MLPA) and the extended MLPA. Note that
NIP carries out this function only if the MLPA system parameter is specified.
● Allocates virtual storage for the common service area (CSA) and the extended CSA. The
amount of storage allocated depends on the values specified on the CSA system parameter
at IPL.
● Page protects the: NUCMAP, PLPA and extended PLPA, MLPA and extended MLPA, FLPA and
extended FLPA, and portions of the nucleus.
Note: An installation can override page protection of the MLPA and FLPA by specifying NOPROT on the
MLPA and FIX system parameters.
Version: 2.27 Page 77 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.1.2.1 Initial System Address Space Creation
In addition to initializing system areas, z/OS establishes system component address spaces. z/OS
establishes an address space for the master scheduler (the master scheduler address space (MSTR))
and other system address spaces for various subsystems and system components. Details about the
initial address space creation can be found in [MVSTUNE.G], chapter 1.
7.2.1.2.2 Master Scheduler Initialization (MSTR)
Master scheduler initialization routines initialize system services such as the system log and
communications task, and start the master scheduler itself. They also cause creation of the system
address space for the job entry subsystem (JES2), and then start the job entry subsystem.
7.2.1.2.3 z/OS Subsystem Initialization
z/OS subsystem initialization is the process of readying a subsystem for use in the system. IEFSSNxx
members of SYS1.PARMLIB contain the definitions for the primary subsystems, such as JES2, and
possibly the secondary subsystems, such as SMS and DB2. For detailed information about the data
contained in IEFSSNxx members for secondary systems, please refer to the installation manual for the
specific system.
During system initialization, the defined subsystems are initialized. The system administrator should
define the primary subsystem (JES2) first, because other subsystems require the services of the primary
subsystem in their initialization routines – problems can occur if subsystems that use the primary
subsystem's services in their initialization routines are initialized before the primary subsystem.
After the primary subsystem JES2 is initialized, then the subsystems are initialized in the order in which
the IEFSSNxx parmlib members are specified by the SSN parameter. For example, for SSN=(aa,bb)
parmlib member IEFSSNaa would be processed before IEFSSNbb.
Note: The storage management subsystem (SMS) is the only subsystem that can be defined before
the primary subsystem.
Using IEFSSNxx to initialize the subsystems, the system administrator can specify the name of a
subsystem initialization routine to be given control during master scheduler initialization, and the
system administrator can specify the input parameter to be passed to the subsystem initialization
routine.
7.2.1.2.4 Trusted Boot/IPL
The establishment of a trusted boot within the TOE is a two step process, where only the second is
actually performed by the TOE:
1. Controlled Signing
On a controlled, separate non-TOE system a "secure build" process initiated by the
administrator creates signed IPL Text and load modules using administrator defined keys
and stores them on disk. Trusted is built upon the validation of the "incoming" code package
deliverables using IBM's vendor public key. The administrator builds/creates all needed load
module executables, and signs them with their own private key (including the IPL Text). The
signing is happening in a controlled environment.
The non-TOE system uses SHA2-512 used for hashing in creating the signature, hashing the
data to be signed and an Elliptic Curve ECDSA-P521 key used for signing. The RACF Signing
Service (using the existing R_PgmSignVer SAF callable service (IRRSPS00)) is used to sign
load modules, and by ICKDSF to sign the IPL Text on an IPL volume
The following modules are subject to signing:
Version: 2.27 Page 78 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● IPL Text (IEAIPL00) (validated by firmware (Z Bootloader))
● All load modules through LPA creation:
❍ IRIMs and RIMs (up through LPA creation)
❍ SYS1.NUCLEUS load modules including z/OS Nucleus (IEANUCxx)
❍ LPA load modules (LPALST concatenation) and MLPA/FLPA load modules
2. Trusted IPL
At IPL time, platform firmware (Z Bootloader) validates the IPL Text, which contains the
validation function code which z/OS will use in subsequent load module validation steps
● Client's (or other) public keys for validation purposes are provided by the z platform
firmware
● The IPL Text is a signed object, signed by the client and validated by the z platform
firmware
{SP-IPL-V2R5.1}
As z/OS loads the individual authorized load modules during the IPL, z/OS uses the validation
function code to validate their signatures using the administrator's defined public keys. {SP-
IPL-V2R5.2}
Any validation failures may result in non-restartable wait state termination of the IPL, or not,
depending on IPL validation mode. {SP-IPL-V2R5.3}
The z firmware (SE/HMC and LPAR) provides the trusted validation Certificate Store for use in
validation processing done by both the Z Bootloader and z/OS. {SP-IPL-V2R5.4}
7.2.1.3 Address Spaces in z/OS
Originally the operating system z/OS evolved from was designed for processing batch jobs where each
job was executed in its own address space separated from the address spaces of other jobs. Still today
the main task of z/OS is to serve those batch jobs in large production environments.
Address spaces in z/OS have some parts in common, but in the evaluated configuration all those parts
can only be written by the operating system itself. Some parts of those common areas of all address
spaces contain library programs that can be used by all address spaces, some parts contain data written
by the operating system for common use by all address spaces. Some of those common data areas may
contain critical data and are therefore also protected from being read by unauthorized user programs.
Address spaces are assigned a user identity which is used for security functions like access control
and audit. All subjects within an address space are associated with that user-ID. A user-ID is assigned
during address space initialization either as part of the user identification and authentication process.
A system administrator of an installation may have defined specific address spaces that are started
automatically or on request of a system administrator where the specification of the address space
(in terms of the 'Job Control Language') does not require the specific user-ID to be authenticated. This
allows the operating system itself to consists also of dedicated address spaces providing operating
system services.
7.2.1.4 System Call Interface
A subject within an address space can request operating system services using either the (legacy)
SVC instruction or the (more modern) Program Call (PC) or Program Transfer (PT) instructions. The SVC
instruction traps into the operating system kernel which determines the type of service requested,
while the PC or PT instruction may call operating system services either provided within the caller's
address space or provided by another operating system owned address space. In this case the hardware
Version: 2.27 Page 79 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
performs a full address space context switch. This allows z/OS to have operating system services being
implemented in a way where a system call never executes with the highest hardware privileges but
just with the privileges assigned to the address space (i. e. the 'user' assigned to the address space).
7.2.1.5 Subjects
Subjects in z/OS are programs executing in the context of an address space. The parameters of an
address space are stored within an 'Address Space Control Block' (ASCB). Within an address space
several programs can execute in parallel as 'tasks'. Each task is assigned to exactly one address space
and the parameters of a task are stored in a 'Task Control Block' (TCB). The address of the list of
TCBs belonging to an address space is stored in the ASCB. There is also a kind of 'lightweight' subjects
controlled by a 'Request Block' (RB), which are also linked to an address space.
7.2.1.6 Security Services
The security services for user identification and authentication, access control, and security related
auditing are implemented in a single component of z/OS called the 'Resource Access and Control
Facility' (RACF). RACF consists of a set of system services that can be used by properly authorized
callers to perform I&A, access control, and security management functions. The authorization required
for each service are documented with the service itself.
7.2.1.7 User interaction with z/OS
A user interacts with z/OS either via a JOB, defined using a 'Job Control Language' (JCL) or interactively.
For direct interaction with z/OS a user either has to use the 'Time Sharing Option' (TSO) or use a shell
of the UNIX System Services (USS) subsystem. In all of those cases the user has provide a valid user-
ID and associated authentication credentials.
7.2.1.8 Persistent Storage
To store data permanently z/OS provides storage containers called 'data sets' or – when operating
under the USS subsystems – traditional Unix files and directories. Data sets on disks are identified by
their data set name and the disk they reside on. To make locating a data set easier, z/OS offers a
mechanism called a 'catalog' that can be used to locate data sets without specifying the directly the
disk they reside on. Data sets can also be located on tapes.
7.2.1.9 Authorized Programs
In addition to supervisor and PC routines, z/OS has a number of “authorized programs” that need
to be trusted because they are not restricted by the security policy defined in this Security Target.
An authorized program may call a number of program calls or supervisor calls or use supervisor call
parameters that are reserved for authorized programs. In particular, it is authorized to call the MODESET
SVC used to switch into supervisor state. With this function, authorized programs can execute any
privileged instruction.
A program is authorized if at least one of the following conditions is true:
● The program is executing in supervisor state {SP.3::SP.3.1}.
● The program is executing with a PSW key of 0 to 7 or a PSW key mask value that supports at
least one key in the range of 0 to 7 in control register 3 {SP.3::SP.3.2} .
● The authorization bit is set in the Job Step Control Block (JSCB) under which the program is
executing {SP.3::SP.3.3}.
Version: 2.27 Page 80 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Whenever a supervisor routine reserved for authorized programs is called or when a parameter
reserved for authorized programs is used, the routine invoked to service the request checks if one of
the above listed conditions is satisfied. Only if this is true, the request is honored {SP.3::SP.3.4}.
Note that the hardware performs some checks when a supervisor routine is called with a Program
Call (PC) instruction. In this case the routine implementing the service only needs to perform its own
checks if additional restrictions to those implied by the hardware checks apply. Note also that some
supervisor routine may be more restrictive, i. e. only a subset of the three conditions mentioned above
is checked and the request is rejected if not one of the conditions in the subset apply. For example
the hardware can not check if a program running in problem state with a PSW key of 8 is authorized
by the authorization bit in the JSCB.
An authorized program can be started in one of the following ways:
● By starting a program from a dedicated program library (defined in the system configuration
data set SYS1.PARMLIB) that has the authorization bit set in the directory entry of the
member of the partitioned data set (library) containing the program. This program has to be
the one started with the EXEC JCL statement of the job step, as a TSO command, as a UNIX
process using exec(), or started as a dedicated task by an authorized program using the
ATTACH supervisor call with parameters reserved for authorized programs {SP.3::SP.3.5}.
Note: TSO commands might be entered directly by the user at a terminal, executed in a batch job
that runs TSO TMP, or entered programmatically using the TSO IKJEFTSR service. They may also be
executed by any service that uses either the TMP or IKJEFTSR service such as the REXX 'address
tso' function or the Unix shell 'tsocmd' function.
● By starting a started task from an authorized library using the operator START command
{SP.3::SP.3.6}.
● By starting an authorized program from a zFS file system {SP.3::SP.3.V1R7.1}. A program
in a zFS file system is authorized when the authorization bit has been set using the extattr
–a command for the file containing the program {SP.3::SP.3.V1R7.2}. A user needs
to have been authorized to the BPX.FILEATTR.APF profile in the FACILITY class to set
the authorization bit {SP.3::SP.3.V1R7.3}. If a program running in an APF-authorized
address space attempts to load a program from zFS that does not have the APF-extended
attribute set, the load is rejected {SP.3::SP.3.V1R7.4}. Sanction lists can be defined that
restrict access of authorized programs in the z/OS Unix System Services environment to files
and directories defined in those sanction lists {SP.3::SP.3.V1R7.5}. Note that the APF-
authorized extended attribute of a file is not honored if the file system containing the file has
been mounted as NOSECURITY {SP.3::SP.3.V2R1.1}.
For the invocation of MVS programs linkedited AC=1 found in an APF-authorized library invoked via the
z/OS UNIX spawn, exec and attach_exec service and for MVS load library programs that are to run as
a z/OS UNIX set-user-id or set-group-id program the following rules apply:
● If the z/OS UNIX path name supplied to spawn, exec or attach_exec represents an external
link that resolves to a MVS program found in an APF-authorized library and linkedited with
the AC=1 attribute, the external link must have a owning UID of 0 and not be found in a file
system mounted as NOSECURITY to allow this type of invocation {SP.3::SP.3.V2R1.1a}.
● If the z/OS UNIX path name supplied to spawn, exec, or attach_exec represents a regular
file with the sticky bit attribute that resolves to a MVS program found in an APF-authorized
library and linkedited with the AC=1 attribute, the sticky bit file must have an owning UID of
0 or have the APF extended attribute turned on to allow this type of invocation. Additionally,
the sticky bit file must not be found in a file system mounted as NOSECURITY to allow this
type of invocation {SP.3::SP.3.V2R1.2}.
● If the z/OS UNIX path name supplied to spawn, exec or attach_exec represents a symbolic
link to a regular file with the sticky bit attribute and the sticky bit file has the set-user-id
attribute, the symbolic link must have an owning uid of 0 or an owning uid equal to that of
Version: 2.27 Page 81 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
the sticky bit file. If the sticky bit file has the set-group-id attribute, the symbolic link must
have an owning uid of 0 or an owning gid equal to that of the sticky bit file. Additionally, the
symbolic link must not be found in a file system mounted as NOSECURITY to allow this type of
invocation {SP.3::SP.3.V2R1.3}.
Libraries that can contain authorized programs need to be protected from unauthorized modifications
including the possibility to add new programs to the library. zFS files containing authorized programs
also need to be protected from unauthorized modifications. The discretionary access control features
of z/OS have to be used to protect those libraries.
The IKJTSOxx member of SYS1.PARMLIB can be used to define the authorized programs and commands
that can be executed in the TSO environment {SP.3::SP.3.V1R7.6}.
Some trusted subsystems of z/OS are started as part of the standard startup procedure or may be later
started by explicit request of a properly authorized user.
7.2.2 Security Functionality
7.2.2.1 Identification and Authentication (FIA, FTA)
A user can interact with the TOE in one of the following ways:
● As a TSO user
● As an operator at a console
● As a user of the UNIX System Services (USS), including access via the UNIX shell or remote
access using OpenSSH.
In all cases users are identified and authenticated by the TOE {IA.1::IA.1.1} before being authorized
to perform any other security relevant action. In the case of jobs submitted by an already-authenticated
user, no additional authentication is required for jobs running with the ID of the user who submitted
them. The internal reader accepts (and relies) in this case on the authentication performed when the
user has logged on to the system {IA.1::IA.1.2}.
An exception to this rule are started tasks, which operate under a protected user ID and are started
either at system startup or through an operator command. Those tasks are not executing on behalf of
a human user and their protected user IDs are exempt from authentication {IA.1::IA.1.3}. They must
only be started from trusted data sets.
When authenticating a user, the TOE allows applications to accept:
● A user ID defined to RACF {IA.1::IA.1.4-R8-RACF-1} and the RACF password
{IA.1::IA.1.4-R8-RACF-2} or password phrase {IA.1::IA.1.4-R10-RACF-4} or a
PassTicket {IA.1::IA.1.4-R8-RACF-3}.
● A valid x.509v3 digital certificate that the application has validated using TLSv1.2-based
or TLSv1.3-based client authentication and presented to RACF via initACEE (or indirectly
via __certificate()) or mapped to a RACF user ID R_usermap(), for those applications
supporting TLSv1.2-based or TLSv1.3-based client authentication (see Authentication
via Client Digital Certificates). {IA.1::IA.1.4-V2R4-MULTI-1} {IA.1::IA.1.4-V2R4-
RACFEAL5-1}
● For SSH login functions (ssh, scp, sftp) RACF will also verify the specified password/phrase
{IA.1::IA-1.4-R10-SSH-1}. For clients authenticating using public/private keys, SSH will
verify the private key using information from the RACF keyring when configured to allow this
authentication method {IA.1::IA-1.4-R12-SSH-2} .
Some additional considerations:
Version: 2.27 Page 82 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● For access to UNIX functions, the user must have a valid UID and his default group must
have a valid GID {IA.1::IA.1.6}.
● If the user is in additional groups they may have GIDs, too, and if so UNIX access checking
will make use of those additional GIDs {IA.1::IA.1.6-R8-USS-3}.
● If the user ID is in REVOKE status, RACF prevents user from entering the system at all or
entering the system with certain groups {IA.1::IA.1.7}.
● For a user defined as a system administrator (that is, one who has the system SPECIAL
attribute) a message is displayed on the console asking the operator if the user shall be
revoked if he exceeds the number of failed login attempts due to incorrect passwords
{IA.1::IA.1.7-R8-RACF-1} or if he exceeds the system inactivity interval {IA.1::IA.1.7.R8-
RACF-2}.
7.2.2.1.1 Authentication Functions
7.2.2.1.1.1 RACF Passwords and Password Phrases
In RACF, the user selects his own password/phrase and only the user knows the value chosen. RACF
stores the encrypted representation of passwords and passphrases in the RACF database. If the user
has forgotten his password/phrase and it needs to be reset, the security administrator will reset
the password/phrase {IA.2::IA.2.1-R10}. When the system administrator follows the rules for the
evaluated configuration, this new password/phrase should be in an expired state, thus forcing the user
to enter a new password/phrase on the next logon {IA.2::IA.2.2-R10}. When creating a new user ID
that is not a protected user ID, the initial password/phrase may be marked as non-expired, allowing it
to be used without being changed first. {IA.2::IA.2.3-V2R5}.
7.2.2.1.1.1.1 Password Quality
A system administrator can set a variety of system-global rules for forming valid passwords using the
SETROPTS command (for system-wide settings) or (to a lesser extent) using the password command
to affect only one user. He can change such parameters as the number of days a password is valid for,
how long to maintain password history to prevent the user from reusing the same password again, the
minimum number of days between password changes, and rules for password content.
When a user changes a password, RACF treats the new, user-supplied password as an encryption key
to transform the RACF user ID into an encoded form and is depending on the “ALGORITHM(KDFAES)”
setting, is using the DES or AES algorithm to store it in the database. The password is not stored in
clear text {IA.2::IA.2.4-V2R5-RACF-1}.
The following system-wide options can be set to enforce a minimum strength of passwords using the
PASSWORD option in the SETROPTS command:
● Minimum and maximum length of passwords (LENGTH(m1:m2) as part of a RULE suboption)
{IA.2::IA.2.5}
● Maximum password lifetime (INTERVAL suboption) {IA.2::IA.2.6} and minimum password
change time (MINCHANGE option) {IA.2::IA.2.V1R7-1}
● Number of passwords from the user's password history that are not allowed for a new
password (HISTORY suboption) {IA.2::IA.2.7}
● Maximum number of consecutive failed authentication attempts until the REVOKE attribute
is set in the user's profile (REVOKE suboption) {IA.2::IA.2.8}
● Differentiate between upper- and lowercase characters with the PASSWORD(MIXEDCASE)
option {IA.2::IA.2.V1R7-2}
● allowance for the use of the following special characters in passwords: .<+|&!*-%_>?:=
Version: 2.27 Page 83 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Type of character for each character position of a password. Possible types are
{IA.2::IA.2.9}:
❍ ALPHA
❍ ALPHANUM (which includes also the special characters $, # and @)
❍ VOWEL
❍ NOVOWEL
❍ CONSONANT
❍ NUMERIC
❍ MIXEDCONSONANT
❍ MIXEDVOWEL
❍ MIXEDNUM
❍ NATIONAL
If the value ALPHANUM is defined for more than one position in the password, at least one alphabetical
value and one numeric value are required by RACF.
The SETROPTS command with the SPECIALCHARS option can be used to increase the possible password
space by an additional 14 characters (! % & * _ + | : ? > < . - =) {IA.2::IA.2-V2R2.1}.
A new MIXEDALL content-keyword is used to force a mixture of the four categories of characters within
a password. Note: MIXEDALL considers the existing national characters (@, #, $) as special characters,
and not as upper case letters {IA.2::IA.2-V2R2.2}.
SMF Type 80 record for the SETROPTS event code is being augmented with new indicators for:
● the NO/SPECIALCHARS keyword specified
● the NO/SPECIALCHARS keyword failed
● the SPECIALCHARS setting in effect after completion of the SETROPTS command.
{IA.2::IA.2-V2R2.3}
When the commands are called in a way that allows the TOE to suppress printing, passwords are not
displayed:
● when entered at a TSO terminal as part of the login process {IA.2::IA.2.10}, or
● when entered at a TSO terminal as part of the ADDUSER, ALTUSER, or PASSWORD commands
when the command contains the PASSWORD keyword but no value {IA.2::IA.2-R10-
RACF-21}, or
● when entered into one of the RACF-supplied ISPF panels that allows specification of a
password {IA.2::IA.2-R10-RACF-22}, or
● when entered at a system operator console as part of the operator logon {IA.2::IA.2-R8-
BCP-1}, or
● when the content of a jobcard is displayed as part of a job's output {IA.2::IA.2.13}.
Note that the TSF can not ensure that passwords entered into programs executing with the user's
privilege are fully protected from being spoofed. The user has to take care about his password in those
cases as explained in the guidance.
7.2.2.1.1.1.2 Password Phrase Quality
Many of the system rules for passwords set by SETROPTS apply to password phrases, too. However,
RACF does not provide support for content syntax rules when using password phrases.
Version: 2.27 Page 84 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
When a password phrase is established for a user, RACF treats the new phrase as a sequence
of encryption keys to transform the RACF user ID into an encoded form using the DES algorithm
with chaining, that it then stores on the database. The password phrase is not stored in clear text
{IA.2::IA.2-R10-RACF-1}.
The following system-wide options that can be set to enforce a minimum strength of passwords using
the PASSWORD option in the SETROPTS command also apply to password phrases:
● Maximum password phrase lifetime (INTERVAL suboption) {IA.2::IA.2-R10-RACF-2} and
minimum password phrase change time (MINCHANGE option) {IA.2::IA.2-R10-RACF-3}
● Number of password phrases from the user's password phrase history that are not allowed
for a new password phrase (HISTORY suboption) {IA.2::IA.2-R10-RACF-4}
● Maximum number of consecutive failed authentication attempts using a password or
password phrase until the REVOKE attribute is set in the user's profile (REVOKE suboption)
{IA.2::IA.2-R10-RACF-5}
● A password phrase must be changed after the first use, if the EXPIRED parameter is passed
to the ADDUSER or ALTUSER command. {IA.2::IA.2-V2R4-RACF-1}
Rather than having an administrator specify syntax rules to specify valid password phrase content,
RACF enforces the following set of predefined rules:
● maximum length: 100 characters in the absence of exit ICHPWX11 {IA.2::IA.2-R10-
RACF-6}
Note: The evaluated configuration of the TOE generally does not allow customers to
implement exits to change the system processing. However, RACF supplies a sample
ICHPWX11 exit and a sample REXX exec IRRPHREX that the sample ICHPWX11 will invoke. The
administrator may install the sample ICHPWX11 unmodified, and may specify tailoring options
in IRRPHREX to apply some additional syntax/content rules.
● minimum length:
❍ 14 characters in the absence of exit ICHPWX11 and when KDFAES is not the
passphrase encryption algorithm {IA.2::IA.2-V2R2-4}
❍ 9 characters when KDFAES is the passphrase encryption algorithm {IA.2::IA.2-
V2R2-5}
❍ 9 characters if exit ICHPWX11 is present and allows the phrase {IA.2::IA.2-R10-
RACF-8}
● The phrase may not contain the user ID, in either sequential uppercase or sequential
lowercase characters {IA.2::IA.2-R10-RACF-9}
● The phrase must contain at least two alphabetic characters (A-Z, a-z) {IA.2::IA.2-R10-
RACF-10}
● The phrase must contain at least two non-alphabetic characters (numeric, punctuation,
special (including blanks)) {IA.2::IA.2-R10-RACF-11}
● The phrase may not contain more than two consecutive identical characters {IA.2::IA.2-
R10-RACF-12}
If the administrator chooses to install the supplied sample exit ICHPWX11, the sample REXX exec
IRRPHREX may then apply the following additional checks, if selected by the administrator, and may
then accept a shorter phrase or reject a phrase that RACF would have accepted:
● The administrator can set the minimum allowable phrase length to a value between 9 and
100 inclusive by setting variable Phr_minlen {IA.2::IA.2-R10-RACF-26}
● The administrator can set the maximum allowable phrase length to a value between 9 and
100 inclusive by setting variable Phr_maxlen {IA.2::IA.2-R10-RACF-13}
Version: 2.27 Page 85 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● The administrator can set a more restrictive set of characters for password phrases by
setting the variables numbers, letters, special, and Phr_allowed_chars {IA.2::IA.2-R10-
RACF-14}
● The administrator can prevent leading or trailing blanks in password phrases by setting
the variables Phr_leading_blanks or Phr_trailing_blanks to “no” {IA.2::IA.2-R10-
RACF-15}
● The administrator can prevent use of password phrases that contain a case-insensitive
character string from the user's name by setting the variable Phr_name_allowed to “no”
and setting the variable Phr_name_minlen to the longest substring allowed {IA.2::IA.2-
R10-RACF-16} Example: if the user's name is John Smith the administrator could prevent
the user from specifying a phrase containing John or john or jOhn or Smith by appropriate
settings of the variables.
● The administrator can enable a triviality check by setting the variable Phr_triviality
to “yes”. This will prevent use of a new password phrase that differs from the old one only
insertion/deletion of spaces or changing character case. It also will reject a new phrase when
the shorter of the old and new phrases is simply a substring of the other. {IA.2::IA.2-R10-
RACF-17}
● The administrator can prevent use of new phrases that do not differ in a significant number
of characters from the old phrase by setting the variable Phr_min_unique to the number
of positions that must differ. In addition, if the variable Phr_min_unique_norm has the value
“yes” the exec will first normalize the old and new phrases to be checked by converting
them to uppercase and removing spaces. {IA.2::IA.2-R10-RACF-18}
● The administrator can prevent the user of a new phrase which simply reorders the
words of the old phrase by setting the variables Phr_unique_words (number of words
that must be unique), Phr_word_minlen (minimum length of the unique words), and
Phr_word_unique_upper (if “yes” then the exec will convert the old and new phrases to
uppercase for this check {IA.2::IA.2-R10-RACF-19}
● The administrator can provide a list of disallowed words by setting the variables Phr_dict.0
to the number of words in a supplied list, and supplying the list in variables Phr_dict.1,
Phr_dict.2, etc. {IA.2::IA.2-R10-RACF-20}
When the commands are called in a way that allows the TOE to suppress printing, the phrase is not
displayed:
● when entered at a TSO terminal as part of the login process {IA.2::IA.2-R10-TSO-23}, or
● when entered into one of the RACF-supplied ISPF panels that allows specification of a
password phrase {IA.2::IA.2-R10-RACF-25}.
Note that the TSF can not ensure that password phrases entered into programs executing with the
user's privilege are fully protected from being spoofed. The user has to take care about his password
phrase in those cases as explained in the guidance.
z/OS UNIX uses, by default, an application name (APPLID) of OMVSAPPL {IA.2::IA.2.14-R10-USS-1}
when authenticating users via:
● The __login(), or pthread_security_np() services.
● The __passwd() service if issued from a thread created by pthread_create() which
subsequently issued pthread_security_np(), and if the __passwd() call does not specify a
new password.
The application may override this default in one of these ways:
● For pthread_security_np() and __passwd(), the application can
Version: 2.27 Page 86 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ update the BPXYTHLI control block to indicate that z/OS UNIX should instead use the
job name as the APPLID value {IA.2::IA.2.14-R10-USS-2}, or
❍ update the BPXYTHLI control block to indicate a specific APPLID to use
{IA.2::IA.2.14-R10-USS-3}.
● By changing to use one of the corresponding new services
pthread_security_applid_np(), __login_applid(), and __passwd_applid() the
application can specify an APPLID value directly as a parameter on the call {IA.2::IA.2.14-
R10-USS-4}.
7.2.2.1.1.1.3 Authentication via Client Digital Certificates
In the evaluated configuration, TLS-aware applications, or the Application-Transparent TLS (AT-TLS)
functions of the Communications Server, can accept client certificates and map them to RACF user
IDs as part of the client authentication process. Such applications must be configured to use RACF to
store the keyrings that contain the application private key and the allowed Certificate Authority (CA)
certificates that may be used to provide the client certificates that the application will support. The
security administrator will use RACDCERT to establish those keyrings, which may reside in RACF profiles
in the DIGTRING class or in PKCS#11 tokens maintained in ICSF, and thus to approve of any CAs that
will be used. Any CA used in the evaluated configuration must support obtaining revocation information
through OCSP responses , and the security administrator must configure the application to use OCSP
responses {IA.2::IA.2.V2R5-SSL-2}. This configuration may be application-specific, or may be done
by establishing LE environment variables that System SSL will use in the absence of specific application-
provided OCSP configuration information.
The first step in the client authentication process is for the server or AT-TLS to acquire the client
certificate via the standard TLS data flows. As part of that processing, System SSL will validate the
client certificate using the process specified by [RFC5280]☝. {IA.2::IA.2.15-V2R4-SSL-20}.
For AT-TLS one can also specify a policy to perform certificate path validation according to [RFC5280]☝
{IA.2::IA.2-V2R2.7}.
AT-TLS also allows to specify a security policy that include OCSP for certificate revocation checking
{IA.2::IA.2-V2R5.1}.
System SSL will perform the following checks against the client certificate and certification chain:
1. [RFC5280]☝, section 6 conforming certificate validation and certificate path validation.
{IA:2::IA.2-V2R5-SSL-CPV-1}
2. The certificate path must terminate with a trusted CA certificate. {IA:2::IA.2-V2R4-SSL-
CPV-2}
3. Ensure the presence of the basicConstraints extension and that the CA flag is set to TRUE
for all CA certificates certificates, and that any path constraints are met. {IA:2::IA.2-V2R5-
SSL-CPV-3}
4. The TSF shall validate that any CA certificate includes "Certificate Signing" as a purpose the
key usage field. {IA:2::IA.2-V2R5-SSL-CPV-3a}
5. The revocation status of the certificate is checked using the Online Certificate Status
Protocol (OCSP) as specified in [RFC6960]☝ with the exception of the TOE's TCP/IP stack
being configured to not validate certificates using an OCSP service. {IA:2::IA.2-V2R5-SSL-
CPV-4}
6. The following extendedKeyUsage field rules are applied during validation:
● Server certificates presented for TLS shall have the Server Authentication purpose
(id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
Version: 2.27 Page 87 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Client certificates presented for TLS shall have the Client Authentication purpose (id-
kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
● OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
{IA:2::IA.2-V2R5-SSL-CPV-5}
7.2.2.1.1.1.4 Authentication via Public/Private Key (SSH)
OpenSSH supports authentication via public/private keys, however for the evaluated configuration
OpenSSH on z/OS must be configured to obtain those public/private key pairs from digital certificates
associated with RACF key rings. The existing RACDCERT command can be used to generate the
keys and a certificate, or the certificates may be generated elsewhere and imported into RACF using
RACDCERT. Private keys stored directly in the UNIX file system must not be used.
When a remote user authenticates to the OpenSSH server, the server will use the public key, obtained
via a digital certificate which is associated with the user's configured key ring, to perform the
authentication. {IA.2::IA.2-R12-SSH-KEY-1}
When a z/OS user acts as an SSH client, connecting to an SSH server, the client will obtain the necessary
private key via a digital certificate which is associated with the user's configured key ring to perform
the authentication. {IA.2::IA.2-R12-SSH-KEY-2}
The private key is not needed at the server when a client authenticates. The public keys must be
distributed to remote hosts. When stored in a key ring, the certificate must be exported (via RACDCERT)
and manually copied (e.g. by transferring them using a secured channel) to the remote host, where it
will be imported into that system's key ring.
When configured to use key rings, the OpenSSH server and client code will use existing System SSL
interfaces to pull the keys from the RACF key ring, and the server and client will need authority to those
key rings to use the RDATALIB service. {IA.2::IA.2-R12-SSH-KEY-3}.
When a user registers his public key with the user he wants to access on the server side, a key-
based authentication can be performed instead of a password-based authentication.{CS.5::CS.1-
V2R4-SSH-2}. The key-based authentication is performed as defined by RFC 4252. The public key
for the key-based authentication must reside in the home directory of the target user in the file .ssh/
authorized_keys. As this file may contain multiple key, each key is tried whether it is appropriate as
a public key for the authentication attempt (i.e. whether the public key can decrypt the data sent by
the client encrypted with the client's private key). The first key that is found to match the private key
indicates a successful authentication. {CS.5::CS.1-V2R4-SSH-3}
7.2.2.1.1.1.5 Started procedures
With the concept of a started procedure, the TOE provides a mechanism where a defined task can be
started by an operator, but then operates under a defined user ID that is specifically assigned to the
started procedure itself {IA.3::IA.3.1} .
A started procedure consists of a set of job control language statements that are frequently used
together to achieve a certain result. Started procedures usually reside in the system procedure library,
SYS1.PROCLIB, which is a partitioned data set. A started procedure is usually started by an operator,
but can be associated with a functional subsystem. For example, SMS is treated as a started procedure
even though it does not need to be specifically started with a START command.
Only RACF-defined users and groups can be specifically authorized to access RACF-protected resources
{IA.3::IA.3.2}. Other users can access those resources with the authority allowed in the UACC entry
of the RACF profile controlling access to the resource. However, started procedures have system-
generated JOB statements that do not contain the USER, GROUP, or PASSWORD parameter.
Version: 2.27 Page 88 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
To enable started procedures to access RACF-protected resources with other authorities than those
defined in the UACC entry of the profile protecting the resource, started procedures must have RACF
user IDs and group names {IA.3::IA.3.4}. By assigning them RACF identities, an installation can give
started procedures specific authorization to access RACF-protected resources. For example, one can
allow JES to access spool data sets.
To associate the names of started procedures with specific RACF group names and user IDs, an
administrator can do one of the following:
● Set up the STARTED class (the recommended method)
● Create a started procedures table (ICHRIN03)
Assigning RACF user IDs to started procedures
As with any other user ID and group name, the user ID and group name that is assigned to a started
procedure must be defined to RACF using the ADDUSER and ADDGROUP commands, and the user must
be connected to the group. The administrator also needs to use the PERMIT command to authorize the
users or groups to get access to the required resources.
7.2.2.1.1.1.6 Protected user IDs
The user IDs that an administrator assigns to started procedures should have the PROTECTED attribute
unless the started procedure is required to have a user ID with a password defined. Protected user IDs
are user IDs that have all the NOPASSWORD, NOPHRASE and NOOIDCARD attributes {IA.3::IA.3.5-V2R5}.
They are defined or modified using the ADDUSER and ALTUSER commands. Protected user IDs can not
be authenticated via a password, password phrase, or RACF PassTicket, and are protected from being
revoked through incorrect password attempts {IA.3::IA.3.6-R12-RACFEAL5}.
7.2.2.1.1.1.7 Authentication Method Summary
The following TOE applications support client authentication via digital certificates when using TLS
sessions in the evaluated configuration:
● TN3270, when using a TN3270 emulator that supports TLS certificate based mutual
authentication. {IA.3-V2R5-TN3270-AUTHSSL}
The following TOE functions support authentication using passwords/phrases in the evaluated
configuration:
● TSO/E {IA.3::IA.3-R10-TSO-AUTHPHRASE}
● OpenSSH {IA.3::IA.3-R10-SSH-AUTHPHRASE}
● The z/OS UNIX shell commands su and passwd {IA.3::IA.3-R10-USS-AUTHPHRASE-1}
● The C runtime functions __login(), __passwd(), pthread_security_np() (and the
variants that accept an APPL ID), and getpass() {IA.3::IA.3-R10-LE-AUTHPHRASE}
● TN3270 Server {IA.3::IA.3-R13-TN3270-AUTHPHRASE}
● An operating system console {IA.3::IA.3-V2R5-CONSOLE-AUTHPHRASE}
OpenSSH supports authentication via public/private key pairs stored in digital certificates. It can be
configured to store the keys and certificates in RACF key rings {IA.3::IA.3-R12-SSH-AUTHRINGS}.
7.2.2.1.1.1.8 Handling of Groups During Authentication
During authentication, RACF construct security information that represents the user (subject) for
subsequent use during access checking.
● During RACF authentication, RACF determines whether list-of-groups processing is in effect
or not. If list-of-groups is not in effect, RACF puts the user's default group into the subject's
ACEE, or the group specified by the caller of the RACF interfaces for user authentication. If
Version: 2.27 Page 89 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
list-of-groups is in effect, RACF gathers a list of all the groups to which the user is connected,
and makes a copy of that list in the subject's ACEE. During access checking (DAC) for
MVS resources, RACF can then base its decisions on both the user ID and on the group
membership of the user {IA.3::IA.1.14-R12-RACFEAL5-1}.
● When a user attempts to use UNIX functions, RACF selects from the group(s) in the subject's
ACEE up to the first 300 (alphabetically) which have OMVS segments with GIDs defined.
During access checking (DAC) for UNIX resources, RACF can then base its decisions on the
user's UID and the selected groups' GIDs {IA.3::IA.1.14-R10-RACF-2}.
7.2.2.1.1.1.9 Assertion of User Identity
{IA.5::IA.5-R12-IDPROP-RACF-1} RACF supports specification on initACEE and RACROUTE
REQUEST=VERIFY of a distributed identity via a structure called an IDID (containing a user's
distinguished name (DN) and a domain/realm name (DC)):
● If an IDID is specified on initACEE but a RACF user ID is not specified, then initACEE will
perform a mapping operation using the IDIDMAP class to determine the associated RACF
user ID to use during RACROUTE REQUEST=VERIFY processing and will also include the IDID
information.
● If both an IDID and a RACF user ID are specified on initACEE, then initACEE will create an
ACEE for that user ID as it usually would and not perform mapping. Again, it will include the
IDID information on the RACROUTE REQUEST=VERIFY call.
● When an IDID is specified on RACROUTE REQUEST=VERIFY, RACF uses the other parameters
to create the ACEE as it normally does, but will anchor the IDID information in the ACEE for
later use during auditing.
{IA.5::IA.5-R12-IDPROP-RACF-2} RACF provides a 'RACMAP' command to allow the security
administrator to define 'mapping filter rules' to RACF that will support the mapping of distributed user
identities, as specified within the IDID data area, into RACF user IDs as required by the customer. This
new RACF command is similar to the existing RACDCERT command, which allows the specification of
mapping filter rules that RACF uses to map distributed user identities based on the 'subject' and 'issuer'
information within Digital Certificates. But instead of being limited to only user identities within Digital
Certificates, the new command supports the definition of mapping filter rules within the IDIDMAP class
based on an x.500 representation of the user identity and the 'Name-Space' that the user is defined
within.
{IA.5::IA.5-R12-IDPROP-RACF-3} The RACF R_cacheserv callable service provides a function
(function code 7) that will extract a copy of the ACEE for the currently active user in the form of a RACF
environment object (aka RACO), save that RACO in a data space, and return a context reference (ICRX)
that will uniquely identify that saved RACO. Subsequently an invoker of RACROUTE REQUEST=VERIFY
can provide that ICRX and RACF will recreate the security environment (ACEE) of the original user from
the RACO or from the IDID information in the ICRX if necessary. R_cacheserv will also allow deletion
of a cached security environment.
{IA.5::IA.5-V2R5-IDPROP-RACF-5}The RACF R_cacheserv service can also return authentication
data that RACF authentication functions (initACEE, RACROUTE REQUEST=VERIFY) will subsequently
accept and use to create an ACEE for the previously specified RACF user ID with an ICTX data area
cached on the earlier R_cacheserv invocation. That authentication data may be used at most once on
a subsequent authentication request.
{IA.5::IA.5-R12-IDPROP-RACF-4} RACF will provide an ENF 71 signal when an administrator has
issued an ALTUSER REVOKE or a CONNECT or REMOVE command that changes a user's group
connections, allowing applications that have cached ACEEs locally or via R_cacheserv to remove their
cache entries and recreate the ACEEs if needed.
Version: 2.27 Page 90 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
{IA.5::IA.5-V2R1-IDPROP-RACF-6} RACF will provide an ENF 71 signal when an administrator has
issued a DELUSER or DELGRP command allowing applications that have cached ACEEs local or via
R_cacheserv to remove cache entries.
{IA.5::IA.5-V2R1-IDPROP-RACF-7} RACF will provide an ENF 79 signal when an administrator has
issued a PERMIT command that changes a user's or group's authorization to resources in a resource
class that has been defined in the RACF Class Descriptor Table with the SIGNAL=YES option.
{IA.5::IA.5-V2R5-IDPROP-USS-1} The UNIX System Services __passwd() (BPX1PWD) and
pthread_security_np() (BPX1TLS) function allows appropriately authorized servers to assert a user
identity and create a security environment by specification of the authentication data obtained via a
prior authentication and use of R_cacheserv.
7.2.2.1.1.1.10 Access Banners
The TOE displays informative banners before or during the login to users. For SSH based logons, the
message can be configured in /etc/profile or in the SSH daemon configuration file with the Banner
keyword. For TSO based logons messages can in the logon panel module IKJLPENU. The document
[TSO.CUST], chapter 8 describes the details on the customizations of the logon panel {IA.5::TAB-
V2R4-1}.
7.2.2.2 Access Control (FDP)
7.2.2.2.1 Access Control Overview
7.2.2.2.1.1 Access control principles
z/OS provides the Resource Access Control Facility (RACF) as the component that performs access
control between subjects acting on behalf of a user and resources protected by the discretionary access
control policies. RACF uses user and resource profiles it stores in the RACF database to decide if a
subject has access to a non-UNIX resource. For UNIX resources, the access permissions are carried with
the resource itself (permission bits).
All z/OS components that have to make access decisions will call RACF through a z/OS interface. The
following figure shows the flow of requests and replies within z/OS when a request to access a protected
resource is made.
Figure 1: RACF Request Flow
A program that wants to access a resource uses a function that is part of the external interface provided
by the z/OS operating system to one of the z/OS components (1). An example is a program that wants
to open a data set.
Version: 2.27 Page 91 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
The z/OS component responsible for managing the resource calls the RACF component using the
internal interface to RACF (mainly the RACROUTE interface) to check the access rights of the user
that initiated the user request and passes the name and type of the resource and the requested type
of access to RACF {AC.1::AC.1.1}. The caller may also pass the ID of the user or an explicit user
security context (ACEE), or RACF obtains those values from the security context of the user that has
been established during user authentication (2) {AC.1::AC.1.2}.
RACF extracts the user information from the security context of the user or (in a few cases) from the
user profile, extracts the resource profile from its external database or the internal cache (3), and
checks to see if the user with his current security attributes is allowed to access the resource in the
requested access mode (4 and 5).
If the resource is known to RACF, RACF returns either a “yes” or a “no” decision for the access request
{AC.1::AC.1.3}. If the resource is not known to RACF, RACF may return a “don't know” return code
unless there are specific options set that allow RACF to take a yes or no decision (6) {AC.1::AC.1.4}.
In the case of a “don't know” result, the resource manager needs to make its own decision whether to
allow access or not. Depending on the decision, the resource manager will either perform or reject the
access request of the user program (7) {AC.1::AC.1.5}.
The protection philosophy of RACF is based on “profiles” that represent protected resources but also
users and groups. Profiles are organized in profile classes, where each class represents a type of
resource (such as data sets or terminals) or other entity (such as users or groups). A profile stores
attributes of the subject or object it represents.
For profiles that represent a protected resource, an access list can be assigned {AC.1::AC.1.6}. This
access list specifies the type of access subjects may have to the resource represented by the profile.
RACF handles 6 different types of access which are hierarchically ordered. Those access types are (from
low to high):
● NONE
● EXECUTE
● READ
● UPDATE
● CONTROL
● ALTER
Hierarchically ordered means that a higher access type implies also the lower access types.
To check access to a z/OS resource, a resource manager will call RACF specifying:
● the resource class
● the name of the resource
● a pointer to the user's ACEE (which represents the user)
● the requested type of access
If RACF knows the resource class and if this resource class is active, RACF will identify the resource
profile protecting the resource in that class, extract the access control list for that resource profile and
checks if the user has the requested type of access or a higher type of access. The exact details of this
access check algorithm are defined later in this section.
The semantics of a specific type of access are defined by the resource manager. This allows RACF to
used also for privilege management by defining a specific privilege as a specific type of access to a
specific profile in a specific class which represents the privilege. A resource manager then can call RACF
to check if a user has the required type of access to this profile and allow the user to perform a specific
Version: 2.27 Page 92 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
privileged function only if the user has that type of access. Quite a number of management activities
defined in the Security Management section are implemented that way and the Security Management
section describes the classes, profiles in the classes and the semantics z/OS assigns to specific access
types in those classes that are used for specific management privileges.
Access control to UNIX file system objects and IPC objects are also handled by RACF, but in the case of
these objects, the access rights are stored with the object itself. RACF still performs the access check.
For details, see the description of access control for UNIX objects.
7.2.2.2.1.2 Protected resources
The protected resources considered in detail in this Security Target are:
● Data sets
● Programs
● UNIX file system objects
● UNIX IPC objects
● System logger objects
As a general-access control system, RACF is capable of protecting a number of other resources, but
those are not considered in detail in this evaluation because it is up to the resource manager that
uses them to determine the valid resource names and the semantics of the access control decisions.
Instead, we will mention them below and later consider only the rules regarding their administration
via the RACF commands.
RACF can also protect installation-defined resource classes, which we will not consider at all in this
evaluation.
The reader should note that some other RACF classes are included in this evaluation that do not
represent “resources” but represent privileges or restrictions, where assigning “access” to a resource
in such a class to a user or a group just determines that the user or group has the privilege or restriction
associated with the profile. Those classes and profiles are described in the relevant subsection of
the access control section in this Security Target. The reader should also understand that granting
privileges that are not described in this document should be done with care, and only for trusted users,
as those privileges may allow administrative functions or extraordinary resource accesses.
Resource profiles of RACF are structured into an open set of “resource classes”. IBM provides a set of
resources classes used by z/OS (stored in the “static class descriptor table”), but RACF also allows for
the definition and activation of additional resource classes using the RDEFINE or RALTER commands
addressing the CDT general resource class (those are stored in the “dynamic class descriptor table”).
The dynamically defined classes need to be “activated” using the command SETROPTS RACLIST(CDT)
REFRESH. Resource classes represent “types” of objects that are access protected by RACF. IBM
supplies a default static class descriptor table, which is structured into resources used by different
components of z/OS as well as resources used by specific other IBM products like DB2 or CICS.
7.2.2.2.2 Discretionary Access Control
7.2.2.2.2.1 Datasets
7.2.2.2.2.1.1 Standard System Datasets
The following dataset contain the standard z/OS system libraries, as well as the kernel and drivers:
SYS1.PROCLIB
This library contains JCL procedures distributed with z/OS. In practice, there may be other JCL
procedure libraries (supplied with various program products) concatenated with it.
Version: 2.27 Page 93 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
SYS1.PARMLIB
This library contains control parameters for z/OS and for some program products. In practice,
there may be other libraries concatenated with it.
SYS1.LINKLIB
This library contains many of the basic execution modules of the system. In practice, it is one
of a large number of execution libraries that are concatenated.
SYS1.LPALIB
This library contains system execution modules that are loaded into the link pack area when
the system is initialized. There may be several other libraries concatenated with it. Programs
stored here are available to other address spaces.
SYS1.NUCLEUS
This library contains the basic supervisor ("kernel") modules of z/OS.
SYS1.SVCLIB
This library contains operating system routines known as supervisor calls (SVCs).
SYS1.SEZAINST
This library contains the configuration data sets and files that are used by the TCP/IP servers
and functions.
The data set name table (ICHRDSNT) is an installation-defined load module that describes the data
sets in the RACF database to RACF. This table contains entries describing each data set in the RACF
database and its backup data set. This database holds, amongst other information the encrypted user
password and passphrases.
The installation-defined "Cryptographic Key Data Set (CKDS)", which holds cryptographic keys managed
by the TOE.
The standard USS files and libraries are the following:
/etc
System configuration
/usr/bin, /usr/sbin, /bin, /sbin
System binaries
/usr/lib, /lib
System libraries
It should be noted, that the administrator is expected to follow the guidance and verify the standard
system datasets are protected from unauthorized access.
7.2.2.2.2.1.2 Standard data set naming conventions
By default, RACF expects a data set name (and the data set profile name) to consist of at least two
qualifiers. RACF also expects the high-level qualifier of the data set profile name to be either a RACF-
defined user ID or a RACF-defined group name.
If an installation has chosen to define data set profiles under the standard RACF naming conventions,
they can create a group for each high-level qualifier that is not a user ID, and permit users to
protect any data set that has that high-level qualifier by giving them CREATE authority in that group
{AC.2::AC.2.1}.
7.2.2.2.2.1.3 Table-driven data set naming conventions
An installation can use the naming convention table to set up and enforce a data set naming convention
other than that used by RACF {AC.2::AC.2.2}. The table can:
Version: 2.27 Page 94 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Supply a qualifier to be used as the high-level qualifier for authorization checking
{AC.2::AC.2.3}
● Convert data set names to RACF naming convention form for RACF use {AC.2::AC.2.4}
● Convert names in RACF form to the installation's format for external display {AC.2::AC.2.5}
● Enforce a naming convention by not allowing the definition of data sets that do not conform
to an installation's rules {AC.2::AC.2.6}
● Reduce RACF overhead by determining whether a data set is a user or group data set
An installation can create a naming convention table (module ICHNCV00), which RACF uses to check
and modify (internally to RACF) the data set name in all commands and macros that process data set
names {AC.2::AC.2.7}. An installation can use the table to selectively rearrange data set names to
“fit” the RACF convention without actually changing those names.
7.2.2.2.2.1.4 Protecting data sets that have single-qualifier data set names
If some of the data sets in an installation have names that consist of a single qualifier, one can still
RACF-protect those data sets {AC.2::AC.2.8}. To get RACF protection for single-qualifier names, the
SETROPTS command with the PREFIX operand must be issued.
This command defines a high-level qualifier to be used as a prefix for single-qualifier names and
activates the facility {AC.2::AC.2.9}. Then, when RACF processes requests for the data set, RACF
internally modifies single-qualifier names by adding the prefix, making the data set names acceptable
to RACF routines {AC.2::AC.2.10}. All SMF log records and all messages from RACF contain the RACF-
modified version of the data set name {AC.2::AC.2.11} unless the SETROPTS REALDSN option is in
effect {AC.2::AC.2-R10-RACF-1}.
7.2.2.2.2.1.5 Protecting user data sets
A user data set is a data set whose high-level qualifier is a RACF user ID. The following rules apply
to user data sets:
● In general, all RACF-defined users can protect their own data sets {AC.2::AC.2.12}
● A user can RACF-protect a data set for another user under any of the following conditions:
● The user who is protecting the data set has the SPECIAL attribute. A discrete or generic
profile can be created {AC.2::AC.2.13}.
● The user who is protecting the data set has the group-SPECIAL attribute, and the high-level-
qualifier of the data set name is a user within the group-SPECIAL user's scope of authority. A
discrete or generic profile can be created {AC.2::AC.2.14}.
● The user who is protecting a data set has the OPERATIONS attribute (or the group-
OPERATIONS attribute if the data set is within his scope of authority) and is simultaneously
creating the data set {AC.2::AC.2.15}.
In this case, the user can create a discrete profile:
● Through ADSP {AC.2::AC.2.16}
● By specifying the PROTECT operand on the TSO ALLOCATE command that creates the data set
{AC.2::AC.2.17}
● By specifying the PROTECT=YES OR SECMODEL=profile-name operands on the JCL DD
statement that creates the data set {AC.2::AC.2.18}
7.2.2.2.2.1.6 Protecting group data sets
A group data set is a data set whose high-level qualifier is a RACF group name. A RACF-defined user
can RACF-protect a group data set under any of the following conditions:
Version: 2.27 Page 95 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● The user has JOIN, CONNECT, or CREATE authority in the group {AC.2::AC.2.19};
● The user has the SPECIAL attribute (or the group-SPECIAL attribute for that group) and the
request is made using the ADDSD command {AC.2::AC.2.20};
● The user has the OPERATIONS attribute and is not connected to the group
{AC.2::AC.2.21}.
7.2.2.2.2.1.7 Controlling the creation of new data sets
Using data set profiles, an administrator can control whether users can create (allocate) new data sets.
For cataloged data sets, creating, deleting, or renaming the data set involves access not only to the
data set profile protecting the data set, but also to the catalog in which the data set is cataloged
{AC.2::AC.2.22}. In general, users need the following:
● To add entries to the catalog, users need authority to create the data set as specified below
and (except for SMS-managed data sets) UPDATE authority to the catalog {AC.2::AC.2.23}.
● To delete entries from the catalog, users need ALTER authority to the protecting profile or to
the catalog {AC.2::AC.2.24}.
The following cases describe how RACF can be used to control the creation of new user and group
data sets.
A user can create a new user data set in the following situations:
● The data set is covered by an existing generic profile and the user does not have ADSP
{AC.2::AC.2.25}. The creation is allowed if (1) the user has ALTER authority to the data set
through a generic profile or global access checking, or (2) the data set is the user's own data
set {AC.2::AC.2.26}.
● The data set name is not covered by an existing generic profile and the user does not
have ADSP and the data set is covered by the Global Access check table granting ALTER.
{AC.2::AC.2.27}
● The user has ADSP and the data set is the user's own data set. The creation is allowed and
RACF creates a discrete profile for the data set {AC.2::AC.2.28} .
● The user has the OPERATIONS attribute. If the user has the group-OPERATIONS attribute
instead of OPERATIONS, the high-level qualifier of the new data set must be the ID of a user
who is within the scope of that group {AC.2::AC.2.29-R12-RACF}.
A user can create a new group data set in the following situations:
● The data set name is protected by an existing generic profile and the user does not have
ADSP. The creation is allowed if at least one of the following is true:
● The user has ALTER authority to the data set through the generic profile or global access
checking {AC.2::AC.2.30}
● The user has CREATE authority in the group {AC.2::AC.2.31}
● The data set name is not covered by an existing generic profile and the user does not have
ADSP {AC.2::AC.2.32}
● The user has ADSP and the data set belongs to a group of which the user is a member. The
creation is allowed only if the user has CREATE authority in the group. If the creation is
allowed, RACF creates a discrete profile for the data set {AC.2::AC.2.33}
● {AC.2::AC.2.36-R12-RACF}The user has the OPERATIONS attribute , or the group-
OPERATIONS attribute for the group in question (directly or via a superior group), except
when both of the following are true: The user is connected to the group with less than
CREATE authority {AC.2::AC.2.34-R12-RACF}, and the user has less than ALTER access to
the data set if it protected by a generic profile {AC.2::AC.2.35-R12-RACF}
Version: 2.27 Page 96 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.2.2.1.8 Data set profile ownership
Each data set profile defined to RACF requires a RACF-defined user or group as the owner of the profile.
The owner (if a user) has full control over the profile, including the access list {AC.2::AC.2.37}.
If the owner of the data set profile is a group, users with group-SPECIAL in that group have full control
over the profile {AC.2::AC.2.38}.
Ownership of data set profiles is assigned when the profiles are defined to RACF but may be changed
later. Note that ownership of a data set profile does not mean that the owner can automatically
access that data set. To access a data set, the owner must still be authorized by the DAC rules
{AC.2::AC.2.39-V2R4}.
7.2.2.2.2.2 Programs
The ability of users to execute programs can be restricted by the RACF program control function. This
feature is useful for programs operating with privileges like authorized programs. Program control can
for example be used to restrict the ability of a user to start an authorized program from an authorized
library in a way such that it executes with APF authorization {AC.2::AC.2-V1R7-1}. Users may still
have read access to the library and may therefore copy the program into another library and execute
it from this library. Although this is possible, the program will then not execute with the privileges it
has when executed from the original library {AC.2::AC.2-V1R7.2}.
Program control (as described in this section) applies to programs residing in z/OS partitioned data sets
or libraries, not to programs stored as part of z/OS UNIX file system. Mechanisms for program control
for the z/OS UNIX subsystem are explained in another section of this Security Target.
z/OS allows for three modes for program control: BASIC, ENHANCED and ENHANCED-WARNING. The
mode is defined by the strings 'BASIC', 'ENHANCED' or 'ENHANCED-WARNING' in the APPLDATA field of
the IRR.PGMSECURITY profile in the FACILITY class {AC.2::AC.2.V1R7.3}. An empty value or any other
value than 'BASIC' or 'ENHANCED' will result in the ENHANCED-WARNING mode {AC.2::AC.2.V1R7.4}.
If the IRR.PGMSECURITY profile is not defined, BASIC mode is used {AC.2::AC.2.V1R7.5}. In
ENHANCED-WARNING mode the access decisions made by the TOE are the same as in BASIC mode
but a warning message is issued whenever the access would have been denied in ENHANCED mode
{AC.2::AC.2.V1R7.6} .
The checks that RACF makes when a user makes a request to load (execute) a program are:
i. If program control has been activated with SETROPTS WHEN(PROGRAM) {AC.2::AC.2-
V1R7.7}
ii. If program control is active, RACF checks to see whether the program is protected by a
profile in the PROGRAM class {AC.2::AC.2-V1R7.8}
iii. If the program is not protected, RACF determines whether there are any data sets currently
open using PADS or whether there are any execute-controlled programs in storage in the
address space:
● If there are no such data sets or programs, RACF marks the environment dirty
(uncontrolled) and allows the user to execute the program {AC.2::AC.2-V1R7.9}.
● If there are data sets currently opened using PADS, or programs to which the user
has only EXECUTE authority, RACF fails the request and the system abends the task.
RACF issues message ICH423I to document the execute-controlled programs, or
message ICH424I to document the PADS data sets that caused the operation to fail.
In this way, RACF prevents uncontrolled programs from gaining access to protected
data or programs inappropriately {AC.2::AC.2-V1R7.10}.
iv. If the program is protected by a profile but the user does not have at least EXECUTE
authority to the program, RACF causes the system to abend the task because the user is not
authorized to execute the program {AC.2::AC.2-V1R7.11}.
Version: 2.27 Page 97 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
v. If the program is protected by a profile and the user has only EXECUTE authority to
the PROGRAM profile or to the library that contains the program (when the program is
loaded from a JOBLIB, STEPLIB, or tasklib), and if the job step or TSO session is running
in ENHANCED program security mode, RACF checks whether an appropriate program
established the program environment. RACF determines if the first program executed in the
job step had the 'MAIN' attribute, or (if necessary) if the program invoked by TSOEXEC or
IKJEFTSR had the 'MAIN' attribute. If the program does not have MAIN, RACF next determines
if the first program run in the current task (TCB) or the first program executed in some
parent task had the 'BASIC' attribute. If so, RACF allows the Program control request.
Otherwise, RACF fails the request and issues message ICH429I to describe the problem and
tell you what program established the environment {AC.2::AC.2-V1R7.12}.
vi. If the user is still authorized to execute the program and the program was defined with the
PADCHK attribute, RACF checks whether any program-accessed data sets are open.
● If no program-accessed data sets are open, RACF allows the user to execute the
program {AC.2::AC.2-V1R7.13}.
● If program-accessed data sets are open, RACF checks the user or program
combination to verify that the combination has at least the same authority to each
data set in the list that was required when each data set was opened.
● If the user or program combination has sufficient authority to all of the opened data
sets, RACF allows the user to execute the program {AC.2::AC.2-V1R7.14}
● If the user or program combination does not have sufficient authority to all of the
opened data sets, RACF causes the system to end the task (with abend code 306 or
806) {AC.2::AC.2-V1R7.15}.
With program control enabled, z/OS provides the ability to allow users to access data sets which they
are not allowed to access directly by using program controlled programs {AC.2::AC.2.V1R7.16}.
The following algorithm is used to determine if a user has access to a data set via a controlled program:
Whenever the user has the requested access to the data set as determined by normal RACF access
checking, access is granted {AC.2::AC.2.V1R7.17}.
If the user is not granted access to the data set with normal authorization checking, RACF checks the
data set's conditional access list if program control is active and the program currently executing is
executing as a RACF-controlled program in a clean environment. RACF authorizes the user to open
the program-accessed data set with the currently executing program if all of the following conditions
are met:
● The conditional access list contains the name of the currently running program, the name
of the first program currently running in the current task (TCB), or the name of the first
program currently running in a parent task, with the requested level of access or higher
{AC.2::AC.2.V1R7.18}.
● The user's group or user ID is associated with the program name in the conditional access
list {AC.2::AC.2.V1R7.19}.
● The current program environment (job step, or task established under TSO/E using TSOEXEC
or IKJEFTSR) is controlled. In other words, it has not loaded an uncontrolled program. If either
of these conditions are not met, the environment is considered uncontrolled. The user's
attempt to open the program-accessed data set fails and the task ends with abend code
913. RACF issues message ICH417I, specifying what caused the environment to become
uncontrolled {AC.2::AC.2.V1R7.20}.
● If the job step or TSO session is running in ENHANCED program security mode, one of the
following is true:
Version: 2.27 Page 98 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● The current environment (job step or task created by TSOEXEC or IKJEFTSR) first ran a
program defined with the 'MAIN' attribute.
● The current program running in the current task, or the first program run in the current task
or a parent task, has the BASIC attribute. If neither of these conditions is met, the user's
attempt to open the program-accessed data set fails and the task ends with abend code 913.
RACF issues message ICH426I, specifying the non-MAIN program that established the current
environment {AC.2::AC.2.V1R7.21} .
● If there is more than one controlled program running in the current environment (job step
or task created by TSOEXEC or IKJEFTSR), all of those programs defined with the PADCHK
attribute have conditional access list entries allowing them to access the data set. If one
or more programs in the environment are not authorized, the attempt fails and the task
terminates with abend code 913. RACF issues message ICH418I specifying one or more
programs that were missing from the conditional access list {AC.2::AC.2.V1R7.22}.
● If all the conditions for program access to data set are met and the requested type of
access is granted to the program by the profile protecting the data set, access is granted
{AC.2::AC.2.V1R7.23}.
7.2.2.2.2.3 DAC for MVS Resources
RACF controls the types of access to all MVS (non-UNIX) resources. The access types are ordered
hierarchically, an access type listed higher in the list implies all the access types lower in this list (except
for NONE access). The full semantics of each access type are defined by the resource manager. The
semantics for MVS data sets are:
● ALTER
ALTER allows users to read, update, delete, rename, move, or scratch the data set.
When specified in a discrete profile, ALTER allows users to read, alter, and delete the profile
itself including the access list {AC.4::AC.4.1}.
ALTER does not allow users to change the owner of the profile using the ALTDSD command
{AC.4::AC.4.2}. However, if a user with ALTER access authority to a discrete data set
profile renames the data set, changing the high-level qualifier to his or her own user ID, both
the data set and the profile are renamed, and the OWNER of the profile is changed to the
new user ID {AC.4::AC.4.3}.
When specified in a generic profile, ALTER gives users no authority over the profile itself
{AC.4::AC.4.4}.
● CONTROL
For VSAM data sets, CONTROL is equivalent to the VSAM CONTROL password; that is, it
allows users to perform improved control interval processing. This is control-interval access
(access to individual VSAM data blocks), and the ability to retrieve, update, insert, or delete
records in the specified data set {AC.4::AC.4.5}.
For non-VSAM data sets, CONTROL is equivalent to UPDATE {AC.4::AC.4.6}.
● UPDATE
Allows users to read from, copy from, or write to the data set {AC.4::AC.4.7}. UPDATE
does not, however, authorize a user to delete, rename, move, or scratch the data set
{AC.4::AC.4.8}.
● READ
Allows users to access the data set for reading only {AC.4::AC.4.9}. (Note that users who
can read the data set can copy or print it.)
Version: 2.27 Page 99 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● EXECUTE
For a private load library, EXECUTE allows users to load and execute, but not to read or copy
programs (load modules) in the library {AC.4::AC.4.10}.
● NONE
The specified user or group is not permitted to access the resource or list the profile
{AC.4::AC.4.11}.
These access types can be defined per user, group or for all users not addressed specifically by a user
or group access entry (“universal access”) {AC.4::AC.4.12}. It is also possible to specify ID(*) in an
ACL, which then applies to all RACF defined users, while the value for UACC applies to users not defined
in RACF {AC.4::AC.4.13}. To modify those entries (as well as other parts of the resource profile) a
user must be the owner of the profile, have ALTER access to the discrete profile of the resource or must
have the SPECIAL attribute in his user profile {AC.4::AC.4.14}.
The access lists defined in a profile can be either a standard access lists, allowing access in general or
a conditional access lists allowing access under defined conditions. Possible conditions are:
● the user must be logged on using a defined terminal that the user has been granted access
to {AC.4::AC.4.15}
● the user must be logged on to a defined console {AC.4::AC.4.16}
● the batch job requesting access must have been submitted from a defined JES input device
{AC.4::AC.4.17}
● the user must have entered the system from a defined network port {AC.4::AC.4.18}
● the resource manager has asserted a criteria, such as the name of an SQL role (SQLROLE),
which applies to this check, on the authorization request (note: this applies only to a
FASTAUTH type of authorization check) {AC.4::AC.4-R8-RACF-1} .
Access to resources can be controlled by discrete resource profiles or generic profiles for a set of
resources of the same type. Discrete profiles protect one single resource (e. g. one data set) while
generic profiles can be used to define a whole set of resources and protect them using a single profile
based on patterns in the resource name. Whenever a discrete profile exists for a resource it has
precedence over a generic profile that also would apply for the resource {AC.4::AC.4.19}. If more
than one generic profiles would apply, z/OS always chooses the most specific profile applicable based
on a matching algorithm {AC.4::AC.4.20}.
The access types above also apply to MVS resources other than data sets (called general resources).
However while the usages remain hierarchical in definition (ALTER includes UPDATE, UPDATE includes
READ, etc.) the interpretation and usage of the access types is the responsibility of each resource
manager. For most resource managers and resources, the meaningful access types are NONE (the
user/group has no access) or READ (the user/group does have access). For most cases access levels
higher than READ convey no added authority (except that ALTER allows administration of a discrete
profile). In specific cases the resource manager may treat UPDATE, CONTROL, and ALTER as granting
additional authority. This security target and evaluation will not address all of those cases.
7.2.2.2.2.4 Algorithm to check DAC Access to MVS Resources
To perform authorization checking for RACF-protected resources, RACF makes the following checks.
RACF stops processing when the request is granted or denied. This algorithm takes the mandatory
SETROPTS settings for RACF in the evaluated configuration into account.
Note: Statements with a grey background are not relevant for the evaluated configuration.
Mandatory SETROPTS options are:
Version: 2.27 Page 100 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
ADSP, CATDSNS(FAILURE), NOCOMPATMODE, CLASSACT(TEMPDSN), ERASE(ALL), GENERIC(*) ,
ENHANCEDGENERICOWNER, GLOBAL(*), JES(BATCHALLRACF), PROTECTALL(FAILURES)
1. For general resource classes, if the class of the resource is not active, RACF returns the "not
protected" return code. {AC.4::AC.4-V2R4-RACF-1}
2. If the RACF class must be RACLISTed, as specified in the class descriptor table (CDT), but is
not currently RACLISTed, RACF returns the "not protected" return code. {AC.4::AC.4-V2R4-
RACF-2}
3. If the user requesting access is "trusted" or "privileged", RACF grants the request. See the
following:
● If the user has the trusted attribute, RACF grants the request (unless the CSA or
PRIVATE operand was specified on the authorization request). Such requests can be
audited only by using the LOGOPTIONS operand on the SETROPTS command (which
audits access requests issued by all users) or the UAUDIT operand on the ALTUSER
command (which audits all access requests by a particular user).
● If the user has the privileged attribute, RACF grants the request (unless the CSA or
PRIVATE operand was specified on the authorization request). Such requests cannot
be audited.
{AC.4::AC.4-V2R4-RACF-3}
4. RACF invokes the naming convention table if:
● The naming convention routine exists
● The resource being checked is a CLASS data set
The naming convention table can continue REQUEST=AUTH processing or deny the request.
{AC.4::AC.4-V2R4-RACF-4}
5. If global access checking is active for the class, RACF searches the global access table
(unless the CSA or PRIVATE operand was specified on the authorization request). If RACF
finds a matching entry that allows access to the resource, RACF grants the request for all
users, except those with the RESTRICTED attribute. {AC.4::AC.4-V2R4-RACF-5}
6. RACF looks for a profile in storage or in the RACF database. If no profile is found that protects
the resource, RACF returns the default return code of the class. Specifically, no profile is
found in the following cases:
● Profiles for the class exist in the user's storage or in a data space, but no profile
matches the resource name.
● Profiles for the class do not exist in the user's storage, in a data space, or in the
RACF database.
{AC.4::AC.4-V2R4-RACF-6}
7. If users attempt to access their own resources, RACF grants the request. For example:
● For tape and DASD data sets, if the user ID of the requesting user is the high-level
qualifier of the data set name, RACF grants the request.
● For spool data sets, if the JESSPOOL class is active, RACF compares the user ID and
node of the requester with the user ID and node of the creator of the spool data set
(using the security token). If the user IDs match, RACF grants the request.
{AC.4::AC.4-V2R4-RACF-7}
8. RACF checks the user's access authority in the standard access list. If the user is in the list
and if the specified access authority is sufficient to allow access, RACF grants the request. If
the user is in the list and if the specified access authority is less than the requested access,
RACF continues processing at Step (III) (conditional access list checking). This prevents
access based on ID(*), UACC, or the OPERATIONS attribute. {AC.4::AC.4-V2R4-RACF-8}
Version: 2.27 Page 101 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
9. RACF determines whether the user has access to the resource because the user is a member
of a group and the group is on the standard access list. Which group is used depends on
whether list-of-groups processing is in effect. (List-of-groups processing is in effect if the
SETROPTS command has been issued with the GRPLIST operand.) RACF determines which
group to use according to the following rules:
● If list-of-groups processing is not in effect, RACF uses only the user's current connect
group.
● If list-of-groups processing is in effect, RACF finds all of the groups to which the user
is connected that are also in the access list. Of these groups, RACF uses the group
that has the highest access authority to the resource. (For example, assume that a
user is a member of groups A, B, and C. If group A has NONE access authority, group
B has READ access authority, and group C has UPDATE access authority, RACF uses
group C to determine the user's access.)
If the highest access authority is sufficient to allow the requested access, RACF grants
the request. If the highest group that was found in the list does not have the requested
authority, RACF continues processing at Step (I) (conditional access list checking). This
prevents access based on ID(*), UACC, or the OPERATIONS attribute. {AC.4::AC.4-V2R4-
RACF-9}
10. If a user ID of * is found on the standard access list, the current user is defined to RACF
without the RESTRICTED attribute, and the access authority granted to * is:
● Sufficient to allow the requested access, RACF grants the request.
● Not sufficient to allow the requested access, RACF continues processing at Step (II)
(OPERATIONS attribute checking).
{AC.4::AC.4-V2R4-RACF-10}
11. If the universal access authority (UACC) for the resource provides sufficient access authority
and the requesting user is not defined with the RESTRICTED attribute, RACF grants the
request. {AC.4::AC.4-V2R4-RACF-11}
12. (II) If the requesting user has the OPERATIONS attribute (or group-OPERATIONS if the
resource is within the scope of that group) and OPERATIONS access is allowed for the class,
RACF grants the request. {AC.4::AC.4-V2R4-RACF-12}
13. (I) RACF checks the user's access authority in the conditional access list specified with
WHEN(TERMINAL), WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH).
If the user is in the list, if the user meets the specified condition (such as logged on at
the specified terminal), and if the specified access authority is sufficient to allow access,
RACF grants the request. If the user is in the list with insufficient access authority, RACF
authorization processing continues at Step (III). {AC.4::AC.4-V2R4-RACF-13}
14. RACF determines whether the user has access to the resource because the user is a member
of a group that meets a condition specified on the conditional access list specified with
WHEN(TERMINAL), WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH).
Which group is used depends on whether list-of-groups processing is in effect. (List-of-
groups processing is in effect if the SETROPTS command has been issued with the GRPLIST
operand). RACF determines which group to use according to the following rules:
● If list-of-groups processing is not in effect, RACF uses only the user's current connect
group.
● If list-of-groups processing is in effect, RACF finds all of the groups to which the user
is connected that are also in the access list. Of these groups, RACF uses the group
that has the highest access authority to the resource. (For example, assume that
a user is a member of groups A and B. If A has READ access authority and B has
UPDATE access authority, RACF uses group B to determine the user's access.)
Version: 2.27 Page 102 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
If the group to be used according to the preceding rules has sufficient access authority to
allow the requested access, RACF authorization processing continues at Step 19. If none of
the user's groups has sufficient authority, RACF does not grant the request, and continues
with the next step. {AC.4::AC.4-V2R4-RACF-14}
15. If a user ID of * is found on the conditional access list specified with WHEN(TERMINAL),
WHEN(CONSOLE), WHEN(APPCPORT), WHEN(JESINPUT) or WHEN(SERVAUTH), and if the current
user is defined to RACF without the RESTRICTED attribute, and if the current user meets
the specified condition (such as logged on at the specified terminal), and the access
authority granted to * is sufficient to allow the requested access, RACF grants the request.
{AC.4::AC.4-V2R4-RACF-15}
16. (III) RACF checks the user's access authority in the conditional access list specified with
WHEN(PROGRAM). If the user is in the list, if the user meets the specified condition (such as
running the specified program), and if the specified access authority is sufficient to allow
access, RACF grants the request.
Note: For DASD data sets, if program control is active and a controlled program is executing,
RACF performs authorization checking for program access to data sets. If the user/program
combination is in the conditional access list with sufficient authority to allow access to the
data sets, RACF grants the request. If the user/program combination is in the conditional
access list with insufficient authority, RACF denies the request.
RACF determines whether the user has access to the resource because the user is a member
of a group that meets a condition specified on the conditional access list (such as running a
specified program). Which group is used depends on whether list-of-groups processing is in
effect. (List-of-groups processing is in effect if the SETROPTS command has been issued with
the GRPLIST operand.) RACF determines which group to use according to the following rules:
● If list-of-groups processing is not in effect, RACF uses only the user's current connect
group.
● If list-of-groups processing is in effect, RACF finds all of the groups to which the user
is connected that are also in the access list. Of these groups, RACF uses the group
that has the highest access authority to the resource. (For example, assume that
a user is a member of groups A and B. If A has READ access authority and B has
UPDATE access authority, RACF uses group B to determine the user's access.)
If the group to be used according to the preceding rules has sufficient access authority to
allow the requested access, RACF grants the request. If the group is specified in the list with
insufficient access authority, RACF denies the request.
{AC.4::AC.4-V2R4-RACF-16}
17. If a user ID of * is found on the conditional access list specified with WHEN(PROGRAM), and
if the current user is defined to RACF without the RESTRICTED attribute, and if the current
user meets the specified condition (such as logged on at the specified terminal or running
the specified program), and the access authority granted to * is sufficient to allow the
requested access, RACF grants the request. {AC.4::AC.4-V2R4-RACF-17}
18. If the WARNING flag is ON in the profile (set using the WARNING operand on the ADDSD, ALTDSD,
RDEFINE, or RALTER command), RACF grants the request. {AC.4::AC.4-V2R4-RACF-18}
19. Since SETROPTS CATDSNS(FAILURES) is in effect in the evaluated configuration, RACF denies
the request unless at least one of the following is true:
● The data set is newly created in this job, or is a system temporary data set.
● The data set is on tape, and the request is for UPDATE access.
● The data set is protected by a discrete profile.
Version: 2.27 Page 103 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● The data set is cataloged in the master catalog.
● The user has access to FACILITY resource ICHUNCAT.data set-name (truncated to
39 characters total, if needed);
● The user has the SPECIAL attribute.
Note: If the user gains access through having the SPECIAL attribute and none of the prior
conditions were true, RACF issues a warning message and creates an SMF record as though
CATDSNS(WARNING) were in effect. {AC.4::AC.4-V2R5-RACF-19}
20. For the DATASET class, if no profile is found, RACF denies the request since in the evaluated
configuration the SETROPTS PROTECTALL(FAILURES) option is in effect. {AC.4::AC.4-V2R4-
RACF-20}
When the SECLABEL class is active on your system, and a user or job requests access to a resource,
RACF compares the security label of the user with the security label of the resource using the algorithm
below before checking for discretionary access. Note that using SETROPTS NOMLS is not allowed in the
evaluated configuration when the SECLABEL class is activated.
1. If the user requesting access does not have a security label and the resource does have a
security label, RACF fails the request.
2. (IV) If the SETROPTS MLACTIVE(FAILURES) option is in effect and the resource does not have
a security label associated with it, and the resource class is DATASET or another class that
requires security labels as defined in the class descriptor table (CDT), RACF fails the request.
3. If the SETROPTS MLACTIVE(WARNING) option is in effect, RACF makes the same checks as in
Step (IV) If the access check fails because the resource does not have a security label, RACF
issues a warning message and grants the request.
4. (V) If the SETROPTS MLS(FAILURES) option is in effect, RACF checks for read-only request if
the user's security label dominates the security label of the resource and fails the request if
this is not the case. For a write request (which implies read), RACF tests if the user's security
label and the security label of the subject are equivalent and denies the request if they are
not.
5. If the SETROPTS MLS(WARNING) option is in effect for this resource class, RACF makes the
same checks as in Step (V). If any test fails the request, RACF issues a warning message and
grants the request.
6. If the resource is a JES spool data set, RACF uses the security label in the token associated
with the data set (specified on the RTOKEN parameter of the RACROUTE REQUEST=AUTH
macro). Otherwise, RACF uses the security label kept in the resource profile protecting the
resource, in the FSP for files, or in the ISP for IPC objects.
7.2.2.2.2.5 Access Control to System Logger Objects
Please refer to section Using a System Log Stream for SMF.
7.2.2.2.2.6 z/OS UNIX file system objects
UNIX file system objects in the zFS file system have their access control defined by:
● UNIX permission bits
● Access control list entries
All of those access-control-related attributes of file system objects are stored with the object. Access
control lists are stored and managed as extended attributes of the file system object and are not
stored in the RACF database {AC.2::AC.2.65-V2R4}. RACF is still involved when an access decision
is made to a UNIX file system object {AC.2::AC.2.66}. The UNIX System Services subsystem of the
TOE extracts the permission bits, access control list entries from the file system object as well as
Version: 2.27 Page 104 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
the effective user ID the user that performed the request and passes this information to RACF using
the ck_access RACF callable service. RACF then evaluates this information, extracts other information
relevant for the access decision from the RACF database, performs the auditing in accordance with the
audit policy defined by the system administrator and returns the access decision to the calling UNIX
System Services subsystem of the TOE {AC.2::AC.2.67-V2R4}.
Besides the access control lists, additional privileges and restrictions may be defined to allow a finer
granularity. Those privileges and restrictions are defined as profiles in the UNIXPRIV class and users
can be granted those privileges or restrictions by giving them authority to those profiles. The ones that
are considered in this Security Target are:
● SUPERUSER.FILESYS.ACL.ACLOVERRIDE
When this profile is defined and active in RACF, a user who has been given authority to this
profile is able to override the access control defined by the access control lists for z/OS UNIX
file system objects.
In z/OS, a UNIX superuser can access all z/OS UNIX files, but is still bound by his rights
defined in RACF with respect to z/OS data sets and other resources {AC.2::AC.2.68-V2R4}.
● SUPERUSER.FILESYS.DIRSRCH
Users with at least READ access to this profile are allowed to search directories regardless of
the general access control settings {AC.2::AC.2-V2R4-6}
7.2.2.2.2.7 z/OS UNIX IPC objects
z/OS UNIX IPC objects are subject to discretionary access control. The permission bits associated with
the IPC object define the discretionary access to those objects. The permission bits are determined by
the creator of the IPC object and are saved in-memory by the UNIX Kernel. UNIX System Services will
collect the permission bits from the IPC object and call RACF using the ck_IPC_access RACF callable
service. RACF will then determine if the user can be granted the requested type of access and returns
the decision to UNIX System Services. For security claims see DAC for UNIX objects.
7.2.2.2.2.8 DAC for UNIX objects
DAC controls for UNIX objects involve the user's effective UID and effective GID (which may be different
from the user's real UID and real GID) {AC.4::AC.4-R8-USS-1} and the user's supplemental GIDs. If
the user is connected to 5 groups, and 3 of them have GIDs, then he would have one real GID and 2
supplemental GIDs {AC.4::AC.4-R8-USS-2}.
DAC checking for UNIX file objects (files, directories) involves permission bits that specify the
permissions (read, write, execute/search) separately for the object's owner, the owning group, and
everyone else (the world), and optional access list entries (ACLs) with similar permission settings.
DAC checking for UNIX IPC objects (semaphores, shared memory) involves only permission bits.
7.2.2.2.2.9 Algorithm to check DAC access to UNIX file system objects
To perform authorization checking for z/OS UNIX files and directories, RACF makes the following checks.
RACF stops processing when the request is granted or denied.
Notes:
The effective UID and effective GID of the process is used in determining access decisions. The only
exception is that when CREDFUNCTION is AFC_ACCESS, the real UID and real GID are used. In other
words, if file access is being tested, rather than requested, the real UID and GID are used instead of
the effective UID and GID. The real and effective IDs are generally the same for a process, but if a
set-uid or set-gid program is executed, they can be different.
Version: 2.27 Page 105 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
If the requesting user is represented by an unauthenticated client ACEE, then the access check
algorithm defined below is performed first for the client, and then, if successful, for the server. Both
client and server must have access to the file in order for the request to succeed.
Statements with a grey background are not relevant for the evaluated configuration.
1. If the system (kernel) is the caller, then access is failed if either of the following conditions
occurs:
● The request includes execute authority for a file and execute authority cannot be
granted. In this condition, none of the permissions bits grant execute access, and, if
an ACL is present and the FSSEC class is active, no ACL entry grants execute access.
● Security label authorization checking fails. In this condition, the SECLABEL class
is active, the object being accessed is a directory, the directory's SECLABEL is not
SYSMULTI, and the CRED contains a SECLABEL.
Otherwise, access is granted. {AC.4::AC.4-V2R4-UNIX-1}
2. RACF checks for a profile in the FSACCESS class that covers the file system name when all of
the following conditions are met:
● The user does not have the AUDITOR or ROAUDIT attribute.
● A file system name was specified in the CRED.
● The FSACCESS class is active and RACLISTed.
If a matching profile is found and the user does not have at least UPDATE authority, access is
denied. Otherwise, access checking continues. {AC.4::AC.4-V2R4-UNIX-2}
3. RACF checks for a profile in the FSEXEC class that covers the file system name when all of
the following conditions are met:
● The request is for file execution access.
● A file system name was specified in the CRED.
● The FSEXEC class is active and RACLISTed.
If a matching profile is found and the user does not have at least UPDATE authority, access is
denied. Otherwise, access checking continues. {AC.4::AC.4-V2R4-UNIX-3}
4. If the SECLABEL class is not active, then go to Step (I). {AC.4::AC.4-V2R4-UNIX-4}
5. If the user has the TRUSTED or PRIVILEGED attribute, then access is granted automatically
unless the user is executing a file. If the user is executing a file, access is denied only if none
of the permissions bits grant execute access, and, if an ACL is present and the FSSEC class
is active, no ACL entry grants execute access. Otherwise, access is granted. {AC.4::AC.4-
V2R4-UNIX-5}
6. If the user has the RACF AUDITOR or ROAUDIT attribute, and has read or search access for a
directory is requested, access is granted. {AC.4::AC.4-V2R4-UNIX-6}
7. If SETROPTS MLFSOBJ is active and the file does not have a security label, the request is
failed.
8. If SETROPTS MLS is active (either in WARNING or FAILURES mode) and all of the following
conditions occur, the request is failed.
● The user has a security label.
● The file has no security label.
● The user explicitly requested write access but is not in writedown mode.
Note: The SETROPTS MLS(WARNING) option is not supported for UNIX files and directories,
and it is treated the same as MLS(FAILURES).
9. If the file has a security label but the user does not, then the request is failed.
Version: 2.27 Page 106 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
10. If the user's security label is equivalent to the security label of the file (this condition is also
satisfied if either security label is SYSMULTI), then continue at Step (II).
11. If ANY access is requested, then two security label dominance checks (RACROUTE
REQUEST=DIRAUTH) are performed: one for READ and one for WRITE. If either succeeds, then
continue at Step (II). Otherwise, the request is failed.
12. If the user is requesting write access along with read or search/execute access, then
a READWRITE dominance check is performed. If it succeeds, then continue at Step (II).
Otherwise, the request is failed.
13. If the user is requesting only read or search/execute access, then a READ dominance check is
performed. If it succeeds, then continue at Step (III). Otherwise, the request is failed.
14. If the user is requesting only write access, then a WRITE dominance check is performed. If it
succeeds, then continue at Step (II). Otherwise, the request is failed.
15. (I) If the user has the RACF AUDITOR or ROAUDIT attribute, and read or search access for a
directory is requested, access is granted. {AC.4::AC.4-V2R4-UNIX-7}
16. (II) If the user has UID(0), then access is granted automatically unless the user is executing
a file. If the user is executing a file, access is denied only if none of the permissions bits
grant execute access, and, if an ACL is present and the FSSEC class is active, no ACL entry
grants execute access. Otherwise, access is granted. {AC.4::AC.4-V2R4-UNIX-8}
17. If the UID matches the file owner UID, the file's "owner" permission bits are checked. If the
"owner" bits allow the requested access, then access is granted. Otherwise, go to Step (IV).
{AC.4::AC.4-V2R4-UNIX-9}
18. If the FSSEC class is active, and an ACL exists, and there is an ACL entry for the requesting
UID, then the permission bits of that ACL entry are checked. If the ACL entry allows the
requested access, then access is granted. Otherwise, go to Step (V). {AC.4::AC.4-V2R4-
UNIX-10}
19. If the GID matches the file owner GID, the file's "group" permission bits are checked. If
the "group" bits allow the requested access, then access is granted. {AC.4::AC.4-V2R4-
UNIX-11}
20. (III) If the FSSEC class is active, and an ACL exists, and there is an ACL entry for the
requesting GID, then the permission bits of that ACL entry are checked. If the ACL entry
allows the requested access, then access is granted. If not, then the next ACL entry is
checked until there are no more entries. {AC.4::AC.4-V2R4-UNIX-12}
21. If any of the user's supplemental GIDs match the file owner GID, the file's "group" permission
bits are checked. If the "group" bits allow the requested access, then access is granted.
{AC.4::AC.4-V2R4-UNIX-13}
22. If the FSSEC class is active, and an ACL exists, and there is an ACL entry for any of the
user's supplemental GIDs, then the permission bits of that ACL entry are checked. If the ACL
entry allows the requested access, then access is granted. If not, then the next ACL entry is
checked until there are no more entries. {AC.4::AC.4-V2R4-UNIX-14}
23. If at least one matching ACL entry was found for the GID, or any of the supplemental GIDs,
then processing continues with Step (V). If the GID, or any of the supplemental GIDs,
matched the file owner GID, then processing continues with Step (IV). Otherwise (neither the
GID nor any of the supplemental GIDs matched either the file owner GID or an ACL entry),
processing continues with the next step. {AC.4::AC.4-V2R4-UNIX-15}
24. If the requesting user has the RESTRICTED attribute, and the UNIXPRIV class is active and
RACLISTed, and the RESTRICTED.FILESYS.ACCESS resource is protected by a profile in the
UNIXPRIV class, and the user does not have at least READ access, then go to Step (IV).
{AC.4::AC.4-V2R4-UNIX-16}
Version: 2.27 Page 107 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
25. The file's "other" permission bits are checked. If the "other" bits allow the requested access,
then access is granted. Otherwise, go to Step (IV). {AC.4::AC.4-V2R4-UNIX-17}
26. (V) If the UNIXPRIV class is active and RACLISTed, and if the
SUPERUSER.FILESYS.ACLOVERRIDE resource is protected by a profile in the UNIXPRIV
class, then the user must have the correct access level as documented for the ck_access
(IRRSKA00) callable service in z/OS Security Server RACF Callable Services. If the profile
exists, it determines whether file access is granted or denied. {AC.4::AC.4-V2R4-
UNIX-18}
27. (IV) If the request is for directory read or search, the UNIXPRIV class is active and
RACLISTed, and the user has at least read permission to the SUPERUSER.FILESYS.DIRSRCH
resource, then access is granted. Otherwise, if the UNIXPRIV class is active and RACLISTed,
and if the SUPERUSER.FILESYS resource is protected by a profile in the UNIXPRIV class, then
the user must have the correct access level as documented for the ck_access ( IRRSKA00)
callable service in z/OS Security Server RACF Callable Services. If the profile exists, it
determines whether file access is granted or denied. {AC.4::AC.4-V2R4-UNIX-19}
28. If this step is reached, access is denied. {AC.4::AC.4.42}
7.2.2.2.2.10 Algorithm to check DAC access to UNIX IPC objects
The discretionary access control rules allow access to an IPC object,
● if the user has an effective user ID of zero {AC.4::AC.2.70}
● if the user is the owner or creator of the IPC object and the requested type of access is
allowed by the owner related permission bits {AC.4::AC.2.71}
● if the user is neither the owner or creator of the IPC object but is a member of the IPC
object's creating group or owning group and the requested type of access is allowed by the
group related permission bits {AC.4::AC.2.72}
● if the user is neither owner nor creator of the IPC object and also is not a member of the
IPC object's creating group or owning group and the access is allowed by the other related
permission bits {AC.4::AC.2.73}
If none of the above mentioned conditions is satisfied, permission is denied by the discretionary access
control rules for IPC objects {AC.4::AC.2.74}.
7.2.2.3 Audit (FAU)
7.2.2.3.1 Generation of audit records
The TOE provides a general facility to collect data required for auditing and accounting services.
This function, the System Management Facilities (SMF), collects and records system and job-related
information that an installation can use for such tasks as the following:
● Billing users
● Reporting reliability
● Analyzing the configuration
● Scheduling jobs
● Summarizing direct access volume activity
● Evaluating data set activity
● Profiling system resource use
● Maintaining system security
This component is used by the TOE to collect security-related auditing information as required by
FAU_GEN.1.
Version: 2.27 Page 108 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Each SMF record consists of a standard header which contains (among other information) the type of
the record and the time the record was produced {AU.1::AU.1.1}. SMF supports up to 256 different
record types. SMF records can only be generated by authorized processes or processes specifically
authorized to generate specific types of SMF records under the mediation of the TOE {AU.1::AU.1.2}.
One record type is usually reserved for a whole class of events where the individual events are identified
by the record subtype or event code in the header of the SMF record.
RACF as the central access control function has three SMF record types reserved for its use (80, 81,
83), with record type number 80 being the most important one. The information recorded in this record
type contains (among other non security related information):
● The record type
● Time stamp (time and date)
● System identification
● Event code and qualifier
● User identification
● Group name
● Authorities used to successfully execute commands or access resources
● Reasons for logging
● Command processing error flag
● Foreground user terminal ID or other port-of-entry information
● Job log number (job name, entry time, and date)
● RACF version, release, and modification number
Each record contains further data specific to the event code and qualifier {AU.1::AU.1.3}.
The administrator can configure RACF and other elements of the TOE to generate audit records for all
events listed in the table in FAU_GEN.1 {AU.1::AU.1-R9-MULTI-1} .
z/OS provides the capability to search the audit trail for specific events and relate them such that events
related to a specific user can be extracted from the audit trail {AU.1::AU.1.4-V2R4}.
Tools exist that allow user with access to the audit trail data to search the audit trail for specific events,
for audit events related to specific jobs / users and other criteria {AU.1::AU.1.5}. Tools exist that
transfer the audit data into human readable format {AU.1::AU.1.6}.
If an application has created an ACEE and specified ICTX= on the RACROUTE REQUEST=VERIFY to
associate an X.500-format distributed identity with the RACF user's ACEE, RACF will include that
distributed identity in the SMF records that it creates. {AU.1::AU.1-R12-RACF-1}
7.2.2.3.2 Protection of the audit trail
SMF writes audit records into either
1. Dedicated SMF data sets that have been defined during system configuration. At least two SMF data
sets must be defined by the administrator for compliance with the evaluated configuration. Those data
sets need to be protected against unauthorized access by appropriate RACF access control lists. The
administrator guidance documentation provides specific guidelines for the protection of the audit trail
using RACF.
Or
2. A system log stream, which may reside solely in DASD data sets, or in a combination of data sets and
a coupling facility structure for better performance, as specified by the administrator. The administrator
configures profiles in the LOGSTRM class to control who can access the data while it exists in the
managed log stream, and profiles in the DATASET class to control access to any data extracted from
the log stream.
Version: 2.27 Page 109 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.3.2.1 Using MVS Data Sets for SMF
When the system is started SMF searches for the first non-full data set in the list of SMF data sets
defined. This data set becomes the active SMF data set used to store audit records. Once this data set
is full, SMF marks the data set to be processed by the SMF Dump program and takes the next empty
data set as the active, searching the list of SMF data sets in a wraparound way {AU.2::AU.2.2}. The
operator is also alerted to switch the data set.
SMF data sets that are full need to be processed by the SMF Dump program, IFASMFDP. This program
copies the content of a full SMF data set to another data set (the “dump data set”) defined by the
installation and marks the SMF data set as empty {AU.2::AU.2.3}. The SMF Dump program itself
creates two SMF records (Dump Header and Dump Trailer) that are stored in the beginning and at
the end of the dump data set {AU.2::AU.2.4}. Dump data sets must be protected by RACF access
control lists.
If no non-full data set is found, SMF stores the records in its buffers until a data set is made available
{AU.2::AU.2.5}. If the TOE is configured according to the administrative guidance, the system will
halt if no buffer space is left {AU.2::AU.2.6}.
7.2.2.3.2.2 Using a System Log Stream for SMF
In contrast to using MVS data sets directly, when using a log stream for the SMF data only one logical
stream exists. Although this stream may reside in multiple MVS data sets as determined by system
logger processing, the administrator will view the stream as one logical entity, starting with the earliest
available data and ending with the current data, rather than dealing with the individual data sets.
Operators do not need to switch SMF data sets, nor dump them to archive storage, nor clear them.
Rather, the data can simply reside in the logger-managed data sets.
z/OS provides the IFASMFDL utility program that can extract an administrator-specified set of SMF data
from the log stream, based on time/date, system ID, and/or SMF record type and write that extracted
data to a standard MVS data set for later processing {AU.2::AU-R9-SMF-1}.
IFASMFDL can invoke exit routines, just as IFASMFDP can, and so the RACF SMF Unload routine will
work with IFASMFDL just as with IFASMFDP, providing an interpreted flat-file of RACF-relevant security
records for subsequent analysis {AU.2::AU-R9-RACF-1}.
7.2.2.4 Cryptographic Functions (FCS)
7.2.2.4.1 General Cryptography
Several components of the TOE use cryptographic functions as part of their security functions. With
the inclusion of the Integrated Cryptographic Services Facility (ICSF) the cryptographic functions are
provided by hardware coprocessors attached to the TOE. ICSF checks for the availability of hardware
support for individual cryptographic functions and uses this in the TOE in its evaluated configuration.
The TOE will use the support provided by CPACF and ICSF for AES, and the SHA-2 family of hash functions
in its evaluated configuration. For the RACDCERT command, ICSF is used.
This support function is used by RACDCERT for certificate public/private key pair generation using the
new secure PKCS#11 support. See the description for the RACDCERT command.
7.2.2.4.1.1 Cryptographic Functions supported by the TOE
The TOE also provides various cryptographic functions via ICSF that are available for use by applications
running on the system.
The TOE supports the following cryptographic primitives:
Version: 2.27 Page 110 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Encryption
The TOE has the capability to perform encryption and decryption operations with the following
algorithms and key sizes
● AES with CBC or CTR block chaining modes and 256-bit keys as defined in NIST SP
800-38A.
● AES in XTS mode with 256-bit keys as defined in NIST SP 800-38E.
● AES in GCM mode with 256 bit keys NIST SP 800-38D. And in the context of TLS
processing, according to [RFC5289]☝.
CR.2::CR-V2R5-COP-1
Hashing
The TOE has the capability to perform message digest generation in accordance with the
following cryptographic algorithms:
● SHA-256
● SHA-384
● SHA-512
with the implementation following FIPS Pub 180-4. CR.2::CR-V2R5-COP-2
Digital Signatures
The TOE has the capability to generate and verify signatures using the following algorithms and
key sizes:
● RSA with 3072 to 4096-bit keys using the RSASSA-PSS scheme (PKCS#1) FIPS PUB
186-4, "Digital Signature Standard (DSS)", Section 4.
It should be noted that the TOE in its evaluated configuration does not generate RSA
based digital signatures.
● ECDSA with:
❍ NIST curve=384
❍ NIST curve=521
as defined in FIPS 186-4 and specified in ANSI X9.62-1998, Public Key Cryptography
for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA).
CR.2::CR-V2R5-COP-3
HMAC
The TOE has the capability to perform keyed-hash message authentication with the following
cryptographic algorithms:
● SHA-256
● SHA-384
● SHA-512
The used key sizes are between 112 and 2048 bits, and the corresponding message sizes ares
256-, 384 and 512-bits respectively. The implementation follows FIPS Pub 198-1 The Keyed-
Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard. CR.2::CR-V2R5-
COP-4
For System SSL and this TOE, the algorithms implemented within System SSL or System SSL uses
directly through the CPACF are: symmetric AES CBC (256 bit); hashing algorithms SHA-2 (256 and 512
bit). {CR.1::CR-V2R5-SSL-1}
For ICSF and this TOE, the algorithms implemented within ICSF, ICSF uses directly through the CPACF
or CEX8C crypto card are: AES ECB, CBC, GCM (256 bit); hashing algorithms SHA-2 (256 and 512 bit);
asymmetric algorithms RSA(3072-4096bit) and EC-DH(384-521bit). {CR.1::CR-V2R5-ICSF-1}
Version: 2.27 Page 111 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.4.2 Cryptographic Key Destruction
z/OS provides two principal methods protecting cryptographic keys. Both of them are not subject to this
evaluation as they are provided be the operational environment and are mentioned here for information
to only (please refer to [ICSF.OVW], chapter 4 for additional information):
● Secure key, and
● Protected key
Secure keys are keys that are generated and used in the CryptoExpress cryptographic coprocessor
cards only. Operations with those keys are performed on those coprocessors only. Those keys never
leave the coprocessor in unencrypted form.
Protected keys are keys generated and established by an ICSF administrator and are immediately
after generation wrapped by a wrapping key inside the processor firmware. Instead of providing the
cryptographic operations implemented in the processor by CPACF with a key in clear, one may also
provide those operations with the wrapped key. The processor firmware checks the integrity of the
wrapped key provided and, if the integrity check passed successfully, unwraps the key in the firmware,
performs the requested cryptographic operation, and returns the result to the caller of the instruction.
This allows protecting keys even when they need to be used by applications that have no need to get
access to the key in clear. For those wrapped keys there is no need for explicit key destruction.
Keys used by the TSF are either clear session keys that are generated and held in volatile storage
only or long-living keys (public or private keys used for asymmetric encryption or long-living keys for
symmetric encryption) which are stored in non-volatile storage, which are data sets managed and
controlled by the TSF component ICSF.
Clear keys in volatile storage are usually either overwritten with new key values or - when in dynamically
allocated memory - are overwritten with zeros as part of the object reuse operating system functionality
when the memory is released. It has to be noted that all key material used for cryptographic functions
described in this Security Target when in volatile memory are in memory that is assigned to and is
accessible by the TSF only. Within the TOE however, keys are finally destructed when the power to
the memory is removed.
This applies to SSH, AT-TLS, IPsec and IKED. They all perform their cryptographic functions within their
own address space which is part of the TSF and protected from access by functions in other address
spaces from the operating system.
Long-living keys used by the TSF are stored in data sets managed by ICSF, which are encrypted using
secure key hat is held and managed solely by the cryptographic co-processor. Symmetric keys are are
encrypted using a symmetric master keys, where asymmetric keys are encrypted using an asymmetric
master key. As indicated that master key never leaves the cryptographic co-processor in the clear. The
managed keys never exist in the TOE's volatile memory in the clear.
ICSF also provides functions where users can use keys without having any access that would allow
them to access keys directly. Instead users are provided with key handles (if they are allowed by RACF
to use that key), which they can use to request ICSF to use the key in cryptographic functions and ICSF
will just provide the result of those functions to the user. In all those cases the keys themselves are
never stored in a user's address space and therefore users cannot access the keys.
Persistent ICSF keys are stored in VSAM data sets which are overwritten with spaces before the space
is eligible for allocation to another user. {CR.1::CR-V2R5-CKM4-1}
Note: As all keys managed by ICSF are stored encrypted using a master key that is managed by the
cryptographic co-processor, they are rendered unusable once their master key becomes unavailable.
The following table summarizes the keys used by the TOE, their storage as well as how they are
destructed:
Version: 2.27 Page 112 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Table 11: Cryptographic Keys used by the TOE
Key Generator Storage Destruction
TLS Session Keys ICSF Volatile overwrite with
zeroes
SSH Session Keys ICSF Volatile overwrite with
zeroes
Dataset encryption
keys
ICSF Persistent single overwrite with
spaces or with a new
value for the key
System SSL private
keys
ICSF Persistent single overwrite with
spaces or with a new
value for the key
SSH private keys ICSF Persistent single overwrite with
spaces or with a new
value for the key
7.2.2.4.3 Random Number Generation
The ICSF PKCS#11 implementation generates random bytes in compliance with NIST SP 800-90A
"Hash_DRBG". The Hash_DRBG is hardware (CPACF) based and is a SHA-512 Hash DRBG with a security
strength of 256 bits. The DRBG is seeded by a hardware based (CPACF) TRNG. {CR.1::CR-V2R4-
DRBG-1}
The CEX8C card is designed to meet NIST SP800-90B using a NIST SP 800-90A compliant 256-bit
strength SHA-512 Hash_DRBG. {CR.1::CR-V2R4-DRBG-2}
7.2.2.5 Security Management (FMT)
7.2.2.5.1 RACF User and Group Management
7.2.2.5.1.1 Definition of users and groups
z/OS users and groups are defined in RACF using user and group profiles.
To create a z/OS user, a user profile for the new user has to be created in RACF. Each user profile
consists of a base segment and optional segments for the use of specific subsystems. In the evaluated
configuration, the base segment and the OMVS segment for the specification of attributes for z/OS
UNIX System Services contain the information required by the security functions defined in this Security
Target. Other segments of the user profile may exist but the effects of any values in those segments
do not influence the security policy defined in this Security Target. RACF also supports a special user
profile segment, CSDATA, for which the security administrator can specify the format and content of the
data fields using other profiles in the CFIELD class, as well as specifying access rules in the FIELD class
to determine which users can view or update data in the segment {SM.1::SM.1-R10-RACF-19}.
To create or modify a user profile, a user must have one of the following authorities:
● the SPECIAL role as a general system administrator {SM.1::SM.1.1}
● the UPDATE authority to the fields in a non-base segment of the profile he wants to modify
through field-level access checking {SM.1::SM.1.2}
● the CLAUTH attribute for the USER class while one of the following is true when creating a
user:
Version: 2.27 Page 113 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ the user is the owner of the default group specified in this command;
❍ the user has JOIN authority in the new user's default group;
❍ the user's default group is within the scope of a group in which the user has the
group-SPECIAL attribute.
{SM.1::SM.1-V2R5-1}
● The user must have the SPECIAL attribute to give the new user the OPERATIONS, SPECIAL,
AUDITOR, or ROAUDIT attribute. The user does not need the SPECIAL attribute to specify the
OWNER operand. {SM.1::SM.1-V2R4-1}
● to modify the attribute of a user: the CLAUTH attribute for the user class {SM.1::SM.1.4}.
Note that only the CLAUTH and NOCLAUTH attribute can be changed {SM.1::SM.1.5}.
RACF allows groups of users to be defined, making the management of users and user attributes and
roles easier. To create a new group, a group profile must be defined in RACF. A group profile (as a
user profile) consists of a base segment and (optional) other segments. As with the user profiles all
group attributes related to the Security Policy as defined in this Security Target are contained in the
base segment and the OMVS segment of the group profile. Each group defined in RACF must be owned
by a RACF-defined user or by its superior group. Ownership of a group is assigned with the ADDGROUP
command when a new group profile is created and can be changed with the ALTGROUP command used
to change an existing group profile {SM.1::SM.1.6}.
RACF also supports a special group profile segment, CSDATA, for which the security administrator can
specify the format and content of the data fields using other profiles in the CFIELD class, as well as
specifying access rules in the FIELD class to determine which users can view or update data in the
segment {SM.1::SM.1-R10-RACF-20}.
The owner of a group or a user connected to a group that has the group-SPECIAL role can:
● Define new users to RACF (provided he also has the CLAUTH attribute for the USER class)
{SM.1::SM.1.7}.
● Connect and remove users from the group {SM.1::SM.1.8}.
● Delegate and change group authorities and set the default UACC for all new resources
belonging to members of the group {SM.1::SM.1.9}.
● Modify, list, and delete the group profile {SM.1::SM.1.10}.
● Define, delete, and list the names of the subgroups under the group {SM.1::SM.1.11}.
● Specify the group terminal option {SM.1::SM.1.12}.
Users can be connected to a number of groups and have the group-related authorities of all the groups
they are connected to {SM.1::SM.1.13}.
The OMVS segment of a group profile contains the group's z/OS UNIX group identifier.
Management of z/OS user and group profiles occurs primarily via the RACF commands described later
(ADDUSER, ALTUSER, DELUSER, LISTUSER , ADDGROUP, ALTGROUP, DELGROUP, LISTGRP). Administrators
enter these commands while running in a TSO session.
7.2.2.5.1.2 User roles and attributes
User roles and attributes are extraordinary capabilities, restrictions, or environments that can be
assigned to a user, either all of the time or when the user is connected to a specific group or groups.
User attributes are stored and managed within the RACF database.
When a role or attribute is to apply only to a specific group or groups, it is specified at the group
level and is called a group-related user attribute. For example, user attributes that are specified in
an ADDUSER or ALTUSER command are stored in the user's profile and are in effect regardless of the
group to which the user is connected {SM.1::SM.1.14}.
Version: 2.27 Page 114 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
RACF maintains the roles and attributes specified in this section in fields in the user profile. The
distinction between roles and attributes in this Security Target is artificial and reflects the definition
in Chapter 5 for roles and user attributed. RACF does not make this distinction and the IBM guidance
describes all of the following as user attributes.
Apart from the explicitly mentioned roles and attributes described below, users are assigned certain
roles implicitly:
● Users implicitly are in the “user” role which allows them to change their own authentication
data
● Users can be assigned the operator role by authorizing them to issue an operator command
in the command's own profile.
● Ownership of objects entitles users to change the object's security attributes. Ownership for
non-UNIX objects is identical to ownership of the profile protecting the object.
7.2.2.5.1.3 RACF Roles
7.2.2.5.1.3.1 SPECIAL and group-SPECIAL
A user who has the SPECIAL attribute at the system level can issue all RACF commands (but not all
operands. There are AUDITOR-only operands related to the configuration of the audit function that only
a user with the AUDITOR attribute is allowed to use) {SM.1::SM.1.15}. The SPECIAL attribute gives
the user full control over all of the RACF profiles in the RACF database. The SPECIAL attribute can also
be assigned at the group level. Such a user with the group-SPECIAL attribute has full control over all
of the profiles within the scope of the group.
A user with the SPECIAL role in his user profile is regarded as a system administrator. He can:
● add, delete, list and modify user, group, DATASET and other profiles {SM.1::SM.1.16}
● list and define RACF general options (except options related to auditing) {SM.1::SM.1.17}
A system administrator can delegate administrative activities to users such that they can administer
profiles belonging to a defined group. He does this by assigning such users the group-SPECIAL attribute.
Those users then have administrative capabilities within the group they were assigned the group
SPECIAL attribute {SM.1::SM.1.18}. Users with the attribute group-SPECIAL can not use general
RACF options of the SETROPTS command (except for the REFRESH GENERIC and LIST operands)
{SM.1::SM.1.19}.
7.2.2.5.1.3.2 AUDITOR and group-AUDITOR
The AUDITOR attribute is given only to users who are responsible for auditing RACF security controls
and functions. To provide a check and balance on RACF security measures, the AUDITOR attribute
should be given to security or group administrators other than those who have the SPECIAL attribute.
The AUDITOR attribute can also be assigned at the group level. Such a user with the group-AUDITOR
attribute can control the audit configuration within the scope of the group where the attribute was
assigned {SM.1::SM.1.20}.
A user with the AUDITOR attribute can define and modify the audit related options in user and
the auditor related options for resource profiles {SM.1::SM.1.21}. This allows him to define which
activities are to be recorded in the audit trail. He can also list the content of any profile and set the
system wide audit related options using the SETROPTS command. Those options are:
● AUDIT or NOAUDIT (for each profile class) {SM.1::SM.1.22}
● CMDVIOL or NOCMDVIOL {SM.1::SM.1.23}
● LOGOPTIONS (for each profile class) {SM.1::SM.1.24}
Version: 2.27 Page 115 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● OPERAUDIT or NOOPERAUDIT {SM.1::SM.1.25}
● SAUDIT or NOSAUDIT {SM.1::SM.1.26}
Audit configuration can also be delegated at the group level by giving the group-AUDITOR attribute
to a user.
A user with the group-Auditor attribute can define and modify the audit related options in user, and
resource profiles associated with his group {SM.1::SM.1.28}. He can not modify or set audit related
attributes that operate system-wide {SM.1::SM.1.29}. Note that a user with SPECIAL controls the
activation/deactivation of the OMVS audit related classes (DIRACC, DIRSRCH, FSOBJ, FSSEC, IPOBJ,
PROCACT and PROCESS)
7.2.2.5.1.3.3 ROAUDIT
A user who has the ROAUDIT attribute can monitor audit information and view RACF profiles to verify
that appropriate audit controls have been defined, but can not alter the auditing controls.
7.2.2.5.1.4 z/OS UNIX superuser
A user operating with an effective UID of zero or a user that has been authorized to the BPX.SUPERUSER
profile in the FACILITY class is defined to have the role of a z/OS UNIX superuser.
7.2.2.5.1.5 Pseudo user
A user defined with the NOPASSWORD, NOPHRASE, and NOOIDCARD parameter in his user profile is defined
as having the role of a "pseudo-user". The TOE prohibits that a user with those attributes can log into
the TOE. Those IDs can be used by SURROGAT-submitted batch jobs or by started procedures defined
in the STARTED class or the started procedures table.
7.2.2.5.1.6 RACF Attributes
CLAUTH
If a user has the CLAUTH attribute in a class, RACF allows the user to define profiles in that class
{SM.1::SM.1.32}.
Users receive the CLAUTH attribute on a class-by-class basis. The CLAUTH attribute can be assigned
at the user or group level {SM.1::SM.1.33}.
A user with the CLAUTH(USER) attribute can add and modify users except for setting or modifying the
following attributes:
● SPECIAL or NOSPECIAL {SM.1::SM.1.34}
● AUDITOR or NOAUDITOR {SM.1::SM.1.35}
● OPERATIONS or NOOPERATIONS {SM.1::SM.1.36}
● ROAUDIT or NOROAUDIT {SM.1::SM.1-V2R2-RACF-70}
7.2.2.5.1.7 REVOKE
A user can be prevented from entering the system by assigning the REVOKE attribute
{SM.1::SM.1.37}. This attribute is useful when a user needs to be prevented from entering the
system, but cannot be deleted using the DELUSER command because the user still owns RACF resource
profiles. It is also useful when a user must be temporarily prevented from using the system for some
reason.
User accounts can be revoked automatically after a period of inactivity {SM.1::SM.1.38}. This applies
also to accounts that have never been active {SM.1::SM.1.39}.
Version: 2.27 Page 116 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.5.1.8 User Revocation
User revocation can take two forms in the TOE:
● Revocation of the RACF user ID associated with a user: As all user authentication occurs via
RACF, and all users have a RACF identity, the administrator can revoke a user by using the
ALTUSER command with the REVOKE operand {SM.1::SM.1-R8-REV-1}. Note that this will
not cover immediate revocation, but it will prevent the user from entering the system in the
future.
● Revocation of a user's digital certificate: For certificates registered in RACF via the
RACDCERT command, the administrator can delete the certificate using RACDCERT
{SM.1::SM.1-R8-REV-2}. This will prevent the system from recognizing that certificate in
the future and associating it with the user's RACF identity.
For immediate revocation of a user in extreme situations a simple ALTUSER or certificate revocation
may not suffice. In that case the administrator may determine which applications the user has access
to (e.g., TSO/E, z/OS UNIX System Services). The administrator can then issue appropriate system or
application commands to determine if the user is active in the system, and if so issue the appropriate
system or application commands to terminate the user's sessions.
For example, for a TSO/E user the administrator could issue the CANCEL U=user-ID command. For a
batch job the administer could issue CANCEL jobname.
As a final resort the administrator could stop related servers if the administrator is not sure how to
locate the user's sessions on the system, as well as stopping all UNIX processing, TSO/E processing,
and batch processing.
7.2.2.5.2 Resource management
RACF makes access decisions based on information stored in profiles or in the metadata associated
with z/OS UNIX objects. RACF manages the following resource profiles:
● Data set profiles
● General resource profiles
General resource profiles apply to a number of resources defined as protected resources in this Security
Target. The structure of the profiles in RACF used to protect those resources is identical, but the
semantics of specific access rights is defined by the manager of the resource and may therefore differ
depending on the type of resource.
Profiles consists of a base segment and optionally a set of non-base segments. Fields within non-base
segments can be individually protected using the field-level access control possibilities provided by
RACF.
7.2.2.5.2.1 Data set profiles
A data set profile within RACF contains (among other data not relevant for the security functions defined
in this Security Target) the following:
Name Description
GENERIC, MODEL, or TAPE Indicates if it is a generic, a model or a tape data set profile
OWNER Owner of the data set profile
NOTIFY The TSO user who is to be notified whenever RACF uses this profile to deny access
to a data set
UACC The universal access authority for the data set or data sets protected by the profile
Version: 2.27 Page 117 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Name Description
AUDIT The type of auditing to be performed for the data set or data sets protected by the
profile
CATEGORY The security categories to be assigned to the data set or data sets protected by
the profile
ERASE A setting that indicates whether the data set or data sets protected by the profile
are to be erased when they are scratched
UNIT The unit type on which the data set resides (for discrete profiles only)
VOLUME The volume on which the data set resides (for discrete profiles only)
Table 12: Data Set Profile Structure and Content
Associated with those profiles is the access control list (ACL) for the profile. Each ACL entry defines the
access rights of a user or a group with respect to the resource protected by the profile.
Attributes within an ACL entry are:
● access type (none, execute, read, update, control, alter)
● user IDs and group IDs allowed for the access type
● conditions of access (among other):
❍ WHEN(CONSOLE( console-id ...))
Modifies the access authority. Specifies that the identified users or groups have the
specified access authority when executing commands originating from the specified
system console
❍ WHEN(JESINPUT( device-name ...))
Modifies the access authority. Specifies that the identified users or groups have the
specified access authority when entering the system through the specified JES input
device
❍ WHEN(PROGRAM( program-name...))
Modifies the access authority. Specifies that the identified users or groups have the
specified access authority when executing the specified program
❍ WHEN(TERMINAL( terminal-id ...))
Modifies the access authority. Specifies that the identified users or groups have the
specified access authority when logged on to the specified terminal
Data set profiles can be created using the ADDSD command. They can be modified using the ALTDSD
command and deleted using the DELDSD command. Access control lists for data set profiles can
be managed using the PERMIT command. For the conditions that need to be satisfied to use those
commands, see the section RACF Commands.
7.2.2.5.3 RACF configuration and management
7.2.2.5.3.1 Configuring RACF with the SETROPTS command
The SPECIAL and AUDITOR roles can define system wide-options of RACF with the SETROPTS command.
This command can be used (among other actions) to:
● Specify logging of certain RACF commands and events (requires AUDITOR). {SM.3::SM.3.3}
● Enable or disable list-of-groups access checking (requires SPECIAL). {SM.3::SM.3.4}
● Enable generic profile checking for all active classes (requires SPECIAL). {SM.3::SM.3.6}
Version: 2.27 Page 118 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Establish password syntax rules (requires SPECIAL). {SM.3::SM.3.7}
● Activate password processing for checking previous passwords, limit invalid password
attempts, and warn of password expiration (requires SPECIAL). {SM.3::SM.3.8}
● Control global access checking for selected individual resources or generic names with
selected generalized access rules (requires SPECIAL). {SM.3::SM.3.9}
● Activate auditing of access attempts to RACF-protected resources based on installation-
defined security levels (requires AUDITOR). {SM.3::SM.3.13}
● Activate enhanced generic naming (requires SPECIAL). {SM.3::SM.3.14}
● Activate protection for data sets with single-level names (requires SPECIAL).
{SM.3::SM.3.16}
● Control logging of real data set names (requires AUDITOR). {SM.3::SM.3.17}
● Enable the erasure of scratched DASD data sets (requires SPECIAL). {SM.3::SM.3.21}
● Activate program control (requires SPECIAL). {SM.3::SM.3.22}
Some administration activities can be delegated to user with other roles. See the definition of those
roles for the administrative options that can be set or defined by those roles.
To operate in correspondence with the requirements in this Security Target, the system
administrator needs to configure RACF (using the SETROPTS command) with the following options:
CATDSNS(FAILURES), NOCOMPATMODE, ERASE(ALL), GENERIC(*), PROTECTALL(FAILURES), CLASSACT
(TEMPDSN), JES(BATCHALLRACF). Additional parameter for the PASSWORD operand need to be set to
define the password policy. See RACF Passwords and Password Phrases for more information.
7.2.2.5.4 RACF Certificate and Key Management
RACF provides the RACDCERT command which can be used to
● generate public/private key pairs and certificates (DIGTCERT class) {SM.1::SM.1-R8-RACF-
RACDCERT-2}
● export a certificate or certificate packages to a data set, optionally with the private key
{SM.1::SM.1-R8-RACF-RACDCERT-3}
● install certificates into the RACF database and register them as belonging to a user or to
a certifying authority {SM.1::SM.1-R8-RACF-RACDCERT-4}. The __certificate()
and initACEE() services can also register/deregister certificates {SM.1::SM.1-R8-RACF-
RACDCERT-5}, and administrators an allow users to register their own certificates by
granting them READ access to FACILITY resource IRR.DIGTCERT.ADD {SM.1::SM.1-R8-
RACF-RACDCERT-6}.
● delete or list certificates in the RACF database {SM.1::SM.1-R8-RACF-RACDCERT-7}
● maintain (create, list, delete) key rings containing certificates (DIGTRING class)
{SM.1::SM.1-R8-RACF-RACDCERT-8}
● add certificates to or delete them from key rings {SM.1::SM.1-R8-RACF-RACDCERT-9}
● create mapping rules (certificate name filters) that can map client certificates that are
not installed/registered in the database to specified user IDs based on subject or issuer
information (DIGTNMAP class) {SM.1::SM.1-R8-RACF-RACDCERT-10}. This can allow a
many-to-one mapping for applications that do not need to have each user run under his
own ID. In this case, accountability can be maintained for auditing purposes by having
the application provide the subject's distinguished name via the X500Name parameter
when creating the security environment (ACEE) for the user {SM.1::SM.1-R8-RACF-
RACDCERT-11}. The mapping process can also make use of mapping criteria specified
by the DIGTCRIT class when it is necessary to map a client certificate into different IDs
depending on characteristics of the user's session (such as the application name, or system
name where the application is running) {SM.1::SM.1-R8-RACF-RACDCERT-12}.
Version: 2.27 Page 119 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● create and manage the contents of PKCS#11 cryptographic tokens contained in the ICSF
TKDS {SM.1::SM-1.R9-RACF-RACDCERT-13}.
● use ICSF to create and manage private cryptographic keys {SM.1::SM-1-V2R5-RACF-
RACDCERT-1}.
7.2.2.5.5 Audit configuration and management
Within the system configuration it needs to be decided, which SMF records shall be generated by z/OS.
Three record types (type 80, 81, and 83) are dedicated to RACF and are the most important ones for
security. Which events are actually recorded with those records can be configured by a user with the
AUDITOR attribute in his RACF user profile {AU.3::AU.3.1}. In addition record type 30 is generated
for a number of security related events.
Because a set of mandatory events is always audited, not all audit records (such as unauthorized
attempts to access the system or changes to the status of the RACF database) can be configured.
In addition, resource profiles can define which events related to this resource are audited
{AU.3::AU.3.2}. The owner of a resource profile as well as a user in the AUDITOR role are able to
change the entries related to auditing within the resource profile {AU.3::AU.3.3}.
The system can be configured to send certain audit messages to the security console to immediately
alert operators of detected policy violations {AU.3::AU.3.4}.
Users that have the ROAUDIT attribute can read the audit trail and obtain audit related information form
RACF profiles, but can not manage audit policy related aspects {AU.3::AU-V2R2-1}.
7.2.2.6 Object Re-Use
z/OS provides explicit object reuse functionality for the following objects, and z/OS ensures that these
objects are prepared for reuse before they are allocated to another subject:
● Memory objects are filled with zeros before they are allocated for the first time to a subject
{OR.1::OR.1.1}.
● z/OS data sets are erased when the data is released when the erase-on-scratch option is
active {OR.1::OR.1.2}.
● z/OS UNIX file system objects and z/OS UNIX IPC objects are cleared before they are made
accessible to a new subject {OR.1::OR.1.3-R13}.
7.2.2.7 Self Protection
7.2.2.7.1 Time Management
The TOE supports using the following reliable time sources:
Local Clock
An operator with appropriate authorization can use the SET command to set the local time (using
the CLOCK parameter) and the date (using the DATE parameter). {SP.1::TIME-V2R4-1}
It should be noted that this method of managing the time is only available if the TOE is not using
the STP protocol to use a synchronized network time source.
Synchronized Network Time
Synchronized network time is provided by the TOE's System z platform, which uses synchronized
platform time sources or by a network time server using the STP protocol to provide correct
time stamps to the TOE. Using the CLOCKxx PARMLIB member, the TOE is instructed to use the
specified time source to synchronize its clock. {SP.1::TIME-V2R4-2}
Version: 2.27 Page 120 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.7.2 Automatic Logout of Sessions
The TOE provides, for both TSO/E and USS a means of automatically logging out inactive sessions. For
TSO/E this is achieved by setting the timeout value JWT parameter in the SMFPRMxx member in PARMLIB.
Also the TIME parameter (in minutes) in the user's login procedure needs to be set accordingly. For
USS this is achieved by setting PWT(SMF) in the BPXPRMxx member in PARMLIB as well as setting the
environment variable _BPXK_TIMEOUT to the value SMF {SP.1::FTA-V2R5-1}.
7.2.2.7.3 Address Space Layout Randomization
With the ASLR feature is enabled, the start of the 24 and 31 bit low private areas will be increased by a
random number of 4k units ranging from 0-63 and 0-255 pages respectively. Similarly, the start 64 bit
private will be increased by a random multiple of megabytes. By changing the start of these storage
ranges, subsequent storage allocation requests will not be satisfied by the addresses that they normally
would be, making it more difficult for an attacker to guess the starting address of an executable or
some other storage area.
The system is using 6 bits of random data for 24bit address spaces and 8 bits of random data for all other
address spaces to randomize the layout of the address space as described {SP.1::ASLR-V2R4-1}.
7.2.2.7.4 Stack Buffer Overflow Protection
The TOE protects TOE binaries from stack-based buffer overflow attacks by using code that is inserted
into compiled modules when the STACKPROTECT C/C++ compiler option is being used. That inserted
code provides protection against malicious code or programming errors that overwrite or corrupt the
stack.
The following list provides the binaries shipped with the TOE that support stack-based buffer overflow
protection:
Binary Binary Binary
/bin/IBM/IEWULD /bin/IBM/FDBXDBD6 /bin/IBM/FDBXDBXX
/bin/IBM/FDBXDBX3 /bin/IBM/FDBXDBX6 /bin/IBM/FOMFTSO
/bin/IBM/FOMFUISH /bin/IBM/FSUMSBSN /bin/IBM/FSUMSCAT
/bin/IBM/FSUMVCHA /bin/IBM/FSUMSCHG /bin/IBM/FSUMSCHL
/bin/IBM/FSUMSCHM /bin/IBM/FSUMSCHT /bin/IBM/FSUMSCHW
/bin/IBM/FSUMSCKS /bin/IBM/FSUMSCMM /bin/IBM/FSUMSCMP
/bin/IBM/FSUMSCOS /bin/IBM/FSUMSDU /bin/IBM/FSUMSECH
/bin/IBM/FSUMSFLS /bin/IBM/FSUMSFND /bin/IBM/FSUMSGRP
/bin/IBM/FSUMSICV /bin/IBM/FSUMSLS /bin/IBM/FSUMSMKD
/bin/IBM/FSUMSNWG /bin/IBM/FSUMSPCK /bin/IBM/FSUMSPCT
/bin/IBM/FSUMSPRN /bin/IBM/FSUMSPWD /bin/IBM/FSUMSRM
/bin/IBM/FSUMSSD0 /bin/IBM/FSUMSSHB /bin/IBM/FSUMSTIM
/bin/IBM/FSUMSTRU /bin/IBM/FSUMSTST /bin/IBM/FSUMSUNE
/bin/IBM/FSUMSUNP /bin/IBM/FSUMSWC /bin/IBM/FSUMSYMN
/bin/IBM/FSUMSAR /bin/IBM/FSUMSAT /bin/IBM/FSUMSCNC
/bin/IBM/FSUMSCOL /bin/IBM/FSUMSCRT /bin/IBM/FSUMSDAT
/bin/IBM/FSUMSDMS /bin/IBM/FSUMSDPC /bin/IBM/FSUMSENV
/bin/IBM/FSUMSEXD /bin/IBM/FSUMSEXP /bin/IBM/FSUMSGEN
/bin/IBM/FSUMSID /bin/IBM/FSUMSIDN /bin/IBM/FSUMSJON
/bin/IBM/FSUMSLP /bin/IBM/FSUMSLPS /bin/IBM/FSUMSMKC
Version: 2.27 Page 121 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Binary Binary Binary
/bin/IBM/FSUMSMKF /bin/IBM/FSUMSOD /bin/IBM/FSUMSPEN
/bin/IBM/FSUMSPR /bin/IBM/FSUMSPSW /bin/IBM/FSUMSRMD
/bin/IBM/FSUMSSFL /bin/IBM/FSUMSSLP /bin/IBM/FSUMSSPL
/bin/IBM/FSUMSSRT /bin/IBM/FSUMSSTP /bin/IBM/FSUMSSTS
/bin/IBM/FSUMSSU /bin/IBM/FSUMSUNX /bin/IBM/FSUMSASA
/bin/IBM/FSUMSBC /bin/IBM/FSUMSCSP /bin/IBM/FSUMSCUT
/bin/IBM/FSUMSDD /bin/IBM/FSUMSDRN /bin/IBM/FSUMSFLD
/bin/IBM/FSUMSFU /bin/IBM/FSUMSGFL /bin/IBM/FSUMSGTC
/bin/IBM/FSUMSHED /bin/IBM/FSUMSLGN /bin/IBM/FSUMSLIN
/bin/IBM/FSUMSMEG /bin/IBM/FSUMSNHP /bin/IBM/FSUMSNIC
/bin/IBM/FSUMSNL /bin/IBM/FSUMLOGN /bin/IBM/FSUMSPST
/bin/IBM/FSUMSPTH /bin/IBM/FSUMSRNC /bin/IBM/FSUMSSCR
/bin/IBM/FSUMSSP0 /bin/IBM/FSUMSSVR /bin/IBM/FSUMSTBS
/bin/IBM/FSUMSTCH /bin/IBM/FSUMSTEE /bin/IBM/FSUMSTLK
/bin/IBM/FSUMSTOT /bin/IBM/FSUMSTPT /bin/IBM/FSUMSTR
/bin/IBM/FSUMSTTY /bin/IBM/FSUMSUDC /bin/IBM/FSUMSUNC
/bin/IBM/FSUMSUNQ /bin/IBM/FSUMSUPT /bin/IBM/FSUMSWHO
/bin/IBM/FSUMSWLL /bin/IBM/FSUMSWMI /bin/IBM/FSUMSWRT
/bin/IBM/FSUMSXRG /bin/IBM/FOMIPCRM /bin/IBM/FOMIPCS
/bin/IBM/FSUMSAWK /bin/IBM/FSUMSCAL /bin/IBM/FSUMSCLN
/bin/IBM/FSUMSCTG /bin/IBM/FSUMSCU /bin/IBM/FSUMSDFF
/bin/IBM/FSUMSED0 /bin/IBM/FSUMSFIL /bin/IBM/FSUMSLCL
/bin/IBM/FSUMSLEX /bin/IBM/FSUMSLGG /bin/IBM/FSUMSMAK
/bin/IBM/FSUMSML1 /bin/IBM/FSUMSMNP /bin/IBM/FSUMSMOR
/bin/IBM/FSUMSPTC /bin/IBM/FSUMSRML /bin/IBM/FSUMSTAL
/bin/IBM/FSUMSUCP /bin/IBM/FSUMSUNM /bin/IBM/FSUMSUST
/bin/IBM/FSUMSUUE /bin/IBM/FSUMSUUX /bin/IBM/FSUMSVI
/bin/IBM/FSUMSPS /bin/IBM/FSUMSCPI /bin/IBM/FSUMSPAX
/bin/IBM/FSUMSTAR /bin/IBM/FSUMSSTT /bin/IBM/FSUMSNM
/bin/IBM/FSUMSCS /bin/IBM/FSUMSCP /bin/IBM/FSUMSLK
/bin/IBM/FSUMSLN /bin/IBM/FSUMSMV /bin/IBM/FSUMSSH
/bin/IBM/FSUMSPG /bin/IBM/FSUMSDF /bin/IBM/FOTSXADD
/bin/IBM/FOTSXAGT /bin/IBM/FOTSXFTP /bin/IBM/FOTSXKGN
/bin/IBM/FOTSXKSC /bin/IBM/FOTSXPYC /bin/IBM/FOTSXSSH
/bin/IBM/FOTSXSCP /bin/IBM/CDAHE003 /bin/IBM/CDAHEAS0
/bin/ld /bin/dbxd64 /bin/dbx
/bin/dbx31 /bin/dbx64 /bin/tso
/bin/fomfuish /bin/basename /bin/cat
/bin/chaudit /bin/chgrp /bin/chlabel
/bin/chmod /bin/chtag /bin/chown
/bin/cksum /bin/sum /bin/comm
/bin/cmp /bin/compress /bin/du
/bin/echo /bin/false /bin/find
Version: 2.27 Page 122 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Binary Binary Binary
/bin/grep /bin/fgrep /bin/egrep
/bin/iconv /bin/ls /bin/mkdir
/bin/newgrp /bin/pack /bin/pcat
/bin/printf /bin/pwd /bin/rm
/bin/unlink /bin/sed /bin/getopts
/bin/command /bin/kill /bin/read
/bin/wait /bin/cd /bin/umask
/bin/alias /bin/bg /bin/fc
/bin/fg /bin/jobs /bin/unalias
/bin/ulimit /bin/hash /bin/type
/bin/time /bin/true /bin/test
/bin/uncompress /bin/zcat /bin/unpack
/bin/wc /bin/yacc /bin/ar
/bin/at /bin/batch /bin/cancel
/bin/col /bin/crontab /bin/date
/bin/dspmsg /bin/dspcat /bin/env
/bin/expand /bin/expr /bin/gencat
/bin/id /bin/iden /bin/join
/bin/lp /bin/lpstat /bin/mkcatdefs
/bin/mkfifo /bin/od /bin/printenv
/bin/pr /bin/passwd /bin/rmdir
/bin/setfacl /bin/sleep /bin/split
/bin/sort /bin/strip /bin/strings
/bin/su /bin/unexpand /bin/asa
/bin/bc /bin/csplit /bin/cut
/bin/dd /bin/dirname /bin/fold
/bin/fuser /bin/getfacl /bin/getconf
/bin/head /bin/logname /bin/line
/bin/mesg /bin/nohup /bin/nice
/bin/nl /bin/login /bin/paste
/bin/pathchk /bin/renice /bin/script
/bin/spell /bin/sysvar /bin/tabs
/bin/touch /bin/tee /bin/talk
/bin/tsort /bin/tput /bin/clear
/bin/tr /bin/tty /bin/uudecode
/bin/uuencode /bin/uniq /bin/uptime
/bin/who /bin/wall /bin/whoami
/bin/write /bin/xargs /bin/ipcrm
/bin/ipcs /bin/awk /bin/cal
/bin/calendar /bin/ctags /bin/cu
/bin/diff /bin/dircmp /bin/ed
/bin/file /bin/locale /bin/lex
/bin/logger /bin/make /bin/mailx
Version: 2.27 Page 123 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Binary Binary Binary
/bin/mail /bin/man /bin/more
/bin/patch /bin/rmail /bin/tail
/bin/uucp /bin/uname /bin/uustat
/bin/uuname /bin/uux /bin/vi
/bin/ex /bin/ps /bin/cpio
/bin/pax /bin/tar /bin/stty
/bin/nm /bin/md5 /bin/rmd160
/bin/sha1 /bin/sha224 /bin/sha256
/bin/sha384 /bin/sha512 /bin/cp
/bin/link /bin/ln /bin/mv
/bin/sh /bin/pg /bin/df
/bin/ssh-add /bin/ssh-agent /bin/sftp
/bin/ssh-keygen /bin/ssh-keyscan /bin/ssh-proxyc
/bin/ssh /bin/scp /bin/dbgld
/bin/as /usr/sbin/IBM/FOMRLOG2 /usr/sbin/IBM/FSUMSCHR
/usr/sbin/IBM/FSUMSMKN /usr/sbin/IBM/FSUMSUCD /usr/sbin/rlogind2
/usr/sbin/chroot /usr/sbin/mknod /usr/sbin/uucpd
/usr/lib/hwicmuss.dll /usr/lib/iewbndd.so /usr/lib/iewbndd6.so
/usr/lib/iewbnddx.so /usr/lib/dbx31.dll /usr/lib/dbx64.dll
/usr/lib/libigwznsqd64.so /usr/lib/libigwznsqd31.so /usr/lpp/zosmf/installableApps/izurestconsoles.ear/
libIzuConsoleJni64.so
/usr/lpp/zosmf/lib/libIzuCommandJni.so /usr/lpp/zosmf/lib/libIzuJesVsam64.so /usr/lpp/zosmf/lib/libIzuJesStatus64.so
/usr/lpp/zosmf/lib/libIzugJni64.so /usr/lpp/zosmf/lib/libIzuTsoSrvJni64.so /usr/lpp/zosmf/lib/libIzuRestJobsJni64.so
/usr/lpp/zosmf/lib/libIzuMessageQueueJni64.so /usr/lpp/zosmf/lib/libIzuCeaTsoJni64.so /usr/lpp/zosmf/lib/libIzuSgJni64.so
/usr/lpp/zosmf/lib/libIzuspJni64.so /usr/lpp/zosmf/lib/libIzudDmJni.so /usr/lpp/zosmf/lib/libIzuComplianceJni64.so
/usr/lpp/IBM/aie/zdnn/lib/libzdnn.so /usr/lpp/IBM/aie/zaio/lib/libzaio.so /usr/lpp/IBM/aie/zade/lib/libzade.so
/usr/lpp/IBM/zdg/REST/smf/v1/SmfBridgeImpl.so /usr/lpp/pkcs11/lib/csnpcapi.so /usr/lpp/pkcs11/lib/csnpca64.so
/usr/lpp/pkcs11/lib/csnpca3x.so /usr/lpp/dfsms/bin/libarcudll.so /usr/lpp/tcpip/lib/
libcmpiOSBase_EthernetPortProvider.so
/usr/lpp/tcpip/lib/
libcmpiOSBase_IPProtocolEndpointProvider.so
/usr/lpp/tcpip/lib/
libcmpiOSBase_NetworkPortImplementsIPEndpointProvider.so
/usr/lpp/tcpip/lib/
libcmpiOSBase_CSNetworkPortProvider.so
/usr/lpp/tcpip/lib/libEZAFTP.so /usr/lpp/tcpip/lib/libEZBCPP.so /usr/lpp/tcpip/lib/libEZBCPP64.so
/usr/lpp/tcpip/lib/libEZBTrustedPartner.so /usr/lpp/tcpip/lib/libEZBTrustedPartner64.so /usr/lpp/tcpip/lib/papi.dll
/usr/lpp/tcpip/lib/rapi.dll /usr/lpp/tcpip/X11R6/lib/X11.dll /usr/lpp/tcpip/X11R6/lib/ICE.dll
/usr/lpp/tcpip/X11R6/lib/PEX5.dll /usr/lpp/tcpip/X11R6/lib/SM.dll /usr/lpp/tcpip/X11R6/lib/Xaw.dll
/usr/lpp/tcpip/X11R6/lib/Xm.dll /usr/lpp/tcpip/X11R6/lib/Mrm.dll /usr/lpp/tcpip/X11R6/lib/Uil.dll
/usr/lpp/ihsa_zos/.31bit/lib/apachecore.dll /usr/lpp/ihsa_zos/.31bit/lib/libapr-1.so /usr/lpp/ihsa_zos/.31bit/lib/libaprutil-1.so
/usr/lpp/ihsa_zos/.31bit/lib/liblua.so /usr/lpp/ihsa_zos/.31bit/lib/libpcre.so /usr/lpp/ihsa_zos/.31bit/lib/libpcreposix.so
/usr/lpp/ihsa_zos/.31bit/modules/debug/
mod_mpmstats.so
/usr/lpp/ihsa_zos/.31bit/modules/debug/
mod_net_trace.so
/usr/lpp/ihsa_zos/.31bit/modules/debug/
mod_whatkilledus.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_a2e.so /usr/lpp/ihsa_zos/.31bit/modules/
mod_access_compat.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_actions.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_alias.so /usr/lpp/ihsa_zos/.31bit/modules/
mod_allowmethods.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_asis.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_auth_basic.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authn_anon.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authn_cert.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_authn_core.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authn_dbm.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authn_file.so
Version: 2.27 Page 124 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Binary Binary Binary
/usr/lpp/ihsa_zos/.31bit/modules/mod_authnz_ldap.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authnz_saf.so /usr/lpp/ihsa_zos/.31bit/modules/mod_authz_core.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_authz_dbm.so /usr/lpp/ihsa_zos/.31bit/modules/
mod_authz_groupfile.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_authz_host.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_authz_user.so /usr/lpp/ihsa_zos/.31bit/modules/mod_autoindex.so /usr/lpp/ihsa_zos/.31bit/modules/mod_cache.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_cache_disk.so /usr/lpp/ihsa_zos/.31bit/modules/mod_cgi.so /usr/lpp/ihsa_zos/.31bit/modules/mod_charset_lite.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_deflate.so /usr/lpp/ihsa_zos/.31bit/modules/mod_dir.so /usr/lpp/ihsa_zos/.31bit/modules/mod_env.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_expires.so /usr/lpp/ihsa_zos/.31bit/modules/mod_ext_filter.so /usr/lpp/ihsa_zos/.31bit/modules/mod_fastcgi.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_filter.so /usr/lpp/ihsa_zos/.31bit/modules/mod_headers.so /usr/lpp/ihsa_zos/.31bit/modules/mod_ibm_ssl.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_imagemap.so /usr/lpp/ihsa_zos/.31bit/modules/mod_include.so /usr/lpp/ihsa_zos/.31bit/modules/mod_info.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_ldap.so /usr/lpp/ihsa_zos/.31bit/modules/mod_log_config.so /usr/lpp/ihsa_zos/.31bit/modules/mod_logio.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_lua.so /usr/lpp/ihsa_zos/.31bit/modules/mod_macro.so /usr/lpp/ihsa_zos/.31bit/modules/mod_mem_cache.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_mime.so /usr/lpp/ihsa_zos/.31bit/modules/mod_mvsds.so /usr/lpp/ihsa_zos/.31bit/modules/mod_negotiation.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_proxy.so /usr/lpp/ihsa_zos/.31bit/modules/
mod_proxy_connect.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_proxy_fcgi.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_proxy_ftp.so /usr/lpp/ihsa_zos/.31bit/modules/mod_proxy_http.so /usr/lpp/ihsa_zos/.31bit/modules/mod_remoteip.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_reqtimeout.so /usr/lpp/ihsa_zos/.31bit/modules/mod_request.so /usr/lpp/ihsa_zos/.31bit/modules/mod_rewrite.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_setenvif.so /usr/lpp/ihsa_zos/.31bit/modules/mod_smf.so /usr/lpp/ihsa_zos/.31bit/modules/mod_speling.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_status.so /usr/lpp/ihsa_zos/.31bit/modules/mod_substitute.so /usr/lpp/ihsa_zos/.31bit/modules/mod_unique_id.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_unixd.so /usr/lpp/ihsa_zos/.31bit/modules/mod_userdir.so /usr/lpp/ihsa_zos/.31bit/modules/mod_usertrack.so
/usr/lpp/ihsa_zos/.31bit/modules/mod_vhost_alias.so /usr/lpp/ihsa_zos/.31bit/modules/mod_wlm.so /usr/lpp/ihsa_zos/.31bit/modules/mod_zos_cmds.so
/usr/lpp/ihsa_zos/lib/libapr-1.so /usr/lpp/ihsa_zos/lib/libaprutil-1.so /usr/lpp/ihsa_zos/lib/liblua.so
/usr/lpp/ihsa_zos/lib/libpcre.so /usr/lpp/ihsa_zos/lib/libpcreposix.so /usr/lpp/ihsa_zos/lib/apachecore.dll
/usr/lpp/ihsa_zos/modules/debug/mod_backtrace.so /usr/lpp/ihsa_zos/modules/debug/mod_mpmstats.so /usr/lpp/ihsa_zos/modules/debug/mod_net_trace.so
/usr/lpp/ihsa_zos/modules/debug/mod_whatkilledus.so /usr/lpp/ihsa_zos/modules/mod_a2e.so /usr/lpp/ihsa_zos/modules/mod_access_compat.so
/usr/lpp/ihsa_zos/modules/mod_actions.so /usr/lpp/ihsa_zos/modules/mod_alias.so /usr/lpp/ihsa_zos/modules/mod_allowmethods.so
/usr/lpp/ihsa_zos/modules/mod_asis.so /usr/lpp/ihsa_zos/modules/mod_auth_basic.so /usr/lpp/ihsa_zos/modules/mod_authn_anon.so
/usr/lpp/ihsa_zos/modules/mod_authn_cert.so /usr/lpp/ihsa_zos/modules/mod_authn_core.so /usr/lpp/ihsa_zos/modules/mod_authn_dbm.so
/usr/lpp/ihsa_zos/modules/mod_authn_file.so /usr/lpp/ihsa_zos/modules/mod_authnz_ldap.so /usr/lpp/ihsa_zos/modules/mod_authnz_saf.so
/usr/lpp/ihsa_zos/modules/mod_authz_core.so /usr/lpp/ihsa_zos/modules/mod_authz_dbm.so /usr/lpp/ihsa_zos/modules/mod_authz_groupfile.so
/usr/lpp/ihsa_zos/modules/mod_authz_host.so /usr/lpp/ihsa_zos/modules/mod_authz_user.so /usr/lpp/ihsa_zos/modules/mod_autoindex.so
/usr/lpp/ihsa_zos/modules/mod_cache.so /usr/lpp/ihsa_zos/modules/mod_cache_disk.so /usr/lpp/ihsa_zos/modules/mod_cgi.so
/usr/lpp/ihsa_zos/modules/mod_charset_lite.so /usr/lpp/ihsa_zos/modules/mod_deflate.so /usr/lpp/ihsa_zos/modules/mod_dir.so
/usr/lpp/ihsa_zos/modules/mod_env.so /usr/lpp/ihsa_zos/modules/mod_expires.so /usr/lpp/ihsa_zos/modules/mod_ext_filter.so
/usr/lpp/ihsa_zos/modules/mod_fastcgi.so /usr/lpp/ihsa_zos/modules/mod_filter.so /usr/lpp/ihsa_zos/modules/mod_headers.so
/usr/lpp/ihsa_zos/modules/mod_ibm_ssl.so /usr/lpp/ihsa_zos/modules/mod_imagemap.so /usr/lpp/ihsa_zos/modules/mod_include.so
/usr/lpp/ihsa_zos/modules/mod_info.so /usr/lpp/ihsa_zos/modules/mod_ldap.so /usr/lpp/ihsa_zos/modules/mod_log_config.so
/usr/lpp/ihsa_zos/modules/mod_logio.so /usr/lpp/ihsa_zos/modules/mod_lua.so /usr/lpp/ihsa_zos/modules/mod_macro.so
/usr/lpp/ihsa_zos/modules/mod_mem_cache.so /usr/lpp/ihsa_zos/modules/mod_mime.so /usr/lpp/ihsa_zos/modules/mod_mvsds.so
/usr/lpp/ihsa_zos/modules/mod_negotiation.so /usr/lpp/ihsa_zos/modules/mod_proxy_connect.so /usr/lpp/ihsa_zos/modules/mod_proxy_fcgi.so
/usr/lpp/ihsa_zos/modules/mod_proxy_ftp.so /usr/lpp/ihsa_zos/modules/mod_remoteip.so /usr/lpp/ihsa_zos/modules/mod_reqtimeout.so
/usr/lpp/ihsa_zos/modules/mod_request.so /usr/lpp/ihsa_zos/modules/mod_setenvif.so /usr/lpp/ihsa_zos/modules/mod_smf.so
/usr/lpp/ihsa_zos/modules/mod_speling.so /usr/lpp/ihsa_zos/modules/mod_status.so /usr/lpp/ihsa_zos/modules/mod_substitute.so
/usr/lpp/ihsa_zos/modules/mod_unique_id.so /usr/lpp/ihsa_zos/modules/mod_unixd.so /usr/lpp/ihsa_zos/modules/mod_userdir.so
/usr/lpp/ihsa_zos/modules/mod_usertrack.so /usr/lpp/ihsa_zos/modules/mod_vhost_alias.so /usr/lpp/ihsa_zos/modules/mod_wlm.so
Version: 2.27 Page 125 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Binary Binary Binary
/usr/lpp/ihsa_zos/modules/mod_zos_cmds.so /usr/lpp/ihsa_zos/modules/mod_proxy.so /usr/lpp/ihsa_zos/modules/mod_proxy_http.so
/usr/lpp/ihsa_zos/modules/mod_rewrite.so /usr/lpp/pkiserv/lib/ObjStore.dll /usr/lpp/pkiserv/lib/Serial.dll
/usr/lpp/pkiserv/lib/asn1.dll /usr/lpp/pkiserv/lib/confobj.dll /usr/lpp/pkiserv/lib/crypto.dll
/usr/lpp/pkiserv/lib/kspkix.dll /usr/lpp/pkiserv/lib/misc.dll /usr/lpp/pkiserv/lib/mvsutils.dll
/usr/lpp/pkiserv/lib/ossrv.dll /usr/lpp/pkiserv/lib/pkiapi.dll /usr/lpp/pkiserv/lib/pkiconf.dll
/usr/lpp/pkiserv/lib/pkimsg.dll /usr/lpp/pkiserv/lib/policy.dll /usr/lpp/pkiserv/lib/safring.dll
/usr/lpp/pkiserv/lib/pkilc.dll /usr/lpp/pkiserv/lib/librpkisJNI.so /usr/lpp/pkiserv/lib/cmpasn1.dll
/usr/lpp/pkiserv/lib64/librpkisJNI64.so /usr/lpp/Printsrv/lib/libaopjnixp.so /usr/lpp/Printsrv/lib/aopapi.dll
/usr/lpp/Printsrv/lib/aopapi2.dll /usr/lpp/Printsrv/lib/aoprform.dll /usr/lpp/Printsrv/lib/aopeapi.dll
/usr/lpp/Printsrv/lib/aoprxf.so /usr/lpp/Printsrv/lib/aop.so /usr/lpp/Printsrv/lib/aopdb.so
/usr/lpp/Printsrv/lib/aopipc2.so /usr/lpp/wbem/lib/libCIMxmlIndicationHandler.so /usr/lpp/wbem/lib/libIBMJobCompletedHandler.so
/usr/lpp/wbem/lib/libcmpiCppImpl.so /usr/lpp/wbem/lib/libCMPIProviderManager.so /usr/lpp/wbem/lib/libCMPIRProxyProvider.so
/usr/lpp/wbem/lib/libCMPIRTCPComm.so /usr/lpp/wbem/lib/libpegclient.so /usr/lpp/wbem/lib/libpegcliutils.so
/usr/lpp/wbem/lib/libpegcommon.so /usr/lpp/wbem/lib/libpegcompiler.so /usr/lpp/wbem/lib/libpegconfig.so
/usr/lpp/wbem/lib/libpegexportclient.so /usr/lpp/wbem/lib/libpeggetoopt.so /usr/lpp/wbem/lib/libpeglistener.so
/usr/lpp/wbem/lib/libpegmanagedclient.so /usr/lpp/wbem/lib/libpegprovider.so /usr/lpp/wbem/lib/libpegslp.so
/usr/lpp/wbem/lib/libpegslp_client.so /usr/lpp/wbem/lib/libSLPProvider.so /usr/lpp/wbem/lib/libcfzsys.so
/usr/lpp/wbem/lib/libpegclient64.so /usr/lpp/wbem/lib/libpegcommon64.so /usr/lpp/wbem/lib/libcfzsys64.so
/usr/lpp/cpo/lib/libcpoprovider.so /usr/lpp/cpo/lib/libcposocket.so /usr/lpp/cpo/lib/libcpoarm.so
/usr/lpp/cpo/lib/libcpoconsole.so /usr/lpp/cpo/lib/libcpostream.so /usr/lpp/cpo/lib/libcpoii.so
/usr/lpp/sdsf/java/lib_64/libisfbuffer.so /usr/lpp/sdsf/java/lib_64/libisfjcall.so /usr/lpp/gpm/bin/libgpmccli.so
Table 13: List of Executables with Stack-buffer Overflow Protection
Any other load module or executable the TOE ships does not have support for stack based buffer
overflow protection enabled as they are not compiled using the C/C++ compiler framework that
supports named protection or the protection mechanisms could not be applied for technical reasons.
7.2.2.7.5 Trusted Update Process
Updates are queried for, obtained, applied using the SMP/E subsystem. SMP/E is also used to verify the
signatures of the updates as well as the signatures of the responses of the update server. The signature
metadata is provided by IBM's updates servers by means of an additional file that is supplied as part
of the update or the query for updates. This file, named GIMPAF2.XML contains the SHA-256 hash sums
for the individual files of the packages comprising the updates or the query. GIMPAF2.XML contains the
SHA256withRSA signature, which is protecting the contents metadata from undetected modification.
This signature is verified upon acceptance of the package by SMP/E, where the GIMUNZIP program is
used for verification {SP.1::TUD-V2R5-1}.
The TOE does not differentiate between updates to applications and updates to the operating system.
The same mechanisms are used for both of them.
Signature, using the RSASSA-PSS scheme, verification is done using the cryptographic hardware:
IBMJCECCA is the backing methods for the cryptographic operations. The IBMJCECCA provider extends
the JCE capability with the use of hardware cryptography via the IBM Common Cryptographic
Architecture (CCA) APIs (which drive ICSF and the cryptographic hardware CEX8) {SP.1::TUD-
V2R5-2}.
Version: 2.27 Page 126 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.8 Communication Security
7.2.2.8.1 Methods of remote Administration
An Administrator can access the TOE using the TLS protected TN3270 (see section System SSL) as well
as the SSH protocol (see section OpenSSH) to carry out administrative actions.
7.2.2.8.2 Communications Server
z/OS provides basic networking functions with the Communications Server component. This subsystem
provides support for network communication using the IBM SNA protocols as well as the TCP/IP protocol
suite. APIs for both protocol stacks are provided. For IP, both IPv4 and IPv6 are supported.
The Communications Server uses RACF to protect access of users to the following resources:
● the TCP/IP stack in general {CS.1::CS.1.1}
● TCP and UDP ports {CS.1::CS.1.2}
● IP addresses {CS.1::CS.1.3}
● Network Security Services, which provides centralized services for clients allowing:
❍ IKE daemons to perform ECDSA signature generation and verification as well
as ECDSA certificate management/validation functions through the System SSL
gsk_validate_certificate_mode() API {CS.1::CS.1-R12-CS-NSS-5} and
through additional certificate revocation checking. {CS.1::CS.1-R13-CS-NSS-6}
z/OS provides the following security functions as part of the Communications Server:
● IPSec security associations:
The Communications Server can be configured to establish IPSec security associations
at the IP layer. All packets transmitted between security association endpoints will be
authenticated, encrypted, or both using the configured algorithms. The Communications
Server provides support for IPSec-protected communication in accordance with [RFC4301]☝
through [RFC4304]☝, [RFC4868]☝, [RFC4869]☝, [RFC4835]☝ [RFC4308]☝ {CS.1::CS.1-R12-
IPSec-1}.
IKEv2 in accordance with [RFC5996]☝, [RFC4307]☝, [RFC4753]☝, [RFC4754]☝, [RFC4809]☝
and [RFC4945]☝ {CS.1::CS.1-R13-IPsec-6}.
It also provides the IKE application that negotiates IPSec security association parameters
with communication peers {CS.1::CS.1-R8-IPSec-2}. IPSec is configured through the
PROFILE.TCPIP configuration and the Policy Agent.
IPSec, when authenticating using certificates, will obtain the subject alternate extension
present in the client's certificate and compare it contents to the identity defined in the IKE
security policy {CS.1::CS.1-R12-IPSec-7}.
In the evaluated configuration the following encryption algorithms are supported (see also
General Cryptography for additional information on the supported algorithms and key
lengths):
❍ AES-CBC-256 (specified by [RFC3602]☝), AES-GCM-256 as specified in [RFC4106]☝
for ESP encryption {CS.1::CS.1-V2R5-IPSec-8};
❍ AES-XCBC-MAC-96, HMAC-SHA2-256-128, HMAC-SHA2-384-192, HMAC-
SHA2-512-256 for ESP authentication and authentication header protection
([RFC4868]☝, [RFC3566]☝){CS.1::CS.1-V2R5-IPSec-9};
❍ IKEv2 as defined by the RFCs named above and no other RFCs for hash functions, for
key negotiation and SA establishment {CS.1::CS.1-V2R5-IPSec-10};
Version: 2.27 Page 127 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
❍ DH Group 20 (384-bit Random ECP), DH Group 21 (521-bit) [RFC5114]☝
{CS.1::CS.1-V2R5-IPSec-11};
❍ ECDSA algorithm for Peer Authentication [RFC4754]☝ {CS.1::CS.1-V2R5-
IPSec-12}.
Note: When hardware crypto has been activated, the cryptographic operations performed
by IPSec {CS.1::CS.1-R8-IPSec-3} and System SSL {CS.1::CS.1-R8-SSL-1} will make
use of the hardware crypto when appropriate, either through ICSF or the CPACF processor
instructions.
● TLS layer to set up a trusted channel to another trusted IT product, in a way transparent to
the application (called Application Transparent TLS, or AT-TLS). The selectable algorithms
can be limited by configuring a subset of allowable algorithms at the server. The TLS
protocol can be used to set up a trusted channel to another system through a potentially
insecure network. TLS protects the data against disclosure and attacks related to integrity
like undetectable modifications or replay. Servers can support encryption using AES with
256-bit key length. Application Transparent Transport Layer Security (AT-TLS) supports the
use of all cipher suites supported by System SSL {CS.1::CS.1.4-V2R4}. The TN3270 or e.g.
the FTP protocols can be enabled to use AT-TLS and can subsequently be tunneled through
TLS to establish a trusted channel to another trusted IT product that also implements this
protocol {CS.1::CS.1.5}. Applications that AT-TLS has been configured to support, can be
tunneled through SSL/TLS to establish a trusted channel to another trusted IT product that
also implements this protocol {CS.1::CS.1-V1R7.1}.
AT-TLS is configured through the PROFILE.TCPIP configuration file and the Policy Agent. .
● Packet filtering functionality that can control information flow into or out of the system based
on security characteristics of the packets or of the network interface they use, as follows:
❍ {CS.1::CS.1-R12-PF-1} Filter rules can apply to a packet based on information
within the packet or information external to the packet.
➤ Internal information: source address, destination address, protocol, source
port, or destination port, ICMP type and code, OSPF type, and mobility
header type.
➤ External information: the direction of packet flow routing attribute, security
class (determined by the network interface used by the packet).
❍ {CS.1::CS.1-R11-PF-3} A z/OS TCP/IP stack configured for IP security implements
a default “deny” policy in the absence of any configured filter rules.
7.2.2.8.3 System SSL
z/OS provides TLS functions via the System SSL component for applications wishing to use TLS
directly (without taking advantage of the AT-TLS functions of the Communications Server). The
selectable algorithms can be limited by configuring a subset of allowable algorithms at the server
{CS.2::CS.1-R8-SSL-2}. The TLS (Version 1.2 [RFC5246]☝, {CS.2::CS.1-V2R4-SSL-1} and Version
1.3 [RFC8446]☝ , {CS.2::CS.1-V2R4-SSL-2}), protocol can be used to set up a trusted channel to
another system through a potentially insecure network. TLS protects the data against disclosure and
attacks related to integrity like undetectable modifications or replay. Servers can support encryption
using AES with either 256-bit key length utilizing session keys generated with information provided
through an EC Diffie-Hellman key exchange method.
Note that in the evaluated configuration, SSLv2, SSLv3, TLSv1.0 and TLSv1.1 are not supported.
The following TLS 1.2 cipher suites are supported:
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 {CS.2::CS.1-V2R1-SSL-16} (number C024)
Version: 2.27 Page 128 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {CS.2::CS.1-V2R1-SSL-14} (number C02C)
The TOE supports the following groups in the "Elliptic Curve (Supported Groups) Extension" in the
"Client Hello":
● secp384r1 (number 0024)
● secp521r1 (number 0025)
{CS.2::CS.1-V2R5-SSL-24}.
The TOE presents the "signature_algorithms" extension in the "Client Hello" with the
"supported_signature_algorithms" value containing the following hash algorithms:
● SHA256 with ECDSA (0403)
● SHA384 with ECDSA (0503)
● SHA512 with ECDSA (0603)
and no other hash algorithms {CS.2::CS.1-V2R5-SSL-25}.
For TLS 1.3 the following ciphers are supported:
● TLS_AES_256_GCM_SHA384 {CS.2::CS.1-V2R4-SSL-22} (number 1302)
The TOE supports the following key exchange modes: ECDHE with the following key shares:
● secp384r1 (number 0024)
● secp521r1 (number 0025)
{CS.2::CS.1-V2R5-SSL-26}.
The TOE supports the following signature algorithms as defined in [RFC8446]☝, section 4.2.3:
● ECDSA_SECP384R1_SHA384 as defined in [FIPS186-4]☝ - SHA384 with ECDSA (0503)
● ECDSA_SECP521R1_SHA512 as defined in [FIPS186-4]☝ - SHA512 with ECDSA (0603)
{CS.2::CS.1-V2R5-SSL-27}.
The TOE does not support certificate pinning.
The TOE supports certificate validation according to [RFC6125]☝ using the DN as well as the DNS name
reference identifier {CS.2::CS.1-V2R5-SSL-1}. The TOE supports and validates wildcards as part
of the server certificates SAN extension (also according to [RFC6125]☝) {CS.2::CS.1-V2R5-SSL-2}.
The TOE supports certificate based client authentication by passing the client certificate to RACF for
validation. {CS.2::CS.1-V2R5-ATTLS-1}
When an X.509 certificate is presented as part of the TLS connection establishment, the TOE verifies the
certificate path, and certification validation process by verifying the rules described in Authentication
via Client Digital Certificates.
7.2.2.8.4 OpenSSH
The TOE provides the Secure Shell Protocol Version 2 (SSH v2.0) to allow users from a remote host to
establish a secure connection and perform a logon to the TOE.
The TOE supports the generation of ECDSA key pairs. These key pairs are used by OpenSSH for the
host keys as well as for the per-user keys.
OpenSSH supports the following cryptographic algorithms (please refer to General Cryptography for
additional information):
Encryption
aes256-ctr, aes256-cbc, AEAD_AES_256_GCM
Version: 2.27 Page 129 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Public Key Algorithms
ecdsa-sha2-nistp384 and ecdsa-sha2-nistp521
MAC algorithms
hmac-sha2-256, hmac-sha2-512 and AEAD_AES_256_GCM
Key Exchange Methods
ecdh-sha2-nistp384, ecdh-sha2-nistp521
Key Derivation Functions
Key derivation functions used by the TOE are according to RFC 5656 (Section 4).
{CS.5::CS.1-V2R5-SSH-1}.
z/OS provides OpenSSH functionality, with an sshd daemon that supports the SSHv2 protocol
{CS.5::CS.1-R8-SSH-1} and these commands to allow remote users to perform work on the z/OS
system:
● ssh, to establish a UNIX shell environment {CS.5::CS.1-R8-SSH-2}
● scp to perform remote file copying operations {CS.5::CS.1-R8-SSH-3}
● sftp to perform file transfer operations {CS.5::CS.1-R8-SSH-4}
● ssh-keygen to generate the host key files and the (EC)DSA key pairs {CS.5::CS.1-R8-
SSH-7}
Please refer to Authentication via Public/Private Key (SSH) for more information regarding user
authentication to the SSH server.
The SSH protocol can be used to set up a trusted channel to another system through a potentially
insecure network. SSH protects the data against disclosure and attacks related to integrity like
undetectable modifications or replay. SSH supports encryption using AES with 256-bit key length
{CS.5::CS.1-R8-SSH-6} , {CS.5::CS.1-R9-OpenSSH-1}.
Both OpenSSH client and server discard packets larger than 218
{CS.5::CS.1-V2R4-SSH-4}.
The following conditions affect OpenSSH's rekeying:
● processing at most 2^30 bytes covering both sent and received data or;
● the last re-key is more than 1 hour ago.
If any of these conditions is true, the TOE initiates a re-keying. This is controlled by the option
RekeyLimit which needs to be set appropriately in the OpenSSH configuration file.{CS.5::CS.1-V2R4-
SSH-5}.
With regard to the authentication functions supported by OpenSSH, please refer to Authentication
Method Summary as well as Authentication via Public/Private Key (SSH).
7.2.2.8.5 IPSec
Communications Server supports IPSec, and Internet Key Exchange (IKE). IP security for z/OS
Communications Server supports version 2 of the IKE protocol (IKEv2).
These features are implemented in the IP layer on a per packet basis, and thus are available to any
network application without requiring any special modifications.
Applications can also implement their own additional security features as necessary, on top of the
underlying IP security.
IP security policy is enabled, enforced, managed, and monitored through a coordinated effort of several
z/OS Communications Server components:
Version: 2.27 Page 130 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
● Policy Agent
The Policy Agent is used to configure IP security on a z/OS system. It reads the configuration
files that contain the IP security policy configuration statements, checks them for errors, and
installs them into the IKE daemon and the TCP/IP stack.
● Internet Key Exchange daemon (IKED)
The Internet Key Exchange daemon is responsible for retrieving IP security policy from Policy
Agent, and dynamically managing keys that are associated with dynamic IPSec VPNs. This
daemon also provides network management capabilities for IP security aspects of local TCP/
IP stacks.
● TCP/IP stack
The stack maintains a list of currently active IP filters and IPSec Security Associations,
actively filters network traffic, controls encryption and decryption of network data, and
maintains counters that are associated with an IPSec Security Association lifetime.
7.2.2.8.6 Management of Communications Server Functions
z/OS provides some basic configuration data sets and files for TCP/IP and TCP/IP based protocols. Those
configuration data sets that are also related to security are:
● PROFILE.TCPIP
Provides TCP/IP initialization parameters and specifications for network interfaces and
routing.
● TCPIP.DATA
Provides parameters for TCP/IP based client and server programs.
● Additional Communications Server configuration information (e.g., AT-TLS or firewall
functions) exists in policy files accessed via the Communications Server Policy Agent.
Configuration statements in those data sets define the properties (including security properties) of the
TCP/IP protocol itself as well as the main protocol server.
These policy files and data sets are protected by the system's access control mechanisms and are
available for changing to authorized users only.
7.2.2.9 Confidentiality Protection of Data Sets
With z/OS confidentiality protection of data sets, users can encrypt data at rest without requiring
application changes. z/OS data set encryption through RACF commands and SMS policies allows the
administrator to identify the data sets or groups of data sets that require encryption. The administrator
can specify an encryption key label, which refers to an encryption key. Both the key label and encryption
key must exist in the ICSF key repository (CKDS). With data set encryption, the administrator is able to
protect viewing the data in the clear. This is based on access to the key label that is associated with
the data set and used by the access methods to encrypt and decrypt the data.
z/OS data set encryption provides the ability to encrypt the following types of data sets:
● Sequential extended format data sets, accessed through BSAM and QSAM,
● VSAM extended format data sets (KSDS, ESDS, RRDS, VRRDS, LDS), accessed through base
VSAM and VSAM RLS,
● PDSE data sets which do not contain program objects.
Encrypted data sets must be in SMS-managed extended format. They also can be in compressed format.
To create an encrypted data set, a key label must be supplied on new data set allocation. The key
label must point to an AES-256 bit encryption key within the ICSF key repository (CKDS) to be used
Version: 2.27 Page 131 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
to encrypt or decrypt the data. For each encrypted data set, its key label is stored in the catalog. The
key label is not sensitive information; it identifies the encryption key. Dataset encryption makes uses
the XTS mode of operation for AES (as defined by IEEE P1619/D16) as well as CPACF for the actual
cryptographic operations.
{SM.4::CDP-V2R3-1} RACF controls which applications can use specific keys to ensure that keys
are used only by authorized users and jobs. To do so, the administrator can generate a RACF general
resource profiles in the CSFKEYS class. The CSFKEYS class controls access to cryptographic keys with
the key label. The user requires READ authority to the key label in the CSFKEYS class to access or
create the encrypted data set. Since the system requires cryptographic support from ICSF to process
encrypted data sets, users of encrypted data sets must be authorized to READ the CSNBKRR2 resource
in the CSFSERV class, either explicitly or through a generic resource profile. {SM.4::CDP-V2R3-9}
Conditional access to the keys can be granted in the context of accessing encrypted datasets by means
of the WHEN(CRITERIA(SMS(DSENCRYPTION))) parameter for PERMIT.
{SM.4::CDP-V2R3-2} To create an encrypted data set, the administrator must assign a key label to
the data set when it is newly allocated (data set create). A key label can be specified through any of
the following methods:
● RACF data set profile
● JCL, dynamic allocation, TSO
● SMS data class
● IDCAMS DEFINE
{SM.4::CDP-V2R3-3} To specify a key label using the DFP segment in the RACF data set profile, use
keyword DATAKEY(Key-Label). The system use this key label for extended format data sets that are
created after DATAKEY is added to the data set profile. Use new keyword NODATAKEY to remove a key
label, if defined, from the RACF DFP segment. The key label is ignored for a data set that is not a DASD
data set.
{SM.4::CDP-V2R3-4} To specify a key label using JCL, dynamic allocation, and TSO allocate,
use JCL keyword DSKEYLBL='key-label', dynamic allocation text unit DALDKYL, or TSO allocate
DSKEYLBL(label-name). DSKEYLBL is effective only if the new data set is on DASD. The key label is
ignored for a data set that is not a DASD data set.
{SM.4::CDP-V2R3-5} To specify a key label using SMS data class, use the Data Set Key Label field
on the ISMF DEFINE/ALTER panel. The system will use this key label for extended format data sets that
are created after the data set key label is added to the data class. The key label is ignored for a data
set that is not a DASD data set.
{SM.4::CDP-V2R3-6} To specify a key label using the IDCAMS DEFINE command for a VSAM CLUSTER,
use the KEYLABEL parameter; for example, KEYLABEL(MYLABEL). Any alternate index associated with
the CLUSTER will also be encrypted and use the same key label as specified for the CLUSTER. The key
label is ignored for a data set that is not a DASD data set.
{SM.4::CDP-V2R3-7} When a key label is specified on more than one source, the key label is derived
from one of the above sources only on the first data set allocation (on data set create). The key label
is derived in the following order of precedence:
1. From RACF DFP segment DATASET profile.
2. Explicitly specified on the DD statement, dynamic allocation text unit, TSO ALLOCATE
command, or IDCAMS DEFINE control statement.
3. From the data class that applies to the current DD statement.
{SM.4::CDP-V2R5-1} The TOE supports the encryption of the RACF database in a VSAM dataset.
Version: 2.27 Page 132 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
7.2.2.9.1 Enabling data set encryption
{SM.4::CDP-V2R3-8} An enablement action is required to allow the creation of encrypted data sets
when the key label is specified through a method outside of the DFP segment in the RACF data set
profile.
To allow the system to create encrypted sequential extended format or VSAM data sets using a
key label specified through a method other than through the DFP segment in the RACF data set
profile, the user must have at least READ authority to the following resource in the FACILITY class:
STGADMIN.SMS.ALLOW.DATASET.ENCRYPT
To allow the system to create PDSE data sets using a key label specified through a method other than
through the DFP segment in the RACF data set profile, the user must have at least READ authority to
the following resource in the FACILITY class: STGADMIN.SMS.ALLOW.PDSE.ENCRYPT.
Version: 2.27 Page 133 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
8 Abbreviations, Terminology, and References
8.1 Abbreviations
BCPii
Base Control Program internal interface
CC
Common Criteria
CFCC
Coupling Facility Control Code
CHPID
Channel Path Identifier
CP
Central Processor
CPC
Central Processing Complex
CSS
Channel Subsystem
HMC
Hardware Management Console
ICF
Internal Coupling Facility
IFL
Integrated Facility for Linux
IOCDS
I/O Configuration Data Set
LIC
Licensed Internal Code
MCM
Multichip Module
PR/SM
Processor Resource/Systems Manager™
PU
Processor Unit
SAP
Assist Processor
SAR
Security Assurance Requirement
SE
Support Element
SFR
Security Functional Requirement
ST
Security Target
Version: 2.27 Page 134 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
STP
Server Time Protocol
SVMM
Separation Virtual Machine Monitor
TKE
Trusted Key Entry
TOE
Target of Evaluation
zIIP
IBM zEnterprise Integrated Information Processor
APF
Authorized Program Facility
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.
Administrator
An administrator is responsible for management activities, including setting policies that
are applied by the enterprise on the operating system. This administrator could be acting
remotely through a management server, from which the system receives configuration
policies. An administrator can enforce settings on the system which cannot be overridden by
non-administrator users.
APF
The Authorized Program Facility is used to control access and use of authorized programs.
API
A specification of routines, data structures, object classes, and variables that allows an
application to make use of services provided by another software component, such as a
library. APIs are often provided for a set of libraries included with the platform.
app
Software that runs on a platform and performs tasks on behalf of the user or owner of the
platform, as well as its supporting documentation.
ASLR
An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR
makes it more difficult for an attacker to redirect control to code that they have introduced
into the address space of a process.
Assets
Information or resources to be protected by the countermeasures of a TOE.
Attack potential
The perceived potential for success of an attack, should an attack be launched, expressed in
terms of an attacker's expertise, resources and motivation.
audit log
See security log
audit record
An entry in the audit log.
Authentication data
Information used to verify the claimed identity of a user.
Version: 2.27 Page 135 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
authorized
A user be authorized to perform certain tasks with security implications. The possible
authorizations are:
● supervisor state of the CPU
● APF-authorized
● having access to memory keys 0 through 7
● running with USS UID 0
● authority to FACILITY resources BPX.DAEMON, BPX.SERVER, or BPX.SUPERUSER
● authority to UNIXPRIV resources
Authorized user
A user who may, in accordance with the TSP, perform an operation.
BCPii
IBM provides Base Control Program internal interface (BCPii) support within z/OS that allows
authorized applications to query, change, and perform operational procedures against the
installed System z hardware base through a set of application program interfaces. These
applications can access the System z hardware that the application is running on and extend
their reach to other System z processors within the attached process control (Hardware
Management Console) network.
CC
Common Criteria for Information Technology Security Evaluation.
CEM
Common Evaluation Methodology for Information Technology Security Evaluation.
check-stopped
This state indicates that a physical or logical processor has been subject to an unrecoverable
failure.
component
The smallest selectable set of elements that may be included in a PP, an ST, or a package.
Credential
Data that establishes the identity of a user, e.g. a cryptographic key or password.
CSP
Information that is either user or system defined and is used to operate a cryptographic
module in processing encryption functions including cryptographic keys and authentication
data, such as passwords, the disclosure or modification of which can compromise the security
of a cryptographic module or the security of the information protected by the module.
DAR Protection
Countermeasures that prevent attackers, even those with physical access, from extracting
data from non-volatile storage. Common techniques include data encryption and wiping.
DEP
An anti-exploitation feature of modern operating systems executing on modern computer
hardware, which enforces a non-execute permission on pages of memory. DEP prevents
pages of memory from containing both data and instructions, which makes it more difficult for
an attacker to introduce and execute code.
Developer
An entity that writes OS software. For the purposes of this document, vendors and developers
are the same.
EP
An implementation-independent set of security requirements for a specific subset of products
described.
Version: 2.27 Page 136 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
General Purpose Operating System
A class of OSes designed to support a wide-variety of workloads consisting of many
concurrent applications or services. Typical characteristics for OSes in this class include
support for third-party applications, support for multiple users, and security separation
between users and their respective resources. General Purpose Operating Systems also lack
the real-time constraint that defines Real Time Operating Systems (RTOS). RTOSes typically
power routers, switches, and embedded devices.
Host-based Firewall
A software-based firewall implementation running on the OS for filtering inbound and
outbound network traffic to and from processes running on the OS.
human user
Any person who interacts with the TOE.
identity
A representation (e.g. a string) uniquely identifying an authorized user, which can either be
the full or abbreviated name of that user or a pseudonym
internal TOE transfer object
Communicating data between separated parts of the TOE. An entity within the TSC that
contains or receives information and upon which subjects perform operations.
object
An object is a passive entity in a computing system. Objects are subject to access control. In
this document the term "object" can be used synonymously to "resource".
OS
Software that manages physical and logical resources and provides services for applications.
The terms TOE and OS are interchangeable in this document.
PII
Any information about an individual maintained by an agency, including, but not limited to,
education, financial transactions, medical history, and criminal or employment history and
information which can be used to distinguish or trace an individual's identity, such as their
name, social security number, date and place of birth, mother's maiden name, biometric
records, etc., including any other personal information which is linked or linkable to an
individual.
PP
An implementation-independent set of security requirements for a category of products.
processor unit
This is the generic term for the z/Architecture processor on the Multichip Module (MCM) that
can be characterized as a:
● Central Processor (CP) to be used by an operating system
● Internal Coupling Facility (ICF) to be used by the Coupling Facility Control Code (CFCC)
● Integrated Facility for Linux (IFL)
● Additional Assist Processors (SAPs) to be used by the Channel Subsystem (CSS)
● IBM zEnterprise Integrated Information Processor (zIIP)
resource
An object that can be allocated to a logical partition, i.e. channel path, control unit, I/O device,
storage, physical processor, logical processor.
role
A predefined set of rules establishing the allowed interactions between a user and the TOE
SAR
A requirement to assure the security of the TOE.
Version: 2.27 Page 137 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Sensitive Data
Sensitive data may include all user or enterprise data or may be specific application data
such as PII, emails, messaging, documents, calendar items, and contacts. Sensitive data must
minimally include credentials and keys. Sensitive data shall be identified in the OS's TSS by
the ST author.
SFR
A requirement for security enforcement by the TOE.
ST
A set of implementation-dependent security requirements for a specific product.
subject
A subject is an active entity in a computing system. Subjects can access objects. Subjects act
on behalf of users.
TOE
The product under evaluation. In this case, the Operating System as described in the TOE
description and the TOEs supporting documentation.
TSF
The security functionality of the product under evaluation.
TSS
A description of how a TOE satisfies the SFRs in a ST.
User
A user is subject to configuration policies applied to the operating system by administrators.
On some systems under certain configurations, a normal user can temporarily elevate
privileges to that of an administrator. At that time, such a user should be considered an
administrator.
8.3 References
Common Criteria for Information Technology Security Evaluation
Version 3.1R5
Date April 2017
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.p
df
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R5.p
df
CC
Location http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.p
df
Digital Signature Standard (DSS)
Date 2013-07-19
FIPS186-4
Location https://csrc.nist.gov/pubs/fips/186-4/final
z/OS 2.5 Cryptographic Services: Integrated Cryptographic Service
Facility Overview
Version SC14-7505-10
ICSF.OVW
Date April 2023
z/OS 2.5 Planning for Multilevel Security and the Common Criteria
MLSGUIDE
Version GA32-0891-50
Version: 2.27 Page 138 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Date August 2023
z/OS 2.5 MVS Initialization and Tuning Guide
Version SA23-1379-50
MVSTUNE.G
Date March 2023
Operating System Protection Profile
Author(s) BSI
Version 2.0, BSI-CC-PP-0067
OSPP
Date 2010-06-01
Functional Package for SSH Version 1.0
Date 2021-05-13
PKG_SSH_V1.0
Location https://www.niap-ccevs.org/protectionprofiles/459
Protection Profile for General Purpose Operating Systems Version 4.3
Date 2022-09-27
PP_OS_V4.3
Location https://www.niap-ccevs.org/protectionprofiles/469
The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
Author(s) S. Frankel, H. Herbert
Date 2003-09-01
RFC3566
Location http://www.ietf.org/rfc/rfc3566.txt
The AES-CBC Cipher Algorithm and Its Use with IPsec
Author(s) S. Frankel, R. Glenn, S. Kelly
Date 2003-09-01
RFC3602
Location http://www.ietf.org/rfc/rfc3602.txt
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating
Security Payload (ESP)
Author(s) J. Viega, D. McGrew
Date 2005-06-01
RFC4106
Location http://www.ietf.org/rfc/rfc4106.txt
The Secure Shell (SSH) Authentication Protocol
Author(s) T. Ylonen, C. Lonvick
Date 2006-01-01
RFC4252
Location http://www.ietf.org/rfc/rfc4252.txt
The Secure Shell (SSH) Transport Layer Protocol
Author(s) T. Ylonen, C. Lonvick
Date 2006-01-01
RFC4253
Location http://www.ietf.org/rfc/rfc4253.txt
Security Architecture for the Internet Protocol
Author(s) S. Kent, K. Seo
Date 2005-12-01
RFC4301
Location http://www.ietf.org/rfc/rfc4301.txt
IP Authentication Header
Author(s) S. Kent
Date 2005-12-01
RFC4302
Location http://www.ietf.org/rfc/rfc4302.txt
Version: 2.27 Page 139 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
IP Encapsulating Security Payload (ESP)
Author(s) S. Kent
Date 2005-12-01
RFC4303
Location http://www.ietf.org/rfc/rfc4303.txt
Extended Sequence Number (ESN) Addendum to IPsec Domain
of Interpretation (DOI) for Internet Security Association and Key
Management Protocol (ISAKMP)
Author(s) S. Kent
Date 2005-12-01
RFC4304
Location http://www.ietf.org/rfc/rfc4304.txt
Cryptographic Algorithms for Use in the Internet Key Exchange
Version 2 (IKEv2)
Author(s) J. Schiller
Date 2005-12-01
RFC4307
Location http://www.ietf.org/rfc/rfc4307.txt
Cryptographic Suites for IPsec
Author(s) P. Hoffman
Date 2005-12-01
RFC4308
Location http://www.ietf.org/rfc/rfc4308.txt
The Secure Shell (SSH) Transport Layer Encryption Modes
Author(s) M. Bellare, T. Kohno, C. Namprempre
Date 2006-01-01
RFC4344
Location http://www.ietf.org/rfc/rfc4344.txt
ECP Groups For IKE and IKEv2
Author(s) D. Fu, J. Solinas
Date 2007-01-01
RFC4753
Location http://www.ietf.org/rfc/rfc4753.txt
IKE and IKEv2 Authentication Using the Elliptic Curve Digital
Signature Algorithm (ECDSA)
Author(s) D. Fu, J. Solinas
Date 2007-01-01
RFC4754
Location http://www.ietf.org/rfc/rfc4754.txt
Requirements for an IPsec Certificate Management Profile
Author(s) C. Bonatti, S. Turner, G. Lebovitz
Date 2007-02-01
RFC4809
Location http://www.ietf.org/rfc/rfc4809.txt
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
Author(s) V. Manral
Date 2007-04-01
RFC4835
Location http://www.ietf.org/rfc/rfc4835.txt
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
RFC4868
Author(s) S. Kelly, S. Frankel
Version: 2.27 Page 140 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Date 2007-05-01
Location http://www.ietf.org/rfc/rfc4868.txt
Suite B Cryptographic Suites for IPsec
Author(s) L. Law, J. Solinas
Date 2007-05-01
RFC4869
Location http://www.ietf.org/rfc/rfc4869.txt
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
Author(s) B. Korver
Date 2007-08-01
RFC4945
Location http://www.ietf.org/rfc/rfc4945.txt
Additional Diffie-Hellman Groups for Use with IETF Standards
Author(s) M. Lepinski, S. Kent
Date 2008-01-01
RFC5114
Location http://www.ietf.org/rfc/rfc5114.txt
The Transport Layer Security (TLS) Protocol Version 1.2
Author(s) T. Dierks, E. Rescorla
Date 2008-08-01
RFC5246
Location http://www.ietf.org/rfc/rfc5246.txt
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
Author(s) D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Date 2008-05-01
RFC5280
Location http://www.ietf.org/rfc/rfc5280.txt
TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
Counter Mode (GCM)
Author(s) E. Rescorla
Date 2008-08-01
RFC5289
Location http://www.ietf.org/rfc/rfc5289.txt
AES Galois Counter Mode for the Secure Shell Transport Layer
Protocol
Author(s) K. Igoe, J. Solinas
Date 2009-08-01
RFC5647
Location http://www.ietf.org/rfc/rfc5647.txt
Elliptic Curve Algorithm Integration in the Secure Shell Transport
Layer
Author(s) D. Stebila, J. Green
Date 2009-12-01
RFC5656
Location http://www.ietf.org/rfc/rfc5656.txt
Internet Key Exchange Protocol Version 2 (IKEv2)
Author(s) C. Kaufman, P. Hoffman, Y. Nir, P. Eronen
Date 2010-09-01
RFC5996
Location http://www.ietf.org/rfc/rfc5996.txt
Version: 2.27 Page 141 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024
IBM Corporation
Security Target for z/OS Version 2 Release 5
Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)
Author(s) P. Saint-Andre, J. Hodges
Date 2011-03-01
RFC6125
Location http://www.ietf.org/rfc/rfc6125.txt
SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport
Layer Protocol
Author(s) D. Bider, M. Baushke
Date 2012-07-01
RFC6668
Location http://www.ietf.org/rfc/rfc6668.txt
X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP
Author(s) S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C.
Adams
Date 2013-06-01
RFC6960
Location http://www.ietf.org/rfc/rfc6960.txt
The Transport Layer Security (TLS) Protocol Version 1.3
Author(s) E. Rescorla
Date 2018-08-01
RFC8446
Location http://www.ietf.org/rfc/rfc8446.txt
z/OS 2.5 TSO/E Customization
Version SA32-0976-50
TSO.CUST
Date September 2022
Version: 2.27 Page 142 of 142
Last update: 2025-06-27 © Copyright IBM Corp. 1994, 2021, 2022, 2023, 2024