Supported rules for CIS IBM z/OS V2R5 with RACF Benchmark v1.1.0
BMC AMI Security Policy Managersupports compliance testing for the following CIS controls. The titles and descriptions are from the CIS IBM z/OS V2R5 with RACF Benchmark documentation. For more information, register and download the CIS IBM z/OS V2R5 with RACF Benchmark v1.1.0 PDF file from: https://www.cisecurity.org/cis-benchmarks#cis_ibm_z/os_v2r5_with_racf_benchmark,_v1.1.0
In SPM, the CIS z/OS reports for RACF are identified by the CR0nnn naming convention. For example, for compliance rule CR08315:
- C = CIS
- R = RACF
- 0 = version 1.1.0
- 8315 = report 8.3.15
SPMsupports compliance testing for the following rules:
1.1.1 Ensure that the PASSWORD(INTERVAL) SETROPTS value is set to no longer than 90 days
Description:
When a user logs on to the system, RACF compares the system password interval value to the value specified in the user profile. RACF uses the lower of the two values to determine if the user’s password has expired.
PASSWORD(INTERVAL(n))command sets the maximum age of a password. The INTERVAL suboperand specifies the system default for the maximum number “n” of days that each user's password and password phrase remain valid.
If you have the SPECIAL attribute, you can specify the INTERVAL of the SETROPTS PASSWORD command. The INTERVAL suboperand specifies the system default for the maximum number of days that each user's password and password phrase remain valid.
1.1.2 Ensure that the PASSWORD(HISTORY) SETROPTS value is set to at least 4
Description:
HISTORYspecifies the number of previous passwords that RACF saves for each user ID and compares with an intended new password. If there is a match with one of the previous passwords, or with the current password, RACF rejects the intended new password. Set the PASSWORD(HISTORY(n)) RACF option “n” value to 4 or more.
PASSWORD(HISTORY(n))command enables you to specify the number of previous passwords and password phrases (1 - 32) that RACF saves for each user and compares it with an intended new value. For passwords, RACF stores only previous passwords in each user's history. For password phrases, RACF saves the user's current password phrase in addition to the user's previous password phrases. Therefore, for password phrases, RACF saves one fewer previous value than the number you specify for history.
Example: If you specify 12 for your HISTORY number using the command SETROPTS PASSWORD(HISTORY(12)) RACF saves up to 12 previous passwords and up to 11 previous password phrases for each user. Effective immediately, the values when executing that command are the default values for new users whom you define to RACF® through the ADDUSER command.
1.1.3 Ensure that the PASSWORD(RULEn) SETROPTS value(s) is set
Description:
SETROPTS PASSWORD(RULEn(LENGTH(m1:m2) content-keyword(position)))specifies an individual syntax rule for new passwords that users create at logon, on JCL jobcards, or on the PASSWORD command and for passwords specified on ALTUSER commands that have the NOEXPIRED operand. Eight syntax rules are allowed. Therefore, for the RULEn suboperand, the value of n is 1 - 8.
At a minimum require at least 8 characters with a mix of character types.
1.1.4 Ensure that the SETROPTS PASSWORD(MINCHANGE(n)) value will specified a value greater the zero (0)
Description:
SETROPTS PASSWORD(MINCHANGE(nnn)specifies the number of days that must pass between a user’s password and password phrase changes. Users can not change their own passwords and password phrases within the minimum change interval. Permitting users to change their password more than once in a day allows users to quickly cycle through their password history and maintain the same password indefinitely. The SETROPTS PASSWORD(MINCHANGE(nnn) value, either specified or defaulted, is in effect for all users. A security administrator may set a password within the MINCHANGE window.
1.1.5 Ensure that the PASSWORD(REVOKE) SETROPTS value is specified
Description:
SETROPTS PASSWORKD(REVOKE(nnn))enables you to specify how many consecutive incorrect password and password phrase attempts RACF permits before it revokes the user ID on the next attempt. If you specify a REVOKE SETROPTS value, ensure INITSTATS are in effect.
If SETROPTS NOREVOKE is in effect, consecutive incorrect passwords and password phrases are ignored.
1.1.6 Ensure that the KDFAES algorithm is used to protect passwords in the security database
Description:
By default passwords stored in RACF are protected using a weak DES based algorithm. Using off the shelf applications and hardware, it is a relatively simple operation to reverse engineer the encryption key – RACF user ID’s password – or perform a brute-force offline attack. Any user with access to RACF database may obtain the passwords for all user IDs in the system.
1.1.7 Ensure that the PASSWORD(WARNING) SETROPTS value is set
Description:
WARNINGspecifies the number of days before a password expires when RACF is to issue a warning message to the user.
1.2.1 Ensure that Inactive users are revoked
Description:
PASSWORD(INACTIVE(nnn))command specifies the number of days (1 - 255) that a user ID can remain unused and still be considered valid. RACF user verification checks the number of days since the last successful time the user accessed the system against the INACTIVE value and, if the former is larger, revokes the user's right to use the system.
INACTIVEdoes not apply to Protected user IDs. Protected user IDs are protected from being revoked through inactivity. If you specify INACTIVE, INITSTATS must be in effect. If the backup database is needed but does not contain current information, some user IDs can be revoked because they appear to have been unused beyond the number of days specified on the INACTIVE operand.
NOINACTIVEspecifies that RACF user verification is not to check user IDs against an unused-userid-interval.
Inactive user IDs are to be revoked after a period of inactivity not to exceed 90 days.
1.2.2 Ensure that STARTED class is used to assign users to Started Tasks
Description:
Started procedures have system generated job statements that do not contain the user, group, or password statements. To enable the started procedure to access the same protected resources that users and groups access, started procedures must have an associated user ID. If a user ID is not associated with the started procedure, the started procedure will not have access to the resources.
User ID can be assigned through the STARTED class or through the ICHRIN03 table. As it is easily auditable, does not require assembler knowledge or system IPL we would recommend the usage of the STARTED class.
1.2.3 Ensure user propagation is protected with the PROPCNTL class
Description:
Batch jobs that are user-submitted to the operating system should inherit the user ID of the submitter. This will identify the batch job with the user for the purpose of accessing resources. In some environments, such as CICS jobs submitted without the USER operand specified on the JOB statement run under a user ID other than the user submitting the job, in this case, the CICS user ID. This situation presents a security violation in that the issuer of the job will inherit the authority of the CICS user ID. The PROPCNTL Class was de-signed to prevent this from occurring. Utilize propagation control (PROPCNTL) for system-level address spaces that submit jobs on behalf of users.
1.2.4 Ensure that Job wait time option is set
Description:
In SMFPRMxx the JWT(n) parameter specifies the maximum amount of consecutive time that an executing job may spend as ineligible to use any CPU resources before being canceled for inactivity.
1.2.5 Ensure that started tasks defined with the trusted attribute are justified
Description:
Trusted Started tasks bypass RACF checking. It is vital that this attribute is NOT granted to unauthorized Started Tasks which could then obtain unauthorized access to the system.
1.2.6 Ensure that the OPERCMDS resource class is ACTIVE and RACLISTed
Description:
SETROPTS CLASSACT(OPERCMDS)specifies that the class OPERCMDS will have RACF protection is to be in effect for it.
These values become effective immediately after the command SETROPTS CLASSACT(OPERCMDS) is issued.
1.2.7 Ensure that CONSOLE resource class is ACTIVE and RACLISTED
Description:
MCS consoles can be used to issue operator commands. Failure to control access to MCS consoles could result in unauthorized personnel issuing sensitive operator commands.
1.2.8 Ensure that FACILITY resource class is ACTIVE and RACLISTED
Description:
SETROPTS CLASSACT(FACILITY)specifies that the class FACILITY class is active and that RACF protection is to be in effect for it.
These values become effective immediately after the command SETROPTS CLASSACT(FACILITY) and SETROPTS RACLIST(FACILITY) are issued.
1.2.12 Ensure that no expired digital certificates are used
Description:
The longer and more often a key is used, the more susceptible it is to loss or discovery. This weakens the assurance provided to a relying Party that the unique binding is secure.
1.3.1 Ensure that the use of RACF SPECIAL Attribute is justified
Description:
The SPECIAL user attribute allows full authorization to modify all profiles in RACF database and allows the user to perform all RACF functions, except those requiring AUDITOR or ROAUDIT attributes. The Group-Special attribute allows decentralized RACF control of datasets and resources. In cases where the scope of authority granted to a Group-Special Administrator has an impact on system security, the installation needs to be fully aware and approve its use. This privilege should be limited to the security group and administrators because of the extreme control that these users have.
1.3.3 Ensure that MCS console user ID(s) is protected
Description:
MCS consoles can be used to issue operator commands. When using the LOGON(AUTO) control, a user with the name of the MCS console will be used for access checking.
1.3.4 Ensure that all STARTED class profiles specify PROTECTED user IDs
Description:
Started procedures have system generated job statements that do not contain the user, group, or password statements.
2.1.4 Ensure that the ICHDSM00 program is protected
Description:
ICHDSM00 is the data security monitor utility. READ authority to this program in the PROGRAM class is one way a user can have authority to run the utility. RACF ships the utility in SYS1.LINKLIB. Further, SYS1.LINKLIB is generally one of the code libraries identified in the PROGRAM * or ** profile and is always treated as UACC(READ), even if the profile itself has a more restrictive UACC.
Therefore, a more specific PROGRAM profile should be defined to protect ICHDSM00.
2.1.5 Ensure that the IRRDPI00 program is protected
Description:
ICHDPI00 is the program that is used to update the dynamic parse function in RACF, and to refresh in-storage custom field data after making updates in the CFIELD class. READ authority to this program in the PROGRAM class is one way a user can have authority to run the program. RACF ships the program in SYS1.LINKLIB. Further, SYS1.LINKLIB is generally one of the code libraries identified in the PROGRAM * or ** profile, and is always treated as UACC(READ), even if the profile itself has a more restrictive UACC.
Therefore, a more specific PROGRAM profile should be defined to protect IRRDPI00.
2.1.8 Ensure the RACF security data sets and all copies are protected
Description:
RACF database files contain all access control information for the operating system environment and system resources as well as user registry, user permissions and user authentication data.
RACF data set rules for RACF security data sets and/or databases restrict READ access to auditors and processes which perform RACF database backup operations.
RACF data set rules for RACF security data sets and/or databases restrict READ and/or greater access to z/OS systems programming personnel, security personnel, and/or batch jobs that perform RACF maintenance.
All (i.e., failures and successes) data set access authorities (i.e. READ, UPDATE, ALTER, and CONTROL for RACF security data sets and/or databases are logged.
Note: Active and backup datasets, that may be split across multiple datasets, or any offloaded copy must be protected.
2.1.12 Ensure that memory and privileged program dumps are protected
Description:
Access to memory and privileged program dumps running Trusted Control Block (TCB) key 0-7 may hold passwords, encryption keys, or other sensitive data that must not be made available.
2.2.4 Ensure that access to datasets in the PARMLIB concatenation is controlled
Description:
The z/OS PARMLIB concatenation contains the parameters which control system IPL, configuration characteristics, security facilities, and performance.
This benchmark helps you make sure that RACF data set rules for the data sets in the PARMLIB concatenation:
- Allow appropriate (e.g., global READ) access.
- Restrict READ, UPDATE and ALTER access to only systems programming and required personnel.
- Restrict READ access to only system Level Started Tasks, authorized Data Center personnel, and auditors.
- Specify that all (i.e., failures and successes) UPDATE and/or ALTER access will be logged.
2.2.5 Ensure that access to all LPA libraries is controlled
Description:
LPA modules, once loaded into the Link Pack Area, are capable of performing APF-authorized functions.
This benchmark helps you make sure that RACF data set rules for LPA libraries:
- Allow appropriate access.
- Restrict UPDATE and/or ALTER access to only required personnel.
- Specify that all (i.e., failures and successes) UPDATE and/or ALTER access will be logged.
2.2.6 Ensure that access to the System Master Catalog is controlled
Description:
System master catalogs are the basis for locating all files on the system.
This benchmark helps you make sure that the following RACF data set rules are followed:
- RACF data set rules for System Catalogs allow appropriate access.
- RACF data set rules for the Master Catalog restrict greater than READ access to only required personnel.
- RACF data set rules for the Master Catalog specify that all (i.e., failures and successes) greater than READ access will be logged.
2.2.7 Ensure that access to all APF-authorized objects is controlled
Description:
The Authorized Program List (APF) designates those libraries that can contain program modules which possess a significant level of security bypass capability.
extattr +a <program-path-name>can grant the same capability in the Unix file system.
This benchmark helps you make sure that:
- RACF data set rules for APF libraries allow appropriate access.
- APF libraries should only be accessible in UPDATE and/or ALTER to z/OS system programmers.
- The MVS.SETPROG and MVS.SET.PROG profiles in the OPERCMDS class are limited to system programmers. The BPX.FILEATTR.APF profile in the FACILITY class should also be limited to system programmers.
- Failures and successes should be logged for APF libraries.
2.2.8 Ensure that access to SYS1.SVCLIB is controlled
Description:
The SYS1.SVCLIB data set is automatically APF-authorized, contains system SVCs, and may also contain I/O appendages.
This benchmark helps you make sure that RACF data set rules for SYS1.SVCLIB specify that all (i.e., failures and successes) UPDATE and/or ALTER access will be logged.
SYS1.SVCLIBmust only be accessible in UPDATE and/or ALTER to z/OS system programmers. All update and allocation access must be logged and reviewed.
2.4.3 Ensure that access for Surrogate users is controlled
Description:
Surrogate users have the ability to submit jobs on behalf of another user (the execution user) without speci-fying the execution user's password.
Jobs submitted by surrogate users run with the identity of the execution user.
3.1 Ensure that the command violations are being logged
Description:
SETROPTS CMDVIOL specifies whether RACF is to log violations detected by RACF commands. You must have the AUDITOR attribute to specify these options.
CMDVIOL
Specifies that RACF is to log violations detected by RACF commands (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH) during RACF command processing. A violation might occur because a user is not authorized to modify a particular profile or is not authorized to enter a particular operand on a command.
These values become effective immediately as:
When RACF is using a newly initialized database OR when the command SETROPTS CMDVIOL is issued.
Ensure that no RACF-protected resources will be created or accessed.
3.2 Ensure that activity of SPECIAL users are being logged
Description:
SETROPTS SAUDIT specifies whether RACF is to log RACF commands issued by users with the SPECIAL or group SPECIAL attribute. You must have the AUDITOR attribute to specify these operands.
SAUDIT
Specifies that RACF is to log RACF commands (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH) issued by users who either had the SPECIAL attribute or who gained authority to issue the command through the group-SPECIAL attribute.
These values become effective immediately when RACF uses a newly initialized database OR the command SETROPTS SAUDIT is issued.
SAUDIT specifies whether RACF is to log all RACF commands issued by users with the SPECIAL or group SPECIAL attribute. The system-wide options control the default settings for determining how RACF will function when handling requests for access to the operating system environment, RACF, and customer data. RACF provides the ability to set a number of these fields at the subsystem level. If no setting is found, the system-wide defaults will be used. The improper setting of any of these fields, individually or in combination with another, can compromise the security of the processing environment. In addition, failure to establish standardized settings for RACF control options introduces the possibility of exposure during migration process or contingency plan activation.
Ensure that RACF is to log commands issued by a user with SPECIAL attribute.
3.3 Ensure that the AUDIT SETROPTS value is set for all classes
Description:
SETROPTS AUDIT(xx) specifies the names of the classes for which you want RACF to perform auditing. For the classes you specify, RACF logs all uses of the RACROUTE REQUEST=DEFINE SVC and all changes made to profiles by RACF commands. When the class specified is USER, RACF logs all password and password phrase changes made by RACROUTE REQUEST=VERIFY. (RACF adds the classes you specify to those already specified for auditing.) The valid class names are USER, GROUP, DATASET, and those defined in the class descriptor table.
If you specify an asterisk (*), logging occurs for all classes. You must have the AUDITOR attribute to enter the AUDIT operand.
These values become effective immediately as the command SETROPTS AUDIT(xx) is issued
3.4 Ensure that activities of users with the OPERATIONS attribute are logged
Description:
SETROPTS OPERAUDIT specifies whether RACF is to log all actions allowed only because a user has the OPERATIONS (or group-OPERATIONS) attribute. To perform these actions the AUDITOR attribute must be set.
OPERAUDIT
Specifies that RACF is to log all actions, such as accesses to resources and commands, allowed only because a user has the OPERATIONS or group-OPERATIONS attribute.
Once the command SETROPTS OPERAUDIT is issued these values become effective immediately.
Ensure that commands issued by users with OPERATIONS attribute is logged.
3.5 Ensure that Logon statistics are recorded
Description:
SETROPTS INITSTATS specifies that statistics available during RACF user verification are to be recorded. These statistics include the date and time the user was verified by RACF, the number of user verifications that specified a particular group, and the date and time of the user last requested verification with a particular group. If you specify INACTIVE, REVOKE, or WARNING, INITSTATS must be in effect. For applications that specify the APPL operand on the RACROUTE REQUEST=VERIFY macro, you can define a profile in the APPL class to specify that the application needs only daily statistics recorded for its users. To do this, specify the RACF-INITSTATS(DAILY) string in the APPLDATA field.
Ensure strong security controls by recording statistics of RACF user verification.
3.6 Ensure RACF AUDITOR or ROAUDIT privilege is assigned only to users with auditing mission.
Description:
A user having the AUDITOR attribute has the authority to specify logging options, gives control of logging SMF data and list auditing information.
3.7 Ensure that effective SMF records collection options are set
Description:
SMF data collection provides a standardized method for recording all system activity to a recording media (file or logstream). including the audit trails from RACF.
Some recording options are mandatory to ensure an effective recording of the activity and therefore complete audit trails.
3.8 Ensure that an automated process is in place to collect and retain SMF data
Description:
SMF data collection provides a standardized method for recording all system activity to a recording media (file or logstream). including the audit trails from RACF.
3.9 Ensure that Required SMF data record types is collected
Description:
SMF data collection provides a standardized method for recording all system activity to a recording media (file or logstream). including the audit trails from RACF.
All SMF records are uniquely identified by a type and an optional subtype value. The type and subtype values reside in the header portion of the SMF record. A record type can reside in the Standard SMF record header or in the Extended SMF record header. Subtype values always reside in the Standard SMF record header.
3.10 Ensure that RACF audit logs is reviewed on a regular basis
Description:
Logging, the recording of data about specific events, is the key to auditing the use of RACF at your installation. But you also need to ensure the logs are reviewed at least daily.
7.1.3 Ensure CSFINPV2 requires signature verification
Description:
Certain z/OS load modules can have an associated signature generated by IBM that is verified by the system when the module is loaded into system storage for execution. The way to ensure the signature verification occurs is by defining a profile in the PROGRAM class with the SIGVER segment.
8.3.1 Ensure that JESJOBS CLASS is set up
Description:
The JESJOBS class controls access to job level resources. The high-level qualifier for entities in this class are used to specify which functions are being controlled. When defining resources in the JESJOBS class, avoid generic high-level qualifiers such as ‘*’ as these could have impacts beyond the original intended purpose (especially as new resources are added to the class).
8.3.2 Ensure CANCEL JESJOBS profiles are protected
Description:
Resources with a CANCEL high-level qualifier in the JESJOBS resource class control the use of the cancel SSI 2 (used by the CANCEL TSO command) and the cancel function of the job modify SSI 85. Canceling jobs can cause the job to terminate the current phase of processing and optionally purge the job from the system.
8.3.4 Ensure GROUPREG JESJOBS profiles are protected
Description:
JCL writers can define dependencies between job using a structure called a JOBGROUP. A JOBGROUP is a set of JCL that defines the dependencies between jobs and a set of JCL jobs streams that are part of the JOBGROUP. JESJOBS resources with a high-level qualifier of GROUPREG control what jobs can be added to a JOBGROUP when the owner of the JOBGROUP is not the same as the owner of the JOB. Failure to protect this resource may allow unauthorized users to add jobs to a JOBGROUP that they do not own.
8.3.5 Ensure HOLD JESJOBS profiles are protected
Description:
Resources with a HOLD high-level qualifier in the JESJOBS resource class control the use of the hold function of the job modify SSI 85. Holding a job delays processing until the job is released.
8.3.6 Ensure JOBCLASS JESJOBS profiles are protected
Description:
Resources with a JOBCLASS high-level qualifier in the JESJOBS resource class control the use of the job classes. Attributes of a job class such as bypass label processing (BLP) need to be restricted to appropriate users. Additionally, job classes can be associated with batch initiators that are reserved for appropriate applications.
8.3.7 Ensure JOBNFY JESJOBS profiles are protected
Description:
Resources with a MODIFY high-level qualifier in the JESJOBS resource class control the use of the HTTP post notification of job status. Users of the JOBS REST API (and the internal reader) can specify an address where a HTTP POST notification is sent when certain job transitions occur (such as the job completes).
8.3.8 Ensure MODIFY JESJOBS profiles are protected
Description:
Resources with a MODIFY high-level qualifier in the JESJOBS resource class control the use of the modify job function of the job modify SSI 85. Modifying a job can change the attributes of a job such as the job class, service class, system affinity, and priority.
8.3.9 Ensure PURGE JESJOBS profiles are protected
Description:
Resources with a PURGE high-level qualifier in the JESJOBS resource class control the use of the purge function of the job modify SSI 85. Purging a job removes the job from the system.
8.3.10 Ensure RELEASE JESJOBS profiles are protected
Description:
Resources with a RELEASE high-level qualifier in the JESJOBS resource class control the use of the release function of the job modify SSI 85. Releasing a job could allow a job to begin processing prematurely.
8.3.11 Ensure REROUTE JESJOBS profiles are protected
Description:
Resources with a REROUTE high-level qualifier in the JESJOBS resource class control the use of the reroute function of the job modify SSI 85. Rerouting a job sends a job (with any instream data) to another NJE note for execution (or could cause an NJE bound job to execute locally).
8.3.12 Ensure SPIN JESJOBS profiles are protected
Description:
Resources with a SPIN high-level qualifier in the JESJOBS resource class control the use of the spin function of the job modify SSI 85. Spinning a job caused all SPIN output of a job to be made available for immediate processing (rather than waiting for the job to end). SPIN output could include logs associated with the running job. Processing could include purging of the data sets that were spun.
8.3.13 Ensure SPOOLIO JESJOBS profiles are protected
Description:
Resources with a SPOOLIO high-level qualifier in the JESJOBS resource class control the use of the SPOOL I/O function of the job information SSI 71. The SPOOL I/O function is intended for application to access data on the JES2 spool for debugging purposes.
8.3.14 Ensure START JESJOBS profiles are protected
Description:
Resources with a START high-level qualifier in the JESJOBS resource class control the use of the start function of the job modify SSI 85. Starting a job causes a job to begin processing immediately (starting an initiator if required). This could cause a job to begin processing prematurely.
8.3.15 Ensure SUBMIT JESJOBS profiles are protected
Description:
Resources with a SUBMIT high-level qualifier in the JESJOBS resource class control the submitting of batch jobs from all sources. By using these resources, you can control the combination of job names, owning user IDs, and submitting user IDs that can be used.
9.20 Ensure that data sets used as step libraries in /etc/steplib are configured
Description:
The STEPLIBLIST parameter specifies the pathname of the HFS file that contains the list of MVS data sets that are used as step libraries for programs that have the set-user-id or set group id permission bit set. The use of STEPLIBLIST is at the site’s discretion, but if used the value of STEPLIBLIST should be /etc/steplib. All update and alter access to the MVS data sets in the list will be logged and only systems programming personnel should be authorized to update the data sets.
9.27 Ensure that data sets containing user file systems do not have the user ID as the high-level qualifier
Description:
A naming convention is generally established when allocating new zFS user file systems for a UNIX user to have as their home directory. If the high-level qualifier for this data set is the user’s RACF user ID, then the user has read and write access to it outside of the UNIX environment where UNIX authorization checks are not made.
9.5 Ensure that newly assigned UIDs and GIDs are unique values
Description:
When users and groups share UIDs and GIDs, respectively, they are essentially the same entity to the UNIX kernel.
9.7 Ensure that RACF Classes required to secure the z/OS UNIX environment are active
Description:
The FACILITY, SURROGAT, and UNIXPRIV class support profiles used to secure the z/OS UNIX (OMVS) environment.
UNIXPRIV class profiles are used to manage certain system privileges that are typically associated with z/OS UNIX superuser authority. By defining UNIXPRIV class profiles, certain individual superuser privileges can be granted to users who do not have superuser authority. This reduces the security risks associated with assigning full superuser authority to users.
SURROGAT class profiles are only needed if there are servers (e.g., a web server) running in the z/OS UNIX environment that must be able to act with the security context of a client and that client does not supply a password or other authenticator for RACF.
FACILITY class profiles are used by a variety of IBM components including UNIX System Services (OMVS). BPX prefixed profiles in this class are critical to the proper security of the z/OS UNIX environment.
9.8 Ensure that RACF Classes required to secure the z/OS UNIX environment are RACLISTed
Description:
RACF provides the ability to load certain classes of profiles into memory for better performance with the SETROPTS RACLIST command. For some classes, RACLISTing is required, but it does not happen automatically.
UNIXPRIV class profiles are used to manage certain system privileges that are typically associated with z/OS UNIX superuser authority. By defining UNIXPRIV class profiles, certain individual superuser privileges can be granted to users who do not have superuser authority. This reduces the security risks associated with assigning full superuser authority to users.
SURROGAT class profiles are only needed if there are servers (e.g., a web server) running in the z/OS UNIX environment that must be able to act with the security context of a client and that client does not supply a password or other authenticator for RACF.
FACILITY class profiles are used by a variety of IBM components including UNIX System Services (OMVS). BPX prefixed profiles in this class are critical to the proper security of the z/OS UNIX environment.
9.18 Ensure that the BPXROOT user account is configured
Description:
The z/OS Unix System Services function “"setuid” can be used to change the UID of the process. When the UID requested is UID=0, the user set as SUPERUSER in BPXPRMxx is used. The default user is BPXROOT.
9.30 Ensure that file systems containing critical data are protected from access using profiles in the FSACCESS class
Description:
Critical data can be stored within zFS file systems. Access to files and directories is controlled by z/OS UNIX mechanisms such as UID(0), file ownership, file permission and access control lists. Using profiles in the FSACCESS class, you can restrict the ability to cross a mount point into a zFS file system to only those explicitly permitted in the profile. This overrides even UID0) authority. Once you have crossed the mount point, UNIX rules apply when accessing files and directories within that file system.
File systems containing critical data should be protected with an FSACCESS profile.
9.31 Ensure that file systems are mounted read-only wherever possible
Description:
Some zFS file systems contain data that is not expected to change. For example, a file system may be dedicated to containing the binary executables of a specific application. You generally do not expect this data to change until the next time you apply service.
9.32 Ensure that file systems are mounted with set-id files disabled wherever possible
Description:
Set-user-ID and set-group-ID files are those containing executables that run under the identity of the file owner rather than the person running the executable. These are often the target of attackers. On the other hand, some applications rely on these types of files to operate as expected. Any file system that is not expected to contain set-id files should be mounted in NOSETUID mode. In this mode, the set-user-ID and set-group-ID bits in the file mode are ignored.
9.33 Ensure that no file systems are mounted with security disabled
Description:
If a file system is mounted with the NOSECURITY option, everyone has all access to every object in the file system. In a production environment, no file system should be mounted with this option.