Security Target for z/OS Version 2 Release 4
1.3
Version:
RELEASE
Status:
2022-01-10
Last Update:
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 z15
● 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.
Page 2 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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
Changes to Previous Revision
Author(s)
Date
Revision
Public Release.
Author: Mark
Nelson
2022-01-10
1.3
Page 3 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Table of Contents
1 Introduction ............................................................................................... 10
1.1 Security Target Identification ................................................................................... 10
1.2 TOE Identification .................................................................................................... 10
1.3 TOE Type ................................................................................................................. 10
1.4 TOE Overview .......................................................................................................... 10
1.5 TOE Description ....................................................................................................... 11
1.5.1 Intended Method of Use ................................................................................. 12
1.5.2 Summary of Security Features ....................................................................... 12
1.5.2.1 Identification and authentication ........................................................... 13
1.5.2.2 Discretionary access control .................................................................. 13
1.5.2.3 Auditing ................................................................................................. 14
1.5.2.4 Object reuse functionality ...................................................................... 15
1.5.2.5 Security management ............................................................................ 15
1.5.2.6 Communications Security ...................................................................... 15
1.5.2.7 TSF protection ........................................................................................ 16
1.5.2.8 Confidentiality Protection of Data Sets .................................................. 16
1.5.3 Configurations ................................................................................................ 16
1.5.3.1 Software Configuration .......................................................................... 16
1.5.3.2 Hardware Configuration ......................................................................... 17
2 CC Conformance Claim ................................................................................ 19
3 Security Problem Definition ........................................................................ 20
3.1 Construction Rationale ............................................................................................ 20
3.1.1 Information obtained from [GPOSPP] .............................................................. 20
3.1.2 Information obtained from [OSPP] .................................................................. 21
3.1.3 Information from this Security Target ............................................................. 21
3.2 Threat Environment ................................................................................................. 21
3.2.1 Assets ............................................................................................................. 21
3.2.2 Threat agents ................................................................................................. 22
3.2.3 Threats countered by the TOE ........................................................................ 22
3.3 Assumptions ............................................................................................................ 23
3.3.1 Intended usage of the TOE ............................................................................. 23
3.4 Organizational Security Policies .............................................................................. 24
4 Security Objectives .................................................................................... 25
4.1 Objectives for the TOE ............................................................................................ 25
4.2 Objectives for the Operational Environment ........................................................... 26
4.3 Security Objectives Rationale .................................................................................. 27
4.3.1 Security Objectives Coverage ......................................................................... 27
4.3.2 Security Objectives Sufficiency ...................................................................... 28
5 Extended Components Definition ................................................................ 32
5.1 Class FCS: Cryptographic support ........................................................................... 32
5.1.1 TLS Protocol (FCS_TLSC_PLUS) ........................................................................ 32
5.1.1.1 FCS_TLSC_PLUS.1 - TLS Protocol ............................................................ 32
5.1.1.2 FCS_TLSC_PLUS.2 - TLS Protocol ............................................................ 33
5.1.1.3 FCS_TLSC_PLUS.3 - TLS Protocol ............................................................ 34
6 Security Requirements ............................................................................... 35
Page 4 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1 TOE Security Functional Requirements ................................................................... 35
6.1.1 Security audit (FAU) ........................................................................................ 38
6.1.1.1 Audit Data Generation (Refined) (FAU_GEN.1) ...................................... 38
6.1.1.2 User identity association (FAU_GEN.2) .................................................. 39
6.1.1.3 Audit review (FAU_SAR.1) ...................................................................... 39
6.1.1.4 Restricted audit review (FAU_SAR.2) ..................................................... 39
6.1.1.5 Selectable audit review (FAU_SAR.3) .................................................... 39
6.1.1.6 Selective audit (FAU_SEL.1) .................................................................. 39
6.1.1.7 Protected audit trail storage (FAU_STG.1) ............................................. 40
6.1.1.8 Action in case of possible audit data loss (FAU_STG.3) ......................... 40
6.1.1.9 Prevention of audit data loss (FAU_STG.4) ............................................ 40
6.1.2 Cryptographic support (FCS) .......................................................................... 40
6.1.2.1 Cryptographic Key Generation (Refined) (FCS_CKM.1) ......................... 40
6.1.2.2 Cryptographic Key Establishment (Refined) (FCS_CKM.2) ..................... 41
6.1.2.3 Cryptographic Key Destruction (FCS_CKM_EXT.4) ................................. 41
6.1.2.4 Cryptographic Operation - Encryption/Decryption (Refined) (FCS_COP.1(1))
............................................................................................................................. 41
6.1.2.5 Cryptographic Operation - Hashing (Refined) (FCS_COP.1(2)) ............... 42
6.1.2.6 Cryptographic Operation - Signing (Refined) (FCS_COP.1(3)) ................ 42
6.1.2.7 Cryptographic Operation - Keyed-Hash Message Authentication (Refined)
(FCS_COP.1(4)) .................................................................................................... 42
6.1.2.8 Cryptographic operation - IPSec (FCS_COP.1(5)) ................................... 42
6.1.2.9 Random Bit Generation (FCS_RBG_EXT.1) ............................................. 43
6.1.2.10 Storage of Sensitive Data (FCS_STO_EXT.1) ........................................ 43
6.1.2.11 TLS Protocol (FCS_TLSC_PLUS.1) ......................................................... 43
6.1.2.12 TLS Protocol (FCS_TLSC_PLUS.2) ......................................................... 44
6.1.2.13 TLS Protocol (FCS_TLSC_PLUS.3) ......................................................... 44
6.1.2.14 TLS Client Protocol (FCS_TLSC_EXT.4) ................................................. 45
6.1.2.15 SSH Protocol (FCS_SSH_EXT.1) ............................................................ 45
6.1.2.16 SSH Protocol - Client (FCS_SSHC_EXT.1) ............................................. 45
6.1.2.17 SSH Protocol - Server (FCS_SSHS_EXT.1) ............................................ 46
6.1.3 User data protection (FDP) ............................................................................. 46
6.1.3.1 Access Controls for Protecting User Data (FDP_ACF_EXT.1) .................. 46
6.1.3.2 Subset access control: MVS (FDP_ACC.1(PSO-MVS)) ............................. 46
6.1.3.3 Subset access control: UNIX (FDP_ACC.1(PSO-UNIX)) ........................... 46
6.1.3.4 Subset access control (FDP_ACC.1(TSO)) .............................................. 47
6.1.3.5 Security attribute based access control: MVS (FDP_ACF.1(PSO-MVS))
............................................................................................................................. 47
6.1.3.6 Security attribute based access control: UNIX (FDP_ACF.1(PSO-UNIX))
............................................................................................................................. 48
6.1.3.7 Security attribute based access control: UNIX IPC (FDP_ACF.1(TSO))
............................................................................................................................. 49
6.1.3.8 Full residual information protection of resources (FDP_RIP.2) ............... 49
6.1.4 Identification and authentication (FIA) ........................................................... 49
6.1.4.1 Authentication failure handling (Refined) (FIA_AFL.1) ........................... 49
6.1.4.2 User attribute definition (FIA_ATD.1) ..................................................... 49
6.1.4.3 Verification of secrets (FIA_SOS.1) ........................................................ 50
6.1.4.4 Timing of authentication (FIA_UAU.1) ................................................... 50
6.1.4.5 Multiple Authentication Mechanisms (Refined) (FIA_UAU.5) ................. 50
Page 5 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.4.6 Protected authentication feedback (FIA_UAU.7) ................................... 51
6.1.4.7 Timing of identification (FIA_UID.1) ....................................................... 51
6.1.4.8 User-subject binding (FIA_USB.1) .......................................................... 51
6.1.4.9 X.509 Certificate Validation (FIA_X509_EXT.1) ...................................... 52
6.1.4.10 X.509 Certificate Authentication (FIA_X509_EXT.2) ............................. 52
6.1.5 Security management (FMT) .......................................................................... 53
6.1.5.1 Management of security functions behavior (FMT_MOF_EXT.1) ............ 53
6.1.5.2 Specification of Management Functions (FMT_SMF_EXT.1) ................... 53
6.1.5.3 Management of object security attributes (FMT_MSA.1(PSO-MVS)) ...... 53
6.1.5.4 Management of object security attributes (FMT_MSA.1(PSO-UNIX)) ..... 53
6.1.5.5 Management of object security attributes (FMT_MSA.1(TSO)) .............. 54
6.1.5.6 Static attribute initialisation (FMT_MSA.3(PSO-MVS)) ........................... 54
6.1.5.7 Static attribute initialisation (FMT_MSA.3(PSO-UNIX)) .......................... 54
6.1.5.8 Static attribute initialisation (FMT_MSA.3(TSO)) ................................... 54
6.1.5.9 Management of TSF data (FMT_MTD.1) ................................................ 54
6.1.5.10 Security management roles (FMT_SMR.1) ........................................... 54
6.1.6 Protection of the TSF (FPT) ............................................................................. 55
6.1.6.1 Access controls (FPT_ACF_EXT.1) .......................................................... 55
6.1.6.2 Address Space Layout Randomization (FPT_ASLR_EXT.1) ..................... 56
6.1.6.3 Reliable time stamps (FPT_STM.1) ........................................................ 56
6.1.7 TOE access (FTA) ............................................................................................ 56
6.1.7.1 Default TOE access banners (FTA_TAB.1) .............................................. 56
6.1.7.2 TSF-initiated session locking (FTA_SSL.1) ............................................. 56
6.1.7.3 User-initiated locking (FTA_SSL.2) ......................................................... 56
6.1.8 Trusted path/channels (FTP) ........................................................................... 57
6.1.8.1 Trusted channel communication (FTP_ITC_EXT.1) ................................. 57
6.1.8.2 Trusted channel communication (IPSec) (FTP_ITC.1) ............................. 57
6.1.8.3 Trusted Path (Refined) (FTP_TRP.1) ........................................................ 57
6.2 Security Functional Requirements Rationale ........................................................... 57
6.2.1 Security Requirements Coverage ................................................................... 57
6.2.2 Security Requirements Sufficiency ................................................................. 60
6.2.3 Security Requirements Dependency Analysis ................................................. 62
6.3 Security Assurance Requirements ........................................................................... 65
6.4 Security Assurance Requirements Rationale ........................................................... 65
7 TOE Summary Specification ........................................................................ 66
7.1 Mapping SFR to TSS ................................................................................................ 66
7.2 TOE Security Functionality ...................................................................................... 68
7.2.1 z/OS Basic Principles ....................................................................................... 68
7.2.1.1 Hardware Platform ................................................................................. 68
7.2.1.2 System Initialization (IPL) ....................................................................... 69
7.2.1.3 Address Spaces in z/OS .......................................................................... 70
7.2.1.4 System Call Interface ............................................................................. 70
7.2.1.5 Subjects ................................................................................................. 71
7.2.1.6 Security Services ................................................................................... 71
7.2.1.7 User interaction with z/OS ..................................................................... 71
7.2.1.8 Persistent Storage .................................................................................. 71
7.2.1.9 Authorized Programs .............................................................................. 71
7.2.2 Security Functionality ..................................................................................... 73
Page 6 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
7.2.2.1 Identification and Authentication (FIA, FTA) ........................................... 73
7.2.2.2 Authentication Functions ....................................................................... 74
7.2.2.3 Access Control (FDP) .............................................................................. 82
7.2.2.4 Audit (FAU) ............................................................................................. 98
7.2.2.5 Cryptographic Functions (FCS) ............................................................. 100
7.2.2.6 Security Management (FMT) ................................................................ 104
7.2.2.7 Object Re-Use (FDP_RIP) ...................................................................... 111
7.2.2.8 Self Protection ...................................................................................... 111
7.2.2.9 Communication Security ...................................................................... 112
7.2.2.10 Confidentiality Protection of Data Sets .............................................. 117
8 Abbreviations, Terminology and References .............................................. 119
8.1 Abbreviations ........................................................................................................ 119
8.2 Terminology ........................................................................................................... 120
8.3 References ............................................................................................................ 123
Page 7 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
List of Tables
Table 1: Mapping of security objectives to threats and policies ....................................... 27
Table 2: Mapping of security objectives for the Operational Environment to assumptions,
threats and policies ................................................................................................... 27
Table 3: Sufficiency of objectives countering threats ....................................................... 28
Table 4: Sufficiency of objectives holding assumptions ................................................... 29
Table 5: Sufficiency of objectives enforcing Organizational Security Policies ................... 30
Table 6: SFRs for the TOE ................................................................................................. 35
Table 7: Mapping of security functional requirements to security objectives ................... 58
Table 8: Security objectives for the TOE rationale ........................................................... 60
Table 9: TOE SFR dependency analysis ............................................................................ 62
Table 10: Data Set Profile Structure and Content ........................................................... 108
Page 8 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
List of Figures
Figure 1: RACF Request Flow ............................................................................................ 82
Page 9 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
1 Introduction
1.1 Security Target Identification
Security Target for z/OS Version 2 Release 4
Title:
1.3
Version:
RELEASE
Status:
2022-01-10
Date:
Mark Nelson, IBM
Author:
IBM Corporation
Sponsor:
IBM Corporation
Developer:
OCSI
Certification Body:
OCSI/CERT/ATS/03/2020
Certification ID:
operating system, access control, identification, authentication, audit, object
reuse
Keywords:
1.2 TOE Identification
The TOE is IBM z/OS Version 2 Release 4.
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
4 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, 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.
Page 10 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 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 z15).
● a certified version of z/VM® executing in a logical partition provided by PR/SM on one
of the above-listed z System™ processors.
Most of the abstract machine itself is not part of the TOE, rather, it belongs to the TOE
environment. Nevertheless the correctness of separation and memory protection mechanisms
implemented in the abstract machine is analyzed as part of the evaluation since those functions
are crucial for the security of the TOE.
Cryptographic functions implemented by the CEX7S coprocessors are part of the TOE environment
and therefore have not been evaluated to the degree required by the target assurance level. It
should be noted, that a cryptographic coprocessor is required to operate the TOE in its evaluated
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.
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.
Page 11 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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
Page 12 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● auditing
● object reuse
● security management
● secure communication
● 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 X.509v3 digital certificate presented to a server application that uses System SSL or
TCP/IP Application Transparent TLS (AT-TLS) to provide TLS-based client authentication,
and then “mapped” (using TOE functions) by that server application or by AT-TLS to a
RACF user ID.
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 required 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.
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.
z/OS provides three 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.)
Page 13 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.
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.
Page 14 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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, 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 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.
Page 15 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
1.5.2.7 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.
1.5.2.8 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 4, consists of:
● IBM z/OS Version 2 Release 4 (V2R4) Common Criteria Evaluated Base Package:
❍ IBM z/OS Version 2 Release 4 (z/OS V2R4, program number 5650-ZOS),
● The following APARs (or their associated PTFs):
❍ OA57641 (UJ02099)
❍ OA57934 (UJ00393)
❍ OA58067 (UJ02223)
❍ OA58074 (UJ02931)
❍ OA58282 (UJ01931)
❍ OA58313 (UJ02442)
Page 16 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
❍ OA58349 (UJ02614)
❍ OA58505 (UJ01875)
❍ OA58588 (UJ01732)
❍ OA58595 (UJ01957)
❍ OA58781 (UJ01929 & UJ01933)
❍ OA58990 (UJ02368 & UJ02370)
❍ OA59021 (UJ02052)
❍ OA59040 (UJ02630)
❍ OA59074 (UJ02508 & UJ02509)
❍ OA59156 (UJ02505)
❍ OA59268 (UJ02740 & UJ02741)
❍ PH14146 (UI68531)
❍ PH14509 (UI66980)
❍ PH14511 (UI67180)
The z/OS V2R4 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 within a logical partition provided by a certified version of
z/VM® executing in a logical partition provided by PR/SM on one of the following z System™
processors:
● IBM z15 with CPACF DES/TDES Enablement Feature 3863 active, with Crypto Express7S
cards.
Note that the CryptoExpress cards are not part of the TOE and therefore the implementation of
the cryptographic functions provided by those cards are not analyzed as required by the assurance
level of the evaluation. Testing has been performed using those cards to ensure that the
cryptographic functions provided by those cards work in principle. No vulnerability analysis or
side channel analysis for those cryptographic functions has been performed. The claims made
in this Security Target concerning the cryptographic functions therefore apply to those functions
implemented in software or by CPACF.
In addition, the TOE may run on a virtual machine provided by a certified version of z/VM.
The following peripherals can be used with the TOE, while still preserving the security functionality:
● All terminals that are supported by the TOE.
● Printers:
❍ 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.
Page 17 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 18 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 19 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.2.1"
[GPOSPP]
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.
Note: The following should be considered:
● [GPOSPP] 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.
3.1.1 Information obtained from [GPOSPP]
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
● O.PROTECTED_COMMS
Objectives for the Environment
● OE.PLATFORM
● OE.PROPER_USER
● OE.PROPER_ADMIN
Page 20 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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
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
Page 21 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
❍ 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.
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.
Page 22 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.
Page 23 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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
Authority shall only be given to users who are trusted to perform the actions correctly.
Page 24 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 25 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 26 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
4.3 Security Objectives Rationale
4.3.1 Security Objectives Coverage
The following table provides a mapping of TOE objectives to threats and policies, showing that
each objective counters or enforces at least one threat or policy, respectively.
Threats / OSPs
Objective
T.NETWORK_ATTACK
T.LOCAL_ATTACK
P.ACCOUNTABILITY
O.ACCOUNTABILITY
T.NETWORK_ATTACK
T.LOCAL_ATTACK
O.INTEGRITY
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.MANAGEMENT
T.LIMITED_PHYSICAL_ACCESS
T.ACCESS.CP.USERDATA
O.PROTECTED_STORAGE
T.NETWORK_ATTACK
T.NETWORK_EAVESDROP
O.PROTECTED_COMMS
P.ACCOUNTABILITY
O.AUDITING
T.ACCESS.TSFDATA
T.ACCESS.USERDATA
T.ACCESS.TSFFUNC
O.DISCRETIONARY
.ACCESS
T.IA.MASQUERADE
T.IA.USER
O.IA
T.IA.MASQUERADE
T.IA.USER
O.IA.MULTIPLE
Table 1: Mapping of security objectives to threats and policies
The following table provides a mapping of the objectives for the Operational Environment to
assumptions, threats and policies, showing that each objective holds, counters or enforces at
least one assumption, threat or policy, respectively.
Assumptions / Threats / OSPs
Objective
A.PLATFORM
OE.PLATFORM
A.PROPER_USER
OE.PROPER_USER
A.PROPER_ADMIN
OE.PROPER_ADMIN
A.CONNECT
OE.REMOTE
Page 27 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Assumptions / Threats / OSPs
Objective
A.PHYSICAL
OE.PHYSICAL
A.PROPER_ADMIN
OE.RECOVER
A.PEER.MGT
A.PEER.FUNC
A.CONNECT
OE.TRUSTED.IT.SYSTEM
Table 2: Mapping of security objectives for the Operational Environment to
assumptions, threats and policies
4.3.2 Security Objectives Sufficiency
The following rationale provides justification that the security objectives are suitable to counter
each individual threat and that each security objective tracing back to a threat, when achieved,
actually contributes to the removal, diminishing or mitigation of that threat.
Rationale for security objectives
Threat
The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS
as this provides for integrity of transmitted data.
T.NETWORK_ATTACK
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.
The threat T.NETWORK_EAVESDROP is countered by
O.PROTECTED_COMMS as this provides for confidentiality of transmitted
data.
T.NETWORK_EAVESDROP
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.
The objective O.INTEGRITY protects against the use of mechanisms
that weaken the TOE with regard to attack by other software on the
platform.
T.LOCAL_ATTACK
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.
The objective O.PROTECTED_STORAGE protects against unauthorized
attempts to access physical storage used by the TOE.
T.LIMITED_PHYSICAL_ACCESS
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
T.ACCESS.TSFDATA
Page 28 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Rationale for security objectives
Threat
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.
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
T.ACCESS.USERDATA
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.
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
T.ACCESS.TSFFUNC
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.
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
T.IA.MASQUERADE
(O.IA.MULTIPLE). It is also addressed by O.MANAGEMENT requiring to
manage the users including their identities and authentication
credentials.
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
T.IA.USER
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.
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.
T.ACCESS.CP.USERDATA
Table 3: Sufficiency of objectives countering threats
The following rationale provides justification that the security objectives for the environment
are suitable to cover each individual assumption, that each security objective for the environment
that traces back to an assumption about the environment of use of the TOE, when achieved,
actually contributes to the environment achieving consistency with the assumption, and that if
all security objectives for the environment that trace back to an assumption are achieved, the
intended usage is supported.
Rationale for security objectives
Assumption
The operational environment objective OE.PLATFORM is realized
through A.PLATFORM.
A.PLATFORM
Page 29 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Rationale for security objectives
Assumption
The operational environment objective OE.PROPER_USER is realized
through A.PROPER_USER.
A.PROPER_USER
The operational environment objective OE.PROPER_ADMIN is realized
through A.PROPER_ADMIN.
A.PROPER_ADMIN
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.
A.PHYSICAL
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
A.PEER.MGT
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.
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
A.PEER.FUNC
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.
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
A.CONNECT
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.
Table 4: Sufficiency of objectives holding assumptions
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.
Rationale for security objectives
OSP
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
P.ACCOUNTABILITY
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.
Page 30 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Rationale for security objectives
OSP
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.
P.USER
Table 5: Sufficiency of objectives enforcing Organizational Security Policies
Page 31 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 [GPOSPP]. 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_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 protcols
as well as the supported ciphers.
Component levelling
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.3 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.3
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.3
There are no audit events foreseen.
5.1.1.1 FCS_TLSC_PLUS.1 - TLS Protocol
No other components.
Hierarchical to:
No dependencies.
Dependencies:
The OS shall implement [selection:
FCS_TLSC_PLUS.1.1
● TLS 1.2 ([RFC5246]☝) supporting the following cipher suites:
[selection:
❍ TLS_RSA_WITH_AES_128_CBC_SHA as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_256_CBC_SHA as defined in [RFC5246]☝
Page 32 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
❍ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in [RFC5288]☝
❍ TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in [RFC5288]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
[RFC5289]☝
❍ 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_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝
]
● TLS 1.3 ([RFC8446]☝) supporting the following cipher suites:
[selection:
❍ TLS_AES_128_GCM_SHA256 as defined in [RFC8446]☝
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]☝
]
].
The OS shall verify that the presented identifier matches the reference
identifier according to [selection:
FCS_TLSC_PLUS.1.2
● [RFC6125]☝
● no RFC
].
The OS shall only establish a trusted channel if the peer certificate
is valid.
FCS_TLSC_PLUS.1.3
Rationale
This component is used to provide choice for cipher suites, certificate validation and TLS protocol
versions.
5.1.1.2 FCS_TLSC_PLUS.2 - TLS Protocol
No other components.
Hierarchical to:
No dependencies.
Dependencies:
The OS shall [selection:
FCS_TLSC_PLUS.2.1
● for TLS 1.2 present the Supported Groups (Elliptic Curves)
Extension in the Client Hello with the following supported groups:
[selection:
Page 33 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
secp256r1
❍
❍ secp384r1
❍ secp521r1
]
● for TLS 1.3 support the following key exchange modes: ECDHE
with the following key shares: [selection:
❍ secp256r1
❍ secp384r1
❍ secp521r1
]
].
Rationale
This component is used to provide choice for key exchange mechanisms as well as TLS protocol
versions.
5.1.1.3 FCS_TLSC_PLUS.3 - TLS Protocol
No other components.
Hierarchical to:
No dependencies.
Dependencies:
The OS shall [selection:
FCS_TLSC_EXT
.3.1
● for TLS 1.2 present the signature_algorithms extension in the
Client Hello with the supported_signature_algorithms value
containing the following hash algorithms: [selection:
❍ SHA256
❍ SHA384
❍ SHA512
] and no other hash algorithms.
● for TLS 1.3 support the following signature algorithms as defined
in [RFC8446]☝, section 4.2.3: [selection:
❍ RSA_PKCS1_SHA256 as defined in [FIPS186-4]☝
❍ RSA_PKCS1_SHA384 as defined in [FIPS186-4]☝
❍ RSA_PKCS1_SHA512 as defined in [FIPS186-4]☝
❍ ECDSA_SECP256R1_SHA256 as defined in [FIPS186-4]☝
❍ ECDSA_SECP384R1_SHA384 as defined in [FIPS186-4]☝
❍ ECDSA_SECP521R1_SHA512 as defined in [FIPS186-4]☝
❍ RSA_PSS_RSAE_SHA256 as defined in [RFC8017]☝
❍ RSA_PSS_RSAE_SHA384 as defined in [RFC8017]☝
❍ RSA_PSS_RSAE_SHA512 as defined in [RFC8017]☝
]
].
Rationale
This component is used to provide choice for signature algorithms as well as TLS protocol versions.
Page 34 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.2.1"
[GPOSPP] - SFRs were reproduced unmodified from this PP 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.
All of the extended requirements in this ST have been drawn from the [GPOSPP]. The
[GPOSPP] defines the following extended requirements and since they are not redefined
in this ST, the [GPOSPP] should thus be consulted for more information in regard to
those CC extensions.
Finally, the SFRs originating from [GPOSPP], are distinguishable from CC Part 2 SFRs by
the ending _EXT or having the term (Refined) appended.
● 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.
Operations
Source
Base
security
functional
component
Security functional
requirement
Security
functional class
Sel.
Ass.
Ref.
Iter.
Yes
Yes
No
No
FAU_GEN.1 Audit Data
Generation (Refined)
FAU - Security
audit
No
No
No
No
CC Part 2
FAU_GEN.2 User identity
association
No
Yes
No
No
CC Part 2
FAU_SAR.1 Audit review
No
No
No
No
CC Part 2
FAU_SAR.2 Restricted audit
review
No
Yes
No
No
CC Part 2
FAU_SAR.3 Selectable audit
review
Yes
Yes
No
No
CC Part 2
FAU_SEL.1 Selective audit
Yes
No
No
No
CC Part 2
FAU_STG.1 Protected audit trail
storage
No
Yes
No
No
CC Part 2
FAU_STG.3 Action in case of
possible audit data loss
Yes
Yes
Yes
No
CC Part 2
FAU_STG.4 Prevention of audit
data loss
Page 35 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Operations
Source
Base
security
functional
component
Security functional
requirement
Security
functional class
Sel.
Ass.
Ref.
Iter.
Yes
No
No
No
FCS_CKM.1 Cryptographic Key
Generation (Refined)
FCS -
Cryptographic
support
Yes
No
No
No
FCS_CKM.2 Cryptographic Key
Establishment (Refined)
Yes
Yes
No
No
FCS_CKM_EXT.4 Cryptographic
Key Destruction
Yes
No
No
Yes
FCS_COP.1
FCS_COP.1(1) Cryptographic
Operation -
Encryption/Decryption (Refined)
Yes
No
No
Yes
FCS_COP.1
FCS_COP.1(2) Cryptographic
Operation - Hashing (Refined)
Yes
No
No
Yes
FCS_COP.1
FCS_COP.1(3) Cryptographic
Operation - Signing (Refined)
Yes
Yes
No
Yes
FCS_COP.1
FCS_COP.1(4) Cryptographic
Operation - Keyed-Hash Message
Authentication (Refined)
No
Yes
Yes
Yes
CC Part 2
FCS_COP.1
FCS_COP.1(5) Cryptographic
operation - IPSec
Yes
No
No
No
FCS_RBG_EXT.1 Random Bit
Generation
No
No
No
No
FCS_STO_EXT.1 Storage of
Sensitive Data
Yes
No
No
No
ECD
FCS_TLSC_PLUS.1 TLS Protocol
Yes
No
No
No
ECD
FCS_TLSC_PLUS.2 TLS Protocol
Yes
No
No
No
ECD
FCS_TLSC_PLUS.3 TLS Protocol
No
No
No
No
FCS_TLSC_EXT.4 TLS Client
Protocol
Yes
No
No
No
FCS_SSH_EXT.1 SSH Protocol
Yes
Yes
Yes
No
FCS_SSHC_EXT.1 SSH Protocol -
Client
Yes
Yes
No
No
FCS_SSHS_EXT.1 SSH Protocol -
Server
No
No
No
No
FDP_ACF_EXT.1 Access Controls
for Protecting User Data
FDP - User data
protection
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(PSO-MVS) Subset
access control: MVS
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(PSO-UNIX) Subset
access control: UNIX
Page 36 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Operations
Source
Base
security
functional
component
Security functional
requirement
Security
functional class
Sel.
Ass.
Ref.
Iter.
No
Yes
No
Yes
CC Part 2
FDP_ACC.1
FDP_ACC.1(TSO) Subset access
control
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(PSO-MVS) Security
attribute based access control:
MVS
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(PSO-UNIX) Security
attribute based access control:
UNIX
No
Yes
No
Yes
CC Part 2
FDP_ACF.1
FDP_ACF.1(TSO) Security
attribute based access control:
UNIX IPC
Yes
No
No
No
CC Part 2
FDP_RIP.2 Full residual
information protection of
resources
Yes
Yes
No
No
FIA_AFL.1 Authentication failure
handling (Refined)
FIA - Identification
and
authentication
No
Yes
Yes
No
CC Part 2
FIA_ATD.1
FIA_ATD.1 User attribute
definition
No
Yes
No
No
CC Part 2
FIA_SOS.1 Verification of secrets
No
Yes
No
No
CC Part 2
FIA_UAU.1 Timing of
authentication
Yes
Yes
No
No
FIA_UAU.5 Multiple
Authentication Mechanisms
(Refined)
No
Yes
No
No
CC Part 2
FIA_UAU.7 Protected
authentication feedback
No
Yes
No
No
CC Part 2
FIA_UID.1 Timing of identification
No
Yes
No
No
CC Part 2
FIA_USB.1 User-subject binding
Yes
No
No
No
FIA_X509_EXT.1 X.509 Certificate
Validation
Yes
No
No
No
FIA_X509_EXT.2 X.509 Certificate
Authentication
No
No
Yes
No
FMT_MOF_EXT.1 Management of
security functions behavior
FMT - Security
management
Yes
No
No
No
FMT_SMF_EXT.1 Specification of
Management Functions
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.1
FMT_MSA.1(PSO-MVS)
Management of object security
attributes
Page 37 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Operations
Source
Base
security
functional
component
Security functional
requirement
Security
functional class
Sel.
Ass.
Ref.
Iter.
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.1
FMT_MSA.1(PSO-UNIX)
Management of object security
attributes
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.1
FMT_MSA.1(TSO) Management
of object security attributes
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(PSO-MVS) Static
attribute initialisation
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(PSO-UNIX) Static
attribute initialisation
Yes
Yes
No
Yes
CC Part 2
FMT_MSA.3
FMT_MSA.3(TSO) Static attribute
initialisation
Yes
Yes
No
No
CC Part 2
FMT_MTD.1
FMT_MTD.1 Management of TSF
data
No
Yes
No
No
CC Part 2
FMT_SMR.1 Security
management roles
No
Yes
No
No
FPT_ACF_EXT.1 Access controls
FPT - Protection of
the TSF
Yes
Yes
No
No
FPT_ASLR_EXT.1 Address Space
Layout Randomization
No
No
No
No
CC Part 2
FPT_STM.1 Reliable time stamps
No
No
No
No
CC Part 2
FTA_TAB.1 Default TOE access
banners
FTA - TOE access
No
Yes
No
No
CC Part 2
FTA_SSL.1 TSF-initiated session
locking
No
Yes
No
No
CC Part 2
FTA_SSL.2 User-initiated locking
Yes
Yes
Yes
No
FTP_ITC_EXT.1 Trusted channel
communication
FTP - Trusted
path/channels
Yes
Yes
Yes
No
CC Part 2
FTP_ITC.1 Trusted channel
communication (IPSec)
Yes
No
No
No
FTP_TRP.1 Trusted Path (Refined)
Table 6: SFRs for the TOE
6.1.1 Security audit (FAU)
6.1.1.1 Audit Data Generation (Refined) (FAU_GEN.1)
The OS shall be able to generate an audit record of the following auditable
events:
FAU_GEN.1.1
a) Start-up and shut-down of the audit functions;
b) All auditable events for the [not specified] level of audit; and [
Page 38 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
c) 1. Authentication events (Success/Failure);
2. Use of privileged/special rights events (Successful and unsuccessful
security, audit, and configuration changes);
3. Privilege or role escalation events (Success/Failure);
4. 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), System
reboot, restart, and shutdown events (Success/Failure),
Administrator or root-level access events (Success/Failure)
].
The OS shall record within each audit record at least the following information:
FAU_GEN.1.2
a) Date and time of the event, type of event, subject identity (if applicable),
and 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 User identity association (FAU_GEN.2)
For audit events resulting from actions of identified users, the TSF shall be
able to associate each auditable event with the identity of the user that caused
the event.
FAU_GEN.2.1
6.1.1.3 Audit review (FAU_SAR.1)
The TSF shall provide the authorized administrators with the capability to
read all audit information from the audit records.
FAU_SAR.1.1
The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
FAU_SAR.1.2
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 Restricted audit review (FAU_SAR.2)
The TSF shall prohibit all users read access to the audit records, except those
users that have been granted explicit read-access.
FAU_SAR.2.1
6.1.1.5 Selectable audit review (FAU_SAR.3)
The TSF shall provide the ability to apply searches of audit data based on
the following attributes:
FAU_SAR.3.1
a) user identity;
b) object type and object name;
6.1.1.6 Selective audit (FAU_SEL.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:
FAU_SEL.1.1
a) user identity
Page 39 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
b) 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 Protected audit trail storage (FAU_STG.1)
The TSF shall protect the stored audit records in the audit trail from
unauthorised deletion.
FAU_STG.1.1
The TSF shall be able to prevent unauthorised modifications to the audit
records in the audit trail.
FAU_STG.1.2
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 Action in case of possible audit data loss (FAU_STG.3)
The TSF shall generate an alarm to the z/OS operator if the audit trail
exceeds the capacity of the current SMF data set.
FAU_STG.3.1
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 Prevention of audit data loss (FAU_STG.4)
The TSF shall prevent audited events, except those taken by the
authorised user with special rightsauthorized administrator and inform
a z/OS operator if the audit trail is full.
FAU_STG.4.1
6.1.2 Cryptographic support (FCS)
6.1.2.1 Cryptographic Key Generation (Refined) (FCS_CKM.1)
The OS shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm
FCS_CKM.1.1
● RSA schemes using cryptographic key sizes of 2048-bit or greater
that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS)", Appendix B.3
● ECC schemes using "NIST curves" P-256, P-384 and P-521 that
meet the following: FIPS PUB 186-4, "Digital Signature Standard
(DSS)", Appendix B.4
● FFC schemes using cryptographic key sizes of 2048-bit or greater
that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS)", Appendix B.1.
Page 40 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.2.2 Cryptographic Key Establishment (Refined) (FCS_CKM.2)
The OS shall implement functionality to perform cryptographic key
establishment in accordance with a specified cryptographic key establishment
method:
[RSA-based key establishment schemes] that meets the following: [NIST Special
Publication 800-56B, "Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography"]
FCS_CKM.2.1
and
● Elliptic curve-based key establishment schemes that meets the
following: NIST Special Publication 800-56A, "Recommendation
for Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography",
● Finite field-based key establishment schemes that meets the
following: NIST Special Publication 800-56A, "Recommendation
for Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography".
6.1.2.3 Cryptographic Key Destruction (FCS_CKM_EXT.4)
The OS shall destroy cryptographic keys and key material in accordance with
a specified cryptographic key destruction method
FCS_CKM_EXT.4.1
● For volatile memory, the destruction shall be executed by a
❍ single overwrite consisting of zeroes , a new value of a key
● For non-volatile memory that consists of the invocation of an
interface provided by the underlying platform that
❍ logically addresses the storage location of the key and
performs a single overwrite consisting of zeroes, a new value
of a key of the same size
❍ instructs the underlying platform to destroy the abstraction
that represents the key
that meets the following: vendor-specific key destruction methods as
described above.
The OS shall destroy all keys and key material when no longer needed.
FCS_CKM_EXT.4.2
6.1.2.4 Cryptographic Operation - Encryption/Decryption (Refined)
(FCS_COP.1(1))
The OS shall perform [encryption/decryption services for data] in accordance
with a specified cryptographic algorithm
FCS_COP.1.1-1
● AES-XTS (as defined in NIST SP 800-38E)
● AES-CBC (as defined in NIST SP 800-38A)
and
● AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE
802.11-2012)
● AES-GCM (as defined in NIST SP 800-38D)
● AES-GCMP-256 (as defined in NIST SP800-38D and IEEE
802.11ac-2013)
and cryptographic key sizes 128-bit , 256-bit .
Page 41 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.2.5 Cryptographic Operation - Hashing (Refined) (FCS_COP.1(2))
The OS shall perform [cryptographic hashing services] in accordance with a
specified cryptographic algorithm [SHA-1 and
FCS_COP.1.1-2
● SHA-256
● SHA-384
● SHA-512
] and message digest sizes 160 bits and
● 256 bits
● 384 bits
● 512 bits
that meet the following: [FIPS Pub 180-4].
6.1.2.6 Cryptographic Operation - Signing (Refined) (FCS_COP.1(3))
The OS shall perform [cryptographic signature services (generation and
verification)] in accordance with a specified cryptographic algorithm
FCS_COP.1.1-3
● RSA schemes using cryptographic key sizes of 2048-bit or greater
that meet the following: FIPS PUB 186-4, "Digital Signature
Standard (DSS)", Section 4
● ECDSA schemes using "NIST curves" P-256, P-384 and P-521 that
meet the following: FIPS PUB 186-4, "Digital Signature Standard
(DSS)", Section 5
.
6.1.2.7 Cryptographic Operation - Keyed-Hash Message Authentication
(Refined) (FCS_COP.1(4))
The OS shall perform [keyed-hash message authentication services] in
accordance with a specified cryptographic algorithm SHA-1, SHA-256,
SHA-384 with key sizes 80 to 2048 bit and message digest sizes 160 bits,
256 bits, 384 bits that meet the following: [FIPS Pub 198-1 The Keyed-Hash
Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard].
FCS_COP.1.1-4
Application Note:
The HMAC key is generated by the ‘KeyGenerate2’ (CSNBKGN1) function of ICSF which allows
for key sizes between 80 and 2048 bit. The HMAC generation with such a key is provided by the
‘HMAC Generate’ (CSNBHMG or CSNBHMG1) function of ICSF. Supported hash functions include
the ones mentioned in the SFR as well as SHA-512. System SSL generated HMACs during TLS
processing.
6.1.2.8 Cryptographic operation - IPSec (FCS_COP.1(5))
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:
FCS_COP.1.1
a) IPSec with IKE allowing the use of AES in CTR mode with 128 bits
and 256 bits key size, and SHA-1 defined by [RFC4301]☝ and
[RFC4303]☝
Page 42 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
b) IPSec with IKE allowing the use of AES in CBC mode with 128 bits
or 256 bits key size, and either SHA-1, SHA-2, AES_GMAC or
AES_XCBC_MAC_96 as defined by [RFC4301]☝, [RFC4303]☝,
[RFC3602]☝, [RFC4106]☝, [RFC2404]☝, and [RFC4868]☝
c) IPSec allowing the use of HMAC-SHA-1 for message authentication,
cryptographically securing the payload and the authentication
header of an IP packet as defined in IETF [RFC4303]☝ (IP
Encapsulating Security Payload [ESP]) and IETF [RFC4302]☝ (IP
Authentication Header) using the specific method for HMAC-SHA-1
as defined in IETF [RFC2404]☝ (The Use of HMAC-SHA-1-96 within
ESP and AH)
d) IPSec allowing the use of AES in GCM mode with 128 bits and 256
bits key size for combined encryption and authentication as
defined by [RFC4301]☝, [RFC4303]☝, [RFC3602]☝, [RFC4106]☝,
[RFC2404]☝, and [RFC4868]☝
6.1.2.9 Random Bit Generation (FCS_RBG_EXT.1)
The OS shall perform all deterministic random bit generation (DRBG) services
in accordance with NIST Special Publication 800-90A using
FCS_RBG_EXT.1.1
● Hash_DRBG (any)
.
The deterministic RBG used by the OS shall be seeded by an entropy source
that accumulates entropy from a
FCS_RBG_EXT.1.2
● 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.
6.1.2.10 Storage of Sensitive Data (FCS_STO_EXT.1)
The OS shall implement functionality to encrypt sensitive data stored in
non-volatile storage and provide interfaces to applications to invoke this
functionality.
FCS_STO_EXT.1.1
6.1.2.11 TLS Protocol (FCS_TLSC_PLUS.1)
The OS shall implement
FCS_TLSC_PLUS.1.1
● TLS 1.2 ([RFC5246]☝) supporting the following cipher suites:
❍ TLS_RSA_WITH_AES_128_CBC_SHA as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_256_CBC_SHA as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in [RFC5246]☝
❍ TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in [RFC5288]☝
❍ TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in [RFC5288]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in
[RFC5289]☝
Page 43 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
❍ 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_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in
[RFC5289]☝
❍ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
[RFC5289]☝
● TLS 1.3 ([RFC8446]☝) supporting the following cipher suites:
❍ TLS_AES_128_GCM_SHA256 as defined in [RFC8446]
❍ TLS_AES_256_GCM_SHA384 as defined in [RFC8446]
.
The OS shall verify that the presented identifier matches the reference identifier
according to no RFC.
FCS_TLSC_PLUS.1.2
The OS shall only establish a trusted channel if the peer certificate is valid.
FCS_TLSC_PLUS.1.3
6.1.2.12 TLS Protocol (FCS_TLSC_PLUS.2)
The OS shall
FCS_TLSC_PLUS.2.1
● for TLS 1.2 present the Supported Groups (Elliptic Curve)
Extension in the Client Hello with the following supported groups:
❍ secp256r1
❍ secp384r1
❍ secp521r1
● for TLS 1.3 support the following key exchange modes: ECDHE
with the following key shares:
❍ secp256r1
❍ secp384r1
❍ secp521r1
.
6.1.2.13 TLS Protocol (FCS_TLSC_PLUS.3)
The OS shall
FCS_TLSC_PLUS.3.1
● for TLS 1.2 present the signature_algorithms extension in the
Client Hello with the supported_signature_algorithms value
containing the following hash algorithms:
❍ SHA256
❍ SHA384
❍ SHA512
and no other hash algorithms
● for TLS 1.3 support the following signature algorithms as defined
in [RFC8446]☝, section 4.2.3:
Page 44 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
RSA_PKCS1_SHA256 as defined in [FIPS186-4]☝
❍
❍ RSA_PKCS1_SHA384 as defined in [FIPS186-4]☝
❍ RSA_PKCS1_SHA512 as defined in [FIPS186-4]☝
❍ ECDSA_SECP256R1_SHA256 as defined in [FIPS186-4]☝
❍ ECDSA_SECP384R1_SHA384 as defined in [FIPS186-4]☝
❍ ECDSA_SECP521R1_SHA512 as defined in [FIPS186-4]☝
❍ RSA_PSS_RSAE_SHA256 as defined in [RFC8017]☝
❍ RSA_PSS_RSAE_SHA384 as defined in [RFC8017]☝
❍ RSA_PSS_RSAE_SHA512 as defined in [RFC8017]☝
.
6.1.2.14 TLS Client Protocol (FCS_TLSC_EXT.4)
The OS shall support mutual authentication using X.509v3 certificates.
FCS_TLSC_EXT
.4.1
6.1.2.15 SSH Protocol (FCS_SSH_EXT.1)
The SSH software shall implement the SSH protocol that complies with RFCs
4251, 4252, 4253, 4254 and 5647, 5656, no other RFCs as a client, server
FCS_SSH_EXT.1.1
Application Note: Supported RFCs are: [RFC4251]☝, [RFC4252]☝, [RFC4253]☝, [RFC4253]☝,
[RFC5647]☝ and [RFC5656]☝.
6.1.2.16 SSH Protocol - Client (FCS_SSHC_EXT.1)
The SSH client shall ensure that the SSH protocol implementation supports
the following authentication methods as described in [RFC4252]☝: public
key-based, and password-based.
FCS_SSHC_EXT
.1.1
The SSH client shall ensure that, as described in [RFC4253]☝, packets greater
than 262144 bytes in an SSH transport connection are dropped.
FCS_SSHC_EXT
.1.2
The SSH software shall ensure that the SSH transport implementation uses
the following encryption algorithms and rejects all other encryption algorithms:
aes128-ctr, aes256-ctr, aes128-cbc, aes256-cbc, AEAD_AES_128_GCM,
AEAD_AES_256_GCM.
FCS_SSHC_EXT
.1.3
The SSH client shall ensure that the SSH transport implementation uses
ssh-rsa, ecdsa-sha2-nistp256 and ecdsa-sha2-nistp384 as its public key
algorithm(s) and rejects all other public key algorithms.
FCS_SSHC_EXT
.1.4
The SSH client shall ensure that the SSH transport implementation uses
hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512 and
AEAD_AES_128_GCM, AEAD_AES_256_GCMas its data integrity MAC
algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHC_EXT
.1.5
The SSH client shall ensure that diffie-hellman-group14-sha1,
ecdh-sha2-nistp256 and ecdh-sha2-nistp384, ecdh-sha2-nistp521 are
the only allowed key exchange methods used for the SSH protocol.
FCS_SSHC_EXT
.1.6
The SSH server client shall ensure that the SSH connection be rekeyed after
no more than 2
28
packets have been transmitted using that key.
FCS_SSHC_EXT
.1.7
The SSH client shall ensure that the SSH client authenticates the identity of
the SSH server using a local database associating each host name with its
corresponding public key or a list of trusted certification authorities as
described in [RFC4251]☝ section 4.1.
FCS_SSHC_EXT
.1.8
Page 45 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.2.17 SSH Protocol - Server (FCS_SSHS_EXT.1)
The SSH server shall ensure that the SSH protocol implementation supports
the following authentication methods as described in [RFC4252]☝: public
key-based, and password-based.
FCS_SSHS_EXT
.1.1
The SSH server shall ensure that, as described in [RFC4253]☝, packets greater
than 262144 bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT
.1.2
The SSH server shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption algorithms:
aes128-ctr, aes256-ctr, aes128-cbc, aes256-cbc, AEAD_AES_128_GCM,
AEAD_AES_256_GCM .
FCS_SSHS_EXT
.1.3
The SSH server shall ensure that the SSH transport implementation uses
ssh-rsa, ecdsa-sha2-nistp256 and ecdsa-sha2-nistp384 as its public key
algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT
.1.4
The SSH server shall ensure that the SSH transport implementation uses
hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512 and
AEAD_AES_128_GCM, AEAD_AES_256_GCM as its MAC algorithm(s) and
rejects all other MAC algorithm(s).
FCS_SSHS_EXT
.1.5
The SSH server shall ensure that diffie-hellman-group14-sha1,
ecdh-sha2-nistp256 and ecdh-sha2-nistp384, ecdh-sha2-nistp521 are
the only allowed key exchange methods used for the SSH protocol.
FCS_SSHS_EXT
.1.6
The SSH server shall ensure that the SSH connection be rekeyed after no
more than 2
28
packets have been transmitted using that key.
FCS_SSHS_EXT
.1.7
6.1.3 User data protection (FDP)
6.1.3.1 Access Controls for Protecting User Data (FDP_ACF_EXT.1)
The OS shall implement access controls which can prohibit unprivileged users
from accessing files and directories owned by other users.
FDP_ACF_EXT.1.1
6.1.3.2 Subset access control: MVS (FDP_ACC.1(PSO-MVS))
The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy on
FDP_ACC.1.1
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 Subset access control: UNIX (FDP_ACC.1(PSO-UNIX))
The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy on
FDP_ACC.1.1
a) jobs, started tasks, UNIX processes, and TSO sessions acting on
behalf of users;
Page 46 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 Subset access control (FDP_ACC.1(TSO))
The TSF shall enforce the Transient Storage Object Access Control Policy
on
FDP_ACC.1.1
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 Security attribute based access control: MVS
(FDP_ACF.1(PSO-MVS))
The TSF shall enforce the MVS Persistent Storage Object Access Control
Policy to objects based on the following:
FDP_ACF.1.1
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.
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.
Page 47 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.2
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.3
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.
FDP_ACF.1.4
6.1.3.6 Security attribute based access control: UNIX
(FDP_ACF.1(PSO-UNIX))
The TSF shall enforce the UNIX Persistent Storage Object Access Control
Policy to objects based on the following:
FDP_ACF.1.1
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.
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.
FDP_ACF.1.2
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.3
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.
FDP_ACF.1.4
Page 48 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.3.7 Security attribute based access control: UNIX IPC
(FDP_ACF.1(TSO))
The TSF shall enforce the Transient Storage Object Access Control Policy
to objects based on the following:
FDP_ACF.1.1
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.
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.2
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.3
The TSF shall explicitly deny access of subjects to named objects based on
the following rules: none.
FDP_ACF.1.4
6.1.3.8 Full residual information protection of resources (FDP_RIP.2)
The TSF shall ensure that any previous information content of a resource is
made unavailable upon the allocation of the resource to all objects.
FDP_RIP.2.1
6.1.4 Identification and authentication (FIA)
6.1.4.1 Authentication failure handling (Refined) (FIA_AFL.1)
The OS shall detect when an administrator configurable positive integer
within a range of positive integers unsuccessful authentication attempts
occur related to events with authentication based on user name and
password .
FIA_AFL.1.1
When the defined number of unsuccessful authentication attempts for an
account has been met, the OS shall: Account Disablement .
FIA_AFL.1.2
6.1.4.2 User attribute definition (FIA_ATD.1)
The TSF shall maintain the following list of security attributes belonging to
individual human users:
FIA_ATD.1.1
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);
Page 49 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 Verification of secrets (FIA_SOS.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.
FIA_SOS.1.1
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 Timing of authentication (FIA_UAU.1)
The TSF shall allow
FIA_UAU.1.1
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.
The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
FIA_UAU.1.2
6.1.4.5 Multiple Authentication Mechanisms (Refined) (FIA_UAU.5)
The OS shall provide the following authentication mechanisms
FIA_UAU.5.1
● authentication based on user name and password
● for use in SSH only, SSH public key-based authentication as
specified by the EP for Secure Shell
to support user authentication.
The OS shall authenticate any user's claimed identity according to the
following rule:
FIA_UAU.5.2
● 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:
❍ certificate-based authentication with certificates held in RACF
keyrings;
❍ user name and password authentication;
❍ a combination of both, where user name and password
authentication is used in case the certificate based
authentication is unsuccessful.
.
Page 50 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.4.6 Protected authentication feedback (FIA_UAU.7)
The TSF shall provide only obscured feedback to the user while the
authentication is in progress.
FIA_UAU.7.1
6.1.4.7 Timing of identification (FIA_UID.1)
The TSF shall allow
FIA_UID.1.1
a) no actions
on behalf of the user to be performed before the user is identified.
The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
FIA_UID.1.2
6.1.4.8 User-subject binding (FIA_USB.1)
The TSF shall associate the following user security attributes with subjects
acting on the behalf of that user:
FIA_USB.1.1
a) 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;
e) Active groups;
f) the RACF attributes/roles SPECIAL, group-SPECIAL, AUDITOR,
ROAUDIT, group-AUDITOR, CLAUTH, OPERATIONS, and
group-OPERATIONS.
The TSF shall enforce the following rules on the initial association of user
security attributes with subjects acting on the behalf of users:
FIA_USB.1.2
a) A started task executes with the user ID defined in the started
class or started procedures table defining the started task.
The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users:
FIA_USB.1.3
a) 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 identify 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
Page 51 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 X.509 Certificate Validation (FIA_X509_EXT.1)
The OS shall implement functionality to validate certificates in accordance
with the following rules:
FIA_X509_EXT.1.1
a) [RFC5280]☝ certificate validation and certificate path validation.
b) The certificate path must terminate with a trusted CA certificate.
c) The OS 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.
d) The OS shall validate the revocation status of the certificate using the
Online Certificate Status Protocol (OCSP) as specified in
[RFC2560]☝, a Certificate Revocation List (CRL) as specified in
[RFC5759]☝.
e) The OS shall validate the extendedKeyUsage field according to the
following rules:
1. Certificates used for trusted updates and executable code integrity
verification shall have the Code Signing purpose (id-kp 3 with OID
1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
2. 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.
3. 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.
4. S/MIME certificates presented for email encryption and signature
shall have the Email Protection purpose (id-kp 4 with OID
1.3.6.1.5.5.7.3.4) in the extendedKeyUsage field.
5. 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.
6. (Conditional) Server certificates presented for EST shall have the
CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID
1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field.
.
The OS shall only treat a certificate as a CA certificate if the basicConstraints
extension is present and the CA flag is set to TRUE.
FIA_X509_EXT.1.2
6.1.4.10 X.509 Certificate Authentication (FIA_X509_EXT.2)
The OS shall use X.509v3 certificates as defined by [RFC5280]☝ to support
authentication for TLS and HTTPS, no other protocols connections.
FIA_X509_EXT.2.1
Page 52 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.5 Security management (FMT)
6.1.5.1 Management of security functions behavior (FMT_MOF_EXT.1)
The OS shall restrict the ability to perform the function indicated in the
"Administrator" column in FMT_SMF_EXT.1 to the administrator.
FMT_MOF_EXT
.1.1
6.1.5.2 Specification of Management Functions (FMT_SMF_EXT.1)
The OS shall be capable of performing the following management functions:
FMT_SMF_EXT.1.1
a) Enable/disable screen lock, session timeout
b) Configure screen lock, 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
h) Configure minimum number of lowercase characters in password
i) Configure lockout policy for unsuccessful authentication attempts through
timeouts between attempts, limiting number of attempts during
a time period
j) Configure host-based firewall
k) Configure audit rules
l) Configure name/address of network time server
.
6.1.5.3 Management of object security attributes (FMT_MSA.1(PSO-MVS))
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
FMT_MSA.1.1
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 Management of object security attributes
(FMT_MSA.1(PSO-UNIX))
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
FMT_MSA.1.1
a) the owner of the object;
b) a user with z/OS UNIX superuser privilege
.
Page 53 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.5.5 Management of object security attributes (FMT_MSA.1(TSO))
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
FMT_MSA.1.1
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 Static attribute initialisation (FMT_MSA.3(PSO-MVS))
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.
FMT_MSA.3.1
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.
FMT_MSA.3.2
6.1.5.7 Static attribute initialisation (FMT_MSA.3(PSO-UNIX))
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.1
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.
FMT_MSA.3.2
6.1.5.8 Static attribute initialisation (FMT_MSA.3(TSO))
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.1
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.
FMT_MSA.3.2
6.1.5.9 Management of TSF data (FMT_MTD.1)
The TSF shall restrict the ability to query, modify the full set of audited
events to
FMT_MTD.1.1
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 Security management roles (FMT_SMR.1)
The TSF shall maintain the roles:
FMT_SMR.1.1
a) User role with the following rights:
Page 54 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Users are authorized to modify their own user password;
1.
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;
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).
The TSF shall be able to associate users with roles.
FMT_SMR.1.2
6.1.6 Protection of the TSF (FPT)
6.1.6.1 Access controls (FPT_ACF_EXT.1)
The OS shall implement access controls which prohibit unprivileged users from
modifying:
FPT_ACF_EXT.1.1
a) Kernel and its drivers/modules
b) Security audit logs
c) Shared libraries
d) System executables
e) System configuration files
f) MVS data sets and other z/OS objects, UNIX file system objects,
UNIX IPC objects
.
The OS shall implement access controls which prohibit unprivileged users from
reading:
FPT_ACF_EXT.1.2
a) Security audit logs
b) System-wide credential repositories
c) MVS data sets, UNIX file system objects
.
Page 55 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.6.2 Address Space Layout Randomization (FPT_ASLR_EXT.1)
The OS shall always randomize process address space memory locations with
8 bits of entropy except for the lower 16 MB of memory.
FPT_ASLR_EXT
.1.1
6.1.6.3 Reliable time stamps (FPT_STM.1)
The TSF shall be able to provide reliable time stamps.
FPT_STM.1.1
6.1.7 TOE access (FTA)
6.1.7.1 Default TOE access banners (FTA_TAB.1)
Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorized use of the TOE.
FTA_TAB.1.1
6.1.7.2 TSF-initiated session locking (FTA_SSL.1)
The TSF shall lock an interactive session after an administrator-configurable
time interval of user inactivity by:
FTA_SSL.1.1
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.
The TSF shall require the following events to occur prior to unlocking the
session:
FTA_SSL.1.2
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 User-initiated locking (FTA_SSL.2)
The TSF shall allow user-initiated locking of the user's own interactive session,
by:
FTA_SSL.2.1
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.
The TSF shall require the following events to occur prior to unlocking the
session:
FTA_SSL.2.2
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.
Page 56 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
6.1.8 Trusted path/channels (FTP)
6.1.8.1 Trusted channel communication (FTP_ITC_EXT.1)
The OS shall use TLS as conforming to FCS_TLSC_EXT.1FCS_TLSC_PLUS.1,
SSH as conforming to the EP for Secure Shell to provide a trusted
communication channel between itself and authorized IT entities supporting
FTP_ITC_EXT.1.1
the following capabilities: management and other general computing
facilities 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 Trusted channel communication (IPSec) (FTP_ITC.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:
FTP_ITC.1.1
● Cryptographically-protected communication channel using the IPSec
protocol offered by TOE services using cipher suites defined in
FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_COP.1(5);
The TSF shall permit the TSF, another trusted IT product to initiate
communication via the trusted channel.
FTP_ITC.1.2
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..
FTP_ITC.1.3
6.1.8.3 Trusted Path (Refined) (FTP_TRP.1)
The OS 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.1
The OS shall permit the TSF, local users, remote users to initiate
communication via the trusted path.
FTP_TRP.1.2
The OS shall require use of the trusted path for [[all remote administrative
actions]].
FTP_TRP.1.3
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).
The following sections analyse the security requirements with regard to coverage and sufficiency
as well as dependencies.
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.
Page 57 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Objectives
Security functional requirements
O.ACCOUNTABILITY,
O.AUDITING
FAU_GEN.1
O.ACCOUNTABILITY,
O.AUDITING
FAU_GEN.2
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.PROTECTED_COMMS
FCS_CKM.1
O.PROTECTED_COMMS
FCS_CKM.2
O.PROTECTED_COMMS
FCS_CKM_EXT.4
O.PROTECTED_COMMS,
O.PROTECTED_STORAGE
FCS_COP.1(1)
O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1(2)
O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1(3)
O.INTEGRITY,
O.PROTECTED_COMMS
FCS_COP.1(4)
O.PROTECTED_COMMS
FCS_COP.1(5)
O.PROTECTED_COMMS,
O.PROTECTED_STORAGE
FCS_RBG_EXT.1
O.PROTECTED_STORAGE
FCS_STO_EXT.1
O.PROTECTED_COMMS
FCS_TLSC_PLUS.1
O.PROTECTED_COMMS
FCS_TLSC_PLUS.2
O.PROTECTED_COMMS
FCS_TLSC_PLUS.3
O.PROTECTED_COMMS
FCS_TLSC_EXT.4
O.PROTECTED_COMMS
FCS_SSH_EXT.1
O.PROTECTED_COMMS
FCS_SSHC_EXT.1
O.PROTECTED_COMMS
FCS_SSHS_EXT.1
O.PROTECTED_STORAGE
FDP_ACF_EXT.1
O.DISCRETIONARY
.ACCESS
FDP_ACC.1(PSO-MVS)
Page 58 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Objectives
Security functional requirements
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.AUDITING,
O.DISCRETIONARY
.ACCESS,
O.IA
FDP_RIP.2
O.IA,
O.INTEGRITY
FIA_AFL.1
O.INTEGRITY
FIA_ATD.1
O.IA
FIA_SOS.1
O.IA,
O.INTEGRITY
FIA_UAU.1
O.IA,
O.IA.MULTIPLE,
O.INTEGRITY
FIA_UAU.5
O.IA
FIA_UAU.7
O.IA,
O.INTEGRITY
FIA_UID.1
O.IA
FIA_USB.1
O.INTEGRITY,
O.PROTECTED_COMMS
FIA_X509_EXT.1
O.PROTECTED_COMMS
FIA_X509_EXT.2
O.MANAGEMENT
FMT_MOF_EXT.1
O.MANAGEMENT
FMT_SMF_EXT.1
O.MANAGEMENT
FMT_MSA.1(PSO-MVS)
O.MANAGEMENT
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.INTEGRITY
FPT_ACF_EXT.1
Page 59 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Objectives
Security functional requirements
O.INTEGRITY
FPT_ASLR_EXT.1
O.ACCOUNTABILITY
FPT_STM.1
O.MANAGEMENT
FTA_TAB.1
O.IA
FTA_SSL.1
O.IA
FTA_SSL.2
O.ACCOUNTABILITY,
O.INTEGRITY,
O.PROTECTED_COMMS
FTP_ITC_EXT.1
O.ACCOUNTABILITY,
O.INTEGRITY,
O.PROTECTED_COMMS
FTP_ITC.1
O.MANAGEMENT
FTP_TRP.1
Table 7: Mapping of security functional requirements to security objectives
6.2.2 Security Requirements Sufficiency
The following rationale provides justification for each security objective for the TOE, showing
that the security functional requirements are suitable to meet and achieve the security objectives.
Rationale
Security objectives
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.
O.ACCOUNTABILITY
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.
FPT_ASLR_EXT.1 prevents attackers from exploiting code that executes
in static known memory locations. FCS_COP.1(2), FCS_COP.1(3), and
FCS_COP.1(4) provide the cryptographic mechanisms that are used
O.INTEGRITY
to verify integrity values. FPT_ACF_EXT.1 guarantees the integrity of
critical components by preventing unauthorized modifications of
them. FIA_UAU.5 provides mechanisms that prevent untrusted users
from accessing the TSF and FIA_AFL.1 prevents brute-force
authentication attempts. FTP_ITC_EXT.1 provides trusted remote
communications which makes a remote authenticated session less
susceptible to compromise.
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.
Page 60 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Rationale
Security objectives
FMT_SMF_EXT.1 defines the TOE's management functions and
FMT_MOF_EXT.1 defines the privileges required to invoke
them. FTP_TRP.1 provides one or more secure remote interfaces for
management of the TSF and FTA_TAB.1 provides actionable warnings
against misuse of these interfaces.
O.MANAGEMENT
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).
FCS_STO_EXT.1 provides a mechanism by which the TOE can designate
data as sensitive and subsequently require it to be
encrypted. FCS_COP.1(1) defines the symmetric algorithm used to
O.PROTECTED_STORAGE
encrypt and decrypt sensitive data. FCS_RBG_EXT.1 defines the random
bit generator used to create the symmetric keys used to perform this
encryption and decryption. FDP_ACF_EXT.1 enforces logical access
control on stored data.
FCS_TLSC_PLUS.1, FCS_TLSC_PLUS.2, FCS_TLSC_PLUS.3, and
FCS_TLSC_EXT.4 define the ability of the TOE to act as a TLS client as
a method of enforcing protected communications. FCS_CKM.1,
O.PROTECTED_COMMS
FCS_CKM.2, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4),
and FCS_RBG_EXT.1 define the cryptographic operations and key
lifecycle activity used to support the establishment of protected
communications. FIA_X509_EXT.1 defines how the TSF validates x.509
certificates as part of establishing protected
communications. FIA_X509_EXT.2 defines the trusted communication
protocols for which the TOE must perform certificate validation
operations. FCS_COP.1(5) defines the TOE's ability to communicate
using the IPSec protocol using the trusted channel defined in FTP_ITC.1.
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
O.AUDITING
(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).
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.
O.DISCRETIONARY
.ACCESS
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).
Page 61 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Rationale
Security objectives
The TSF must ensure that only authorized users gain access to the
TOE and its resources. Users authorized to access the TOE must use
an identification and authentication process (FIA_UID.1, FIA_UAU.1).
O.IA
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 locking
(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).
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.
O.IA.MULTIPLE
Table 8: Security objectives for the TOE rationale
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.
Resolution
Dependencies
Security functional
requirement
FPT_STM.1
FPT_STM.1
FAU_GEN.1
FAU_GEN.1
FAU_GEN.1
FAU_GEN.2
FIA_UID.1
FIA_UID.1
FAU_GEN.1
FAU_GEN.1
FAU_SAR.1
FAU_SAR.1
FAU_SAR.1
FAU_SAR.2
FAU_SAR.1
FAU_SAR.1
FAU_SAR.3
FAU_GEN.1
FAU_GEN.1
FAU_SEL.1
FMT_MTD.1
FMT_MTD.1
FAU_GEN.1
FAU_GEN.1
FAU_STG.1
FAU_STG.1
FAU_STG.1
FAU_STG.3
FAU_STG.1
FAU_STG.1
FAU_STG.4
Page 62 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Resolution
Dependencies
Security functional
requirement
FCS_CKM.2
FCS_COP.1(1)
FCS_COP.1(2)
FCS_COP.1(3)
FCS_COP.1(4)
[FCS_CKM.2 or FCS_COP.1]
FCS_CKM.1
FCS_CKM_EXT.4
FCS_CKM.4
FCS_CKM.1
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.2
FCS_CKM_EXT.4
FCS_CKM.4
No dependencies
FCS_CKM_EXT.4
FCS_CKM.1
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_COP.1(1)
FCS_CKM_EXT.4
FCS_CKM.4
FCS_CKM.1
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_COP.1(2)
FCS_CKM_EXT.4
FCS_CKM.4
FCS_CKM.1
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_COP.1(3)
FCS_CKM_EXT.4
FCS_CKM.4
FCS_CKM.1
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_COP.1(4)
FCS_CKM_EXT.4
FCS_CKM.4
FCS_COP.1(1)
FCS_COP.1(2)
FCS_COP.1(3)
FCS_COP.1(4)
[FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1]
FCS_COP.1(5)
FCS_CKM_EXT.4
FCS_CKM.4
No dependencies
FCS_RBG_EXT.1
No dependencies
FCS_STO_EXT.1
No dependencies
FCS_TLSC_PLUS.1
No dependencies
FCS_TLSC_PLUS.2
No dependencies
FCS_TLSC_PLUS.3
No dependencies
FCS_TLSC_EXT.4
No dependencies
FCS_SSH_EXT.1
No dependencies
FCS_SSHC_EXT.1
No dependencies
FCS_SSHS_EXT.1
No dependencies
FDP_ACF_EXT.1
Page 63 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Resolution
Dependencies
Security functional
requirement
FDP_ACF.1(PSO-MVS)
FDP_ACF.1
FDP_ACC.1(PSO-MVS)
FDP_ACF.1(PSO-MVS)
FDP_ACF.1
FDP_ACC.1(PSO-UNIX)
FDP_ACF.1(TSO)
FDP_ACF.1
FDP_ACC.1(TSO)
FDP_ACC.1(PSO-MVS)
FDP_ACC.1
FDP_ACF.1(PSO-MVS)
FMT_MSA.3(PSO-MVS)
FMT_MSA.3
FDP_ACC.1(PSO-UNIX)
FDP_ACC.1
FDP_ACF.1(PSO-UNIX)
FMT_MSA.3(PSO-UNIX)
FMT_MSA.3
FDP_ACC.1(PSO-UNIX)
FDP_ACC.1
FDP_ACF.1(TSO)
FMT_MSA.3(PSO-UNIX)
FMT_MSA.3
No dependencies
FDP_RIP.2
FIA_UAU.1
FIA_UAU.1
FIA_AFL.1
No dependencies
FIA_ATD.1
No dependencies
FIA_SOS.1
FIA_UID.1
FIA_UID.1
FIA_UAU.1
No dependencies
FIA_UAU.5
FIA_UAU.1
FIA_UAU.1
FIA_UAU.7
No dependencies
FIA_UID.1
FIA_ATD.1
FIA_ATD.1
FIA_USB.1
No dependencies
FIA_X509_EXT.1
No dependencies
FIA_X509_EXT.2
No dependencies
FMT_MOF_EXT.1
No dependencies
FMT_SMF_EXT.1
FDP_ACC.1(PSO-MVS)
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1(PSO-MVS)
FMT_SMR.1
FMT_SMR.1
FMT_SMF_EXT.1
FMT_SMF.1
FDP_ACC.1(PSO-UNIX)
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1(PSO-UNIX)
FMT_SMR.1
FMT_SMR.1
FMT_SMF_EXT.1
FMT_SMF.1
FDP_ACC.1(TSO)
[FDP_ACC.1 or FDP_IFC.1]
FMT_MSA.1(TSO)
FMT_SMR.1
FMT_SMR.1
FMT_SMF_EXT.1
FMT_SMF.1
Page 64 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Resolution
Dependencies
Security functional
requirement
FMT_MSA.1(PSO-MVS)
FMT_MSA.1
FMT_MSA.3(PSO-MVS)
FMT_SMR.1
FMT_SMR.1
FMT_MSA.1(PSO-UNIX)
FMT_MSA.1
FMT_MSA.3(PSO-UNIX)
FMT_SMR.1
FMT_SMR.1
FMT_MSA.1(TSO)
FMT_MSA.1
FMT_MSA.3(TSO)
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_SMR.1
FMT_MTD.1
FMT_SMF_EXT.1
FMT_SMF.1
FIA_UID.1
FIA_UID.1
FMT_SMR.1
No dependencies
FPT_ACF_EXT.1
No dependencies
FPT_ASLR_EXT.1
No dependencies
FPT_STM.1
No dependencies
FTA_TAB.1
FIA_UAU.1
FIA_UAU.1
FTA_SSL.1
FIA_UAU.1
FIA_UAU.1
FTA_SSL.2
No dependencies
FTP_ITC_EXT.1
No dependencies
FTP_ITC.1
No dependencies
FTP_TRP.1
Table 9: TOE SFR dependency analysis
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.
Page 65 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Coverage in TSS
SFR
See section Audit (FAU).
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 General Cryptography.
FCS_CKM.1
See section General Cryptography.
FCS_CKM.2(1)
See section Cryptographic Key Destruction and Object Re-Use (FDP_RIP).
FCS_CKM.4
See section General Cryptography.
FCS_COP.1(1)
See section General Cryptography.
FCS_COP.1(2)
See section General Cryptography.
FCS_COP.1(3)
See section General Cryptography.
FCS_COP.1(4)
See section Communication Security.
FCS_COP.1(5)
See section Random Number Generation.
FCS_RBG_EXT.1
See section Confidentiality Protection of Data Sets.
FCS_STO_EXT.1
See section Communication Security.
FCS_TLSC_PLUS.1
See section Communication Security.
FCS_TLSC_PLUS.2
See section Communication Security.
FCS_TLSC_PLUS.3
See section Communication Security.
FCS_TLSC_EXT.4
See section Communication Security.
FCS_SSH_EXT.1
See section Communication Security.
FCS_SSHC_EXT.1
See section Communication Security.
FCS_SSHS_EXT.1
See section Discretionary Access Control.
FDP_ACF_EXT.1
Page 66 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Coverage in TSS
SFR
See section Discretionary Access Control.
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 Object Re-Use (FDP_RIP).
FDP_RIP.2
See section Password Quality.
FIA_AFL.1
See section Identification and Authentication (FIA, FTA).
FIA_ATD.1
See section Identification and Authentication (FIA, FTA).
FIA_SOS.1
See section Identification and Authentication (FIA, FTA) and Authentication
Functions.
FIA_UAU.1
See section Identification and Authentication (FIA, FTA) and Authentication
Functions.
FIA_UAU.5
See section Identification and Authentication (FIA, FTA) and Authentication
Functions.
FIA_UAU.7
See section Identification and Authentication (FIA, FTA) and Authentication
Functions.
FIA_UID.1
See section Identification and Authentication (FIA, FTA) and Authentication
Functions.
FIA_USB.1
See section Authentication via Client Digital Certificates.
FIA_X509_EXT.1
See section Authentication via Client Digital Certificates.
FIA_X509_EXT.2
See section Security Management (FMT), RACF configuration and management,
RACF Certificate and Key Management and Time Management.
FMT_MOF_EXT.1
See section Security Management (FMT), RACF configuration and management,
RACF Certificate and Key Management and Time Management.
FMT_SMF_EXT.1
See section Resource management, Security Management (FMT), RACF
configuration and management and RACF Certificate and Key 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.
FMT_MSA.3(TSO)
Page 67 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Coverage in TSS
SFR
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 Discretionary Access Control.
FPT_ACF_EXT.1
See section Addess Space Layout Randomization.
FPT_ASLR_EXT.1
See section Time Management.
FPT_STM.1
See section Access Banners.
FTA_TAB.1
See section Session Locking.
FTA_SSL.1
See section Session Locking.
FTA_SSL.2
See section Communication Security.
FTP_ITC_EXT.1
See section Communication Security.
FTP_ITC.1
See section Communication Security.
FTP_TRP.1
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 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.
Page 68 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.
Page 69 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.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
Page 70 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 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}.
Page 71 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.1}.
● 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}.
Page 72 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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 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
● By submitting a job to be initiated and scheduled by the Job Entry Subsystem (JES2)
● As a UNIX user, including access via the UNIX shell
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:
Page 73 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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.2 Authentication Functions
RACF Passwords and Password Phrases
In RACF, the user selects his own password/phrase and only the user knows the value chosen.
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 for a pseudo-user 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-R10}.
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 syntax 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 using the DES algorithm that it stores
on the database. The password is not stored in clear text {IA.2::IA.2.4}.
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: .<+|&!*-%_>?:=
● Type of character for each character position of a password. Possible types are
{IA.2::IA.2.9}:
● ALPHA
Page 74 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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.
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.
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:
Page 75 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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}
● 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}
Page 76 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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
❍ 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}.
Page 77 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 either support Certificate Revocation Lists (CRLs) maintained in an LDAP registry or through
HTTP URIs or the CA must support obtaining revocation information through OCSP responses
{IA.2::IA.2.V2R2-SSL-1}, and the security administrator must configure the application to use
the CRLs or OCSP responses {IA.2::IA.2.V2R2-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 CRL 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 and CRL distribution point HTTP
Crls for certificate revocation checking {IA.2::IA.2-V2R2.8}.
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
which includes a check for the revocation status using a CRL.
{IA:2::IA.2-V2R4-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. {IA:2::IA.2-V2R4-SSL-CPV-3}
4. The revocation status of the certificate is checked using the Online Certificate Status
Protocol (OCSP) as specified in [RFC2560]☝. {IA:2::IA.2-V2R4-SSL-CPV-5}
5. 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.
● 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-V2R4-SSL-CPV-4}
After System SSL has validated the client certificate, the application (or AT-TLS) can map it to
a RACF user ID via the R_usermap() callable service {IA.2::IA.2.16-R8-RACF-1}. Or the
application can directly create a security environment for the user by using the
pthread_security_np() service {IA.2::IA.2.16-R8-USS-1}, the InitACEE() service
{IA.2::IA.2.16-R8-RACF-3}, or the _certificate() service {IA.2::IA.2-16-R9-USS-1} which
will accept the certificate as input. In either case, RACF will:
1. Examine the RACF database and determine whether the certificate is installed and
registered to a specific user. If so, return that user ID {IA.2::IA.2.17-R8-RACF-1}
2. Otherwise, try to find the best-matching mapping profile (DIGTNMAP class), and return
the user ID specified in the profile’s APPLDATA field:
Page 78 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Check for a filter of subject’s-full-name.issuer’s-full-name
{IA.2::IA.2.17-R8-RACF-2}
a)
b) Iteratively remove nodes from the subject’s name and check for a filter of the
form: subject’s-partial-name.issuer’s-full-name {IA.2::IA.2.17-R8-RACF-3}
c) Check for a filter of the form: subject’s-full-name {IA.2::IA.2.17-R8-RACF-4}
d) Iteratively remove nodes from the subject’s name and check for a filter of the
form: subject’s-partial-name {IA.2::IA.2.17-R8-RACF-5}
e) Check for a filter of the form: issuer’s-full-name {IA.2::IA.2.17-R8-RACF-6}
f) Iteratively remove nodes from the issuer’s name and check for a filter of the
form: issuer’s-partial-name {IA.2::IA.2.17-R8-RACF-7}
3. Otherwise, try to find the best-matching mapping profile (DIGTNMAP, DIGTCRIT class)
that matches the mapping criteria specified by the application that presented the
certificate to RACF, and if found return the user ID specified in the DIGTNMAP profile’s
APPLDATA field {IA.2::IA.2.17-R8-RACF-8}.
4. Otherwise, if the certificate contains at least one hostIDMappings extension with a
host-name and user ID {IA.2::IA.2.17-R8-RACF-9} and the certificate was issued by
a CA defined to RACF as having the HIGHTRUST status {IA.2::IA.2.17-R8-RACF-10},
then RACF will examine each of the hostIDMappings extensions, in order
{IA.2::IA.2.17-R8-RACF-11}. RACF will determine whether the application has READ
access to IRR.HOST.host-name in the SERVAUTH class, and if so RACF will return the
user ID associated with that host-name {IA.2::IA.2.17-R8-RACF-12}.
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. Public/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. via FTP) 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}.
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
Page 79 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.
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 both the NOPASSWORD and NOOIDCARD attributes
{IA.3::IA.3.5}. 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}.
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 the Express Logon Facility (ELF)
{IA.3::IA.3-R8-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}
OpenSSH supports authentication via public/private key pairs stored in digital certificates when
it is configured to store the certificates in RACF key rings {IA.3::IA.3-R12-SSH-AUTHRINGS}.
Page 80 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 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}.
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-R12-IDPROP-RACF-5}The RACF R_cacheserv service can also return a
pseudo-userID and pseudo-password 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. The
pseudo-userID and pseudo-password may be used at most once on a subsequent authentication
request.
Page 81 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
{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.
{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-R12-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 pseudo-userID and
pseudo-password obtained via a prior authentication and use of R_cacheserv.
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.3 Access Control (FDP)
Access Control Overview
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
Page 82 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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
Page 83 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
allow the user to perform a specific 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.
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.
Discretionary Access Control
Datasets
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.
Page 84 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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}.
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:
● 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.
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}.
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}
Page 85 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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}
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:
● 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}.
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}
Page 86 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● {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}
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}.
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}.
Page 87 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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}.
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}.
Page 88 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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:
● 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}.
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}.
Page 89 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.)
● 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
Page 90 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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:
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.
Page 91 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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}
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
Page 92 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 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}
Page 93 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
● The data set is cataloged in the master catalog.
● 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-V2R4-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.
Access Control to System Logger Objects
Please refer to section Using a System Log Stream for SMF.
Page 94 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
z/OS UNIX file system objects
UNIX file system objects in the HFS or 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 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}
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.
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.
Page 95 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
DAC checking for UNIX IPC objects (semaphores, shared memory) involves only permission bits.
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.
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}
Page 96 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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}
Page 97 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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}
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}
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.4 Audit (FAU)
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
Page 98 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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 and FAU_GEN.2.
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}
Protection of the audit trail
SMF writes audit records into either
Page 99 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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}.
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.5 Cryptographic Functions (FCS)
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 may be provided by hardware coprocessors attached to the TOE. ICSF checks for the
availability of hardware support for individual cryptographic functions and uses this when
Page 100 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
appropriate. SSH will always use its own software implementation of the cryptographic algorithms
but can also be configured to use CPACF for AES, and the SHA-2 family of hash functions. For
the RACDCERT command, the command issuer chooses, by the keywords chosen, whether to
use ICSF or a software implementation.
ICSF provides secure PKCS #11 support. This support requires the Crypto Express 7S cards to
be configured with the EP11 card code and secure keys to be encrypted and stored in the TKDS
{CR.2::CR2-V2R1-ICSF-1}.
Support for using secure RSA and ECDSA PKCS #11 CA certificates, generation of secure PKCS#11
key pairs for key generation requests and CMP requests is provided {CR.2::CR2-V2R1-ICSF-2}.
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.
Cryptographic Functions for Application Use
The TOE also provides various cryptographic functions via ICSF that are available for use by
applications running on the system.
{CR.2::CR-R13-ICSF-1} The CSFPSKE and CSFPSKD services provided by ICSF provide the
ability for an application to perform encryption and decryption operations with the following
algorithms and key sizes:
● AES with CBC or GCM block chaining modes and 128- or 256-bit keys.
{CR.2::CR-R13-ICSF-2} The CSFPPKV and CSFPPKS services provided by ICSF provide the
ability for an application to perform encryption and decryption operations with the following
algorithms and key sizes:
● RSA with key sizes up to 4096 as defined by PKCS #1 v1.5
{CR.2::CR-R13-ICSF-3} The CSFPOWH service provided by ICSF provides the ability for an
application to perform message digest generation in accordance with the following cryptographic
algorithms:
● SHA-256
● SHA-512
{CR.2::CR-V2R4-ICSF-4} The CSFPOWH service provided by ICSF provides the ability for an
application to generate and verify signatures using the following algorithms and key sizes:
● RSA with 2048 to 4096-bit keys using the RSASSA-PKCS-v1.5 scheme (PKCS#1)
● RSA with 2048 to 4096-bit keys using the RSASSA-PSS scheme (PKCS#1)
● ECDSA with:
❍ NIST curve=256
❍ 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).
The hash function can be selected to be either SHA-256, or SHA-512. Note: other hash functions
are supported but no claims about those are made in this Security Target.
FIPS 140-2
In addition to providing cryptographic support, several components of z/OS have been designed
to meet the Federal Implementation Processing Standard (FIPS) 140-2 Level 1 criteria. FIPS is a
standard that has been issued by the National Institute of Standards and Technology and
Communications Security Establishment (CSE) of the Government of Canada. This standard
specifies security requirements for a cryptographic module which is utilized within a security
Page 101 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
system to protect sensitive or valuable information. To meet this standard, cryptographic modules
are tested against requirements defined in the FIPS PUB 140-2, Security Requirements for
Cryptographic Modules. These security requirements cover 11 areas related to the design and
implementation of a cryptographic module.
The z/OS components designed to meet FIPS 140-2 Level 1 are ICSF and System SSL. When
utilizing these components in FIPS mode, they will restrict cryptographic processing to what is
approved or allowed in FIPS mode.
For System SSL and this TOE, the algorithms implemented within System SSL or System SSL
uses directly through the CPACF are: symmetric AES CBC (128 and 256 bit); hashing algorithms
SHA-1 (160-bit) and SHA-2 (224, 256, 384, 512 bit); asymmetric algorithm RSA (2048-4096 bit).
{CR.1::CR-V2R4-SSL-1}
For ICSF and this TOE, the algorithms implemented within ICSF, ICSF uses directly through the
CPACF or CEX7A crypto card are: AES ECB, CBC, GCM (128, 192 and 256 bit); hashing algorithms
SHA-1 (160 bit) and SHA-2 (224, 256, 384 and 512 bit); asymmetric algorithms RSA(2048-4096bit),
ECDSA(192-521bit); Diffie-Hellman key agreement algorithms DH(2048bit) and EC-DH(224-521bit).
{CR.1::CR-V2R4-ICSF-1}
Approved cryptographic algorithms are tested for conformance by inputting defined test vectors
and comparing the output results against expected output vectors. {CR.1::CR-V2R1-SSL-2},
{CR.1::CR-V2R1-ICSF-2}
Each component has unique methods to control FIPS mode execution.
System SSL applications that execute in FIPS mode must utilize the gsk_fips_state_set() API
prior to other System SSL functions, to set one of the following FIPS levels:
● GSK_FIPS_STATE_LEVEL1 {CR1::CR-V2R3-SSL-5}: When executing in FIPS mode with
GSK_FIPS_STATE_ON or GSK_FIPS_STATE_LEVEL1 set, 128-bit keys and 256-bit keys are
supported for AES. RSA keys must be between 2048 and 4096 bits and Diffie-Hellman
keys must be 2048 bits.
● GSK_FIPS_STATE_LEVEL2 {CR1::CR-V2R3-SSL-6}: When executing in FIPS mode with
GSK_FIPS_STATE_LEVEL2 set, 112-bit security is enforced when creating new keys or
performing digital signature generation and encryption type operations. For key
generation, Diffie-Hellman keys must be 2048 bits, ECC keys must 192 or greater, and
RSA keys must be between 2048 and 4096 bits. For verification, ECC keys must 192 or
greater, and RSA keys must be between 2048 and 4096 bits.
● GSK_FIPS_STATE_LEVEL3 {CR1::CR-V2R3-SSL-7}: When executing in FIPS mode with
GSK_FIPS_STATE_LEVEL3 set, 112 bit or higher security strength is enforced as defined
in NIST SP800-131Ar1. For key generation, Diffie-Hellman keys must be 2048 bits, ECC
keys must 224 or greater, and RSA keys must be between 2048 and 4096 bits. For
verification, ECC keys must 224 or greater, and RSA keys must be between 2048 and
4096 bits.
System SSL allows switching from FIPS to non-FIPS mode but not vice versa
{CR.1::CR-R12-SSL-4}.
Utilizing the FIPSMODE start up option for the ICSF started task allows to operate ICSF in FIPS
mode. FIPSMODE allows ICSF to be started in strict FIPS mode, compatibility mode which allows
select applications to execute in FIPS mode or non-FIPS mode {CR.1::CR-R12-ICSF-3}.
Compatibility mode applications by default execute in FIPS mode {CR.1::CR-R12-ICSF-4}.
FIPSEXEMPT.<token-label> in the CRYPTOZ class allows a user (application) to be exempt from
FIPS when using a specified PKCS#11 token {CR.1::CR-R12-ICSF-5} or the calling application
has indicated that the specified key must always be used in a FIPS 140-2 compliant fashion
{CR.1::CR-R12-ICSF-6}.
Page 102 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
ICSF and System SSL modules that execute within FIPS mode have been digitally signed during
the bind process using RSA and SHA-256 signatures. Upon validation of the signatures, the
modules are verified to ensure they have not been tampered with since being built. Verification
is performed during the module load process {CR.1::CR-R12-SSL-5} {CR.1::CR-R12-ICSF-7}.
In the evaluated configuration, the following services allow for execution in either FIPS or non-FIPS
mode:
● Application Transparent TLS (AT-TLS), which supports the three FIPS levels defined by
System SSL as described above. {CR.1::CR-V2R4-CS-1} Note that in the evaluated
configuration only TLS v1.2 is supported in FIPS mode as described above.
● Network Security Services daemon (NSSD) {CR.1::CR-R12-CS-2}
● IKED {CR.1::CR-R12-CS-3}
● IPSec support in the Communications Server stack {CR.1::CR-R12-CS-4}
● OpenSSH {CR.1::CR-V2R3-CS-7}
Cryptographic Key Destruction
Keys used by the TSF are either 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.
Keys in volatile storage are either overwritten with new key values or – when in dynamically
allocated memory – are overwritten with zeros as part of the object reuse 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.
This applies to SSH, NSSD, AT-TLS, IPSec and the 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.
Long-living keys used by the TSF are stored in data sets managed by ICSF. Access to those data
sets is restricted to ICSF and an installation should limit other access to just a few authorized
administrators. In addition, ICSF uses RACF to allow restricting access to the use of individual
keys to individual users.
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 zeros as part of
the object re-use function for data sets before the space is eligible for allocation to another user.
{CR.1::CR-V2R4-CKM4-1}
z/OS provides two additional methods where cryptographic keys are even more protected. 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.
Page 103 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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 CEX7C 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.6 Security Management (FMT)
RACF User and Group Management
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}
● to create a new user: is connected to a group that has the group-SPECIAL role and has
the CLAUTH attribute for the USER class and is the owner of or has JOIN authority in the
new user’s default group. Note that the following roles of the ADDUSER command can
not be assigned in this case: OPERATIONS, SPECIAL, ROAUDIT and AUDITOR
{SM.1::SM.1-V2R2-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
Page 104 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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}.
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.
Page 105 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
RACF Roles
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}.
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}
● 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)
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.
Page 106 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 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.
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.
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}
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}.
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, FTP server,). 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.
Page 107 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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.
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:
Description
Name
Indicates if it is a generic, a model or a tape data set profile
GENERIC, MODEL, or
TAPE
Owner of the data set profile
OWNER
The TSO user who is to be notified whenever RACF uses this profile to deny
access to a data set
NOTIFY
The universal access authority for the data set or data sets protected by the
profile
UACC
The type of auditing to be performed for the data set or data sets protected
by the profile
AUDIT
The security categories to be assigned to the data set or data sets protected
by the profile
CATEGORY
A setting that indicates whether the data set or data sets protected by the
profile are to be erased when they are scratched
ERASE
The unit type on which the data set resides (for discrete profiles only)
UNIT
The volume on which the data set resides (for discrete profiles only)
VOLUME
Table 10: 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:
Page 108 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● 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.
RACF configuration and management
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}
● 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}
Page 109 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
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}.
● create and manage the contents of PKCS#11 cryptographic tokens contained in the
ICSF TKDS {SM.1::SM-1.R9-RACF-RACDCERT-13}
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}.
Page 110 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.7 Object Re-Use (FDP_RIP)
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.8 Self Protection
Time Management
The TOE supports the following methods to manage it sources of 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 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}
Session Locking
The hardware available for the TOE (see section on Hardware Configuration) does not provide
means for direct connections of synchronous terminals any more. Since the requirements stated
in the SFRs FTA_SSL.1 and FTA_SSL.2 are targeted towards such direct connections, they are
irrelevant to this TOE and therefore trivially met.
Addess 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}.
Page 111 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
7.2.2.9 Communication Security
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 RSA and ECDSA signature generation and verification
as well as RSA and ECDSA certificate management/validation functions (ECDSA
is only supported with IKEv2) 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 [RFC4305]☝, [RFC4308]☝, and [RFC4835]☝
{CS.1::CS.1-R12-IPSec-1} and IKEv2 in accordance with [RFC5996]☝, [RFC4307]☝
through [RFC4308]☝, [RFC4718]☝, [RFC4753]☝, [RFC4754]☝, [RFC4809]☝, [RFC4868]☝,
[RFC4869]☝ 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-128, AES-CBC-256 (both specified by RFC 3602), AES-GCM-128 as
specified in [RFC4106]☝, AES-GCM-256 as specified in [RFC4106]☝ for ESP
encryption {CS.1::CS.1-V2R1-IPSec-8};
❍ HMAC-SHA1-96, AES-XCBC-MAC-96 for ESP authentication and authentication
header protection {CS.1::CS.1-V2R1-IPSec-9};
❍ IKEv1 as defined in [RFC2407]☝, [RFC2408]☝, [RFC2409]☝, [RFC4109]☝, and no
other RFCs for hash functions, IKEv2 as defined in [RFC5996]☝, [RFC4307]☝ and
no other RFCs for hash functions, for key negotiation and SA establishment
{CS.1::CS.1-V2R1-IPSec-10};
❍ DH Groups 14 (2048-bit MODP), and 24 (2048-bit MODP with 256-bit POS), 19
(256-bit Random ECP), 20 (384-bit Random ECP), DH Group 21
(521-bit){CS.1::CS.1-V2R4-IPSec-11};
Page 112 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
❍ ECDSA and RSA algorithm for Peer Authentication
{CS.1::CS.1-V2R1-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. In the absence of hardware crypto support, IPSec
{CS.1::CS.1-R9-IPSec-4} and System SSL {CS.1::CS.1-R9-SSL-2} will use software
algorithms for cryptographic operations, although in the case of AES (CBC, GCM, and
GMAC) encryption and SHA-2 digests IPSec will still make use of ICSF
{CS.1::CS.1-R13-IPSec-5}. For symmetric algorithms (AES) and hashing (SHA-1,
SHA-2) functions, ICSF will invoke the CPACF if it supports the function or will provide
the functions via software within ICSF {CS.1::CS.1-V2R3-ICSF-1}.
● 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 either 128- or 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 and FTP protocols are enabled to use AT-TLS and
can 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.
This configuration may also specify a list of LDAP servers for certificate revocation
information (see Section Network configuration and management.
● 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-R12-PF-2} When a filter rule applies to a packet, it can discard
the packet silently, discard the packet with ICMP notification to the sender,
permit the packet flow, or permit the packet flow and enforce IPSec processing
as described in above.
❍ {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.
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
Page 113 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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 128- or 256-bit key length utilizing session keys
generated with information provided through an RSA or EC Diffie-Hellman key exchange method.
The following TLS 1.2 cipher suites are supported:
● TLS_RSA_WITH_AES_128_CBC_SHA {CS.2::CS.1-V2R1-SSL-7} (number 002F)
● TLS_RSA_WITH_AES_256_CBC_SHA {CS.2::CS.1-V2R1-SSL-8} (number 0035)
● TLS_RSA_WITH_AES_128_CBC_SHA256 {CS.2::CS.1-V2R1-SSL-9} (number 003C)
● TLS_RSA_WITH_AES_256_CBC_SHA256 {CS.2::CS.1-V2R1-SSL-10} (number 003D)
● TLS_RSA_WITH_AES_128_GCM_SHA256 {CS.2::CS.1-V2R1-SSL-11} (number 009C)
● TLS_RSA_WITH_AES_256_GCM_SHA384 {CS.2::CS.1-V2R1-SSL-12} (number 009D)
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 {CS.2::CS.1-V2R1-SSL-15} (number
C023)
● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 {CS.2::CS.1-V2R1-SSL-13} (number
C02B)
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 {CS.2::CS.1-V2R1-SSL-16} (number
C024)
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {CS.2::CS.1-V2R1-SSL-14} (number
C02C)
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 {CS.2::CS.1-V2R1-SSL-17} (number
C027)
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 {CS.2::CS.1-V2R1-SSL-19} (number
C02F)
● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 {CS.2::CS.1-V2R1-SSL-18} (number
C028)
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 {CS.2::CS.1-V2R1-SSL-20} (number
C030)
The TOE supports the following groups in the "Elliptic Curve (Supported Groups) Extension" in
the "Client Hello":
● secp256r1 (number 0023)
● secp384r1 (number 0024)
● secp521r1 (number 0025)
{CS.2::CS.1-V2R4-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 RSA (0401)
● SHA256 with ECDSA (0403)
● SHA384 with RSA (0501)
● SHA384 with ECDSA (0503)
● SHA512 with RSA (0601)
● SHA512 with ECDSA (0603)
and no other hash algorithms {CS.2::CS.1-V2R4-SSL-25}.
For TLS 1.3 the following ciphers are supported:
● TLS_AES_128_GCM_SHA256 {CS.2::CS.1-V2R4-SSL-21} (number 1301)
● TLS_AES_256_GCM_SHA384 {CS.2::CS.1-V2R4-SSL-22} (number 1302)
Page 114 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
The TOE supports the following key exchange modes: ECDHE with the following key shares:
● secp256r1 (number 0023)
● secp384r1 (number 0024)
● secp521r1 (number 0025)
{CS.2::CS.1-V2R4-SSL-26}.
The TOE supports the following signature algorithms as defined in [RFC8446]☝, section 4.2.3:
● RSA_PKCS1_SHA256 as defined in [FIPS186-4]☝ - SHA256 with RSA (0401)
● RSA_PKCS1_SHA384 as defined in [FIPS186-4]☝ - SHA384 with RSA (0501)
● RSA_PKCS1_SHA512 as defined in [FIPS186-4]☝ - SHA512 with RSA (0601)
● ECDSA_SECP256R1_SHA256 as defined in [FIPS186-4]☝ - SHA256 with ECDSA (0403)
● ECDSA_SECP384R1_SHA384 as defined in [FIPS186-4]☝ - SHA384 with ECDSA (0503)
● ECDSA_SECP521R1_SHA512 as defined in [FIPS186-4]☝ - SHA512 with ECDSA (0603)
● RSA_PSS_RSAE_SHA256 as defined in [RFC8017]☝ - SHA256 with RSASSA-PSS (0804)
● RSA_PSS_RSAE_SHA384 as defined in [RFC8017]☝ - SHA384 with RSASSA-PSS (0805)
● RSA_PSS_RSAE_SHA512 as defined in [RFC8017]☝ - SHA512 with RSASSA-PSS (0806)
{CS.2::CS.1-V2R4-SSL-27}.
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 RSA, ECDSA key pairs. These key pairs are used by OpenSSH
for the host keys as well as for the per-user keys.
OpenSSH suports the following cryptographic algorithms:
Encryption
aes128-ctr, aes256-ctr, aes128-cbc, aes256-cbc, AEAD_AES_128_GCM,
AEAD_AES_256_GCM
Public Key Algorithms
ssh-rsa, ecdsa-sha2-nistp256and ecdsa-sha2-nistp384
MAC algorithms
hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512 and AEAD_AES_128_GCM,
AEAD_AES_256_GCM
Key Exchange Methods
diffie-hellman-group14-sha1, ecdh-sha2-nistp256 and ecdh-sha2-nistp384,
ecdh-sha2-nistp521
{CS.5::CS.1-V2R4-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 (similar to ftp) {CS.5::CS.1-R8-SSH-4}
● ssh-keygen to generate the host key files and the RSA or (EC)DSA key pairs
{CS.5::CS.1-R8-SSH-7}
Page 115 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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}
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 128-, 192-, or
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 2
18
{CS.5::CS.1-V2R4-SSH-4}.
OpenSSH allows for configuring the amount of traffic before a rekeying event occurs
{CS.5::CS.1-V2R4-SSH-5}.
IPSec
Communications Server supports IPSec, and Internet Key Exchange (IKE). IP security for z/OS
Communications Server supports two versions of the IKE protocol: IKEv1 and 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:
● 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.
Management of Communications Server Functions
z/OS provides some basic configuration data sets 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.
Page 116 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
● TCPIP.DATA
Provides parameters for TCP/IP based client and server programs.
● Additional Communications Server configuration information (e.g., AT-TLS) exists in
policy files accessed via the Communications Server Policy Agent.
● The IKE daemon, Policy Agent also have their own configuration files.
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.
7.2.2.10 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 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, you 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
Page 117 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
{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.
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.
Page 118 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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
Page 119 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 120 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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.
Page 121 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
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
Page 122 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
SAR
A requirement to assure the security of the TOE.
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 section
1.5 and its 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
CC
3.1R5
Version
April 2017
Date
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART1V3.1R5.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART2V3.1R5.pdf
Location
http://www.commoncriteriaportal.org/files/ccfiles/CC
PART3V3.1R5.pdf
Location
Digital Signature Standard (DSS)
FIPS186-4
2013-07-19
Date
https://csrc.nist.gov/publications/detail/fips/186/4/final
Location
Protection Profile for General Purpose Operating Systems
GPOSPP
NIAP
Author(s)
4.2.1
Version
2019-04-22
Date
Page 123 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
z/OS Cryptographic Services: Integrated Cryptographic Service Facility
Overview
ICSF.OVW
SC14-7505-06
Version
2020-07-22
Date received
z/OS V2.4 Planning for Multilevel Security and the Common Criteria
MLSGUIDE
GA32-0891-40
Version
2021-05-23
Date
MVS Initialization and Tuning Guide
MVSTUNE.G
SA23-1379-30
Version
November 7, 2017
Date
Operating System Protection Profile
OSPP
BSI
Author(s)
2.0, BSI-CC-PP-0067
Version
2010-06-01
Date
The Use of HMAC-SHA-1-96 within ESP and AH
RFC2404
C. Madson, R. Glenn
Author(s)
1998-11-01
Date
http://www.ietf.org/rfc/rfc2404.txt
Location
The Internet IP Security Domain of Interpretation for ISAKMP
RFC2407
D. Piper
Author(s)
1998-11-01
Date
http://www.ietf.org/rfc/rfc2407.txt
Location
Internet Security Association and Key Management Protocol (ISAKMP)
RFC2408
D. Maughan, M. Schertler, M. Schneider, J. Turner
Author(s)
1998-11-01
Date
http://www.ietf.org/rfc/rfc2408.txt
Location
The Internet Key Exchange (IKE)
RFC2409
D. Harkins, D. Carrel
Author(s)
1998-11-01
Date
http://www.ietf.org/rfc/rfc2409.txt
Location
X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP
RFC2560
M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
Author(s)
1999-06-01
Date
http://www.ietf.org/rfc/rfc2560.txt
Location
The AES-CBC Cipher Algorithm and Its Use with IPsec
RFC3602
S. Frankel, R. Glenn, S. Kelly
Author(s)
2003-09-01
Date
http://www.ietf.org/rfc/rfc3602.txt
Location
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security
Payload (ESP)
RFC4106
J. Viega, D. McGrew
Author(s)
2005-06-01
Date
http://www.ietf.org/rfc/rfc4106.txt
Location
Page 124 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
Algorithms for Internet Key Exchange version 1 (IKEv1)
RFC4109
P. Hoffman
Author(s)
2005-05-01
Date
http://www.ietf.org/rfc/rfc4109.txt
Location
The Secure Shell (SSH) Protocol Architecture
RFC4251
T. Ylonen, C. Lonvick
Author(s)
2006-01-01
Date
http://www.ietf.org/rfc/rfc4251.txt
Location
The Secure Shell (SSH) Authentication Protocol
RFC4252
T. Ylonen, C. Lonvick
Author(s)
2006-01-01
Date
http://www.ietf.org/rfc/rfc4252.txt
Location
The Secure Shell (SSH) Transport Layer Protocol
RFC4253
T. Ylonen, C. Lonvick
Author(s)
2006-01-01
Date
http://www.ietf.org/rfc/rfc4253.txt
Location
Security Architecture for the Internet Protocol
RFC4301
S. Kent, K. Seo
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4301.txt
Location
IP Authentication Header
RFC4302
S. Kent
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4302.txt
Location
IP Encapsulating Security Payload (ESP)
RFC4303
S. Kent
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4303.txt
Location
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC4305
D. Eastlake 3rd
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4305.txt
Location
Cryptographic Algorithms for Use in the Internet Key Exchange Version
2 (IKEv2)
RFC4307
J. Schiller
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4307.txt
Location
Cryptographic Suites for IPsec
RFC4308
P. Hoffman
Author(s)
2005-12-01
Date
http://www.ietf.org/rfc/rfc4308.txt
Location
IKEv2 Clarifications and Implementation Guidelines
RFC4718
P. Eronen, P. Hoffman
Author(s)
2006-10-01
Date
http://www.ietf.org/rfc/rfc4718.txt
Location
Page 125 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
ECP Groups For IKE and IKEv2
RFC4753
D. Fu, J. Solinas
Author(s)
2007-01-01
Date
http://www.ietf.org/rfc/rfc4753.txt
Location
IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature
Algorithm (ECDSA)
RFC4754
D. Fu, J. Solinas
Author(s)
2007-01-01
Date
http://www.ietf.org/rfc/rfc4754.txt
Location
Requirements for an IPsec Certificate Management Profile
RFC4809
C. Bonatti, S. Turner, G. Lebovitz
Author(s)
2007-02-01
Date
http://www.ietf.org/rfc/rfc4809.txt
Location
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC4835
V. Manral
Author(s)
2007-04-01
Date
http://www.ietf.org/rfc/rfc4835.txt
Location
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
RFC4868
S. Kelly, S. Frankel
Author(s)
2007-05-01
Date
http://www.ietf.org/rfc/rfc4868.txt
Location
Suite B Cryptographic Suites for IPsec
RFC4869
L. Law, J. Solinas
Author(s)
2007-05-01
Date
http://www.ietf.org/rfc/rfc4869.txt
Location
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC4945
B. Korver
Author(s)
2007-08-01
Date
http://www.ietf.org/rfc/rfc4945.txt
Location
The Transport Layer Security (TLS) Protocol Version 1.2
RFC5246
T. Dierks, E. Rescorla
Author(s)
2008-08-01
Date
http://www.ietf.org/rfc/rfc5246.txt
Location
Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
RFC5280
D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W.
Polk
Author(s)
2008-05-01
Date
http://www.ietf.org/rfc/rfc5280.txt
Location
AES Galois Counter Mode (GCM) Cipher Suites for TLS
RFC5288
J. Salowey, A. Choudhury, D. McGrew
Author(s)
2008-08-01
Date
http://www.ietf.org/rfc/rfc5288.txt
Location
Page 126 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4
TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
Counter Mode (GCM)
RFC5289
E. Rescorla
Author(s)
2008-08-01
Date
http://www.ietf.org/rfc/rfc5289.txt
Location
AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
RFC5647
K. Igoe, J. Solinas
Author(s)
2009-08-01
Date
http://www.ietf.org/rfc/rfc5647.txt
Location
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
RFC5656
D. Stebila, J. Green
Author(s)
2009-12-01
Date
http://www.ietf.org/rfc/rfc5656.txt
Location
Suite B Certificate and Certificate Revocation List (CRL) Profile
RFC5759
J. Solinas, L. Zieglar
Author(s)
2010-01-01
Date
http://www.ietf.org/rfc/rfc5759.txt
Location
Internet Key Exchange Protocol Version 2 (IKEv2)
RFC5996
C. Kaufman, P. Hoffman, Y
. Nir, P. Eronen
Author(s)
2010-09-01
Date
http://www.ietf.org/rfc/rfc5996.txt
Location
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)
RFC6125
P. Saint-Andre, J. Hodges
Author(s)
2011-03-01
Date
http://www.ietf.org/rfc/rfc6125.txt
Location
PKCS #1: RSA Cryptography Specifications Version 2.2
RFC8017
K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch
Author(s)
2016-11-01
Date
http://www.ietf.org/rfc/rfc8017.txt
Location
The Transport Layer Security (TLS) Protocol Version 1.3
RFC8446
E. Rescorla
Author(s)
2018-08-01
Date
http://www.ietf.org/rfc/rfc8446.txt
Location
z/OS Version 2 Release 4 TSO/E Customization
TSO.CUST
SA32-0976-40
Version
2019-07-12
Date
https://www-01.ibm.com/servers/re
sourcelink/svc00100.nsf/pages/zOSV2R4sa320976/$file/ikjb400_v2r4.pdf
Location
Page 127 of 127
Version: 1.3
© Copyright IBM Corp. 1994, 2021
Last update: 2022-01-10
IBM Corporation
Security Target for z/OS Version 2 Release 4