From z/OS RACF STIG
Part of ZUSS0031
Associated with IA controls: DCCS-1, ECCD-2, DCCS-2, ECCD-1
Associated with: CCI-000213 CCI-001499
For the z/OS UNIX environment, there are MVS data sets that contain operating system components, MVS data sets that contain HFS file systems with operating system components, and MVS data sets that contain HFS file systems with application system and user data. All of these MVS data sets require definitions in the ACP to enforce desired access controls. In addition, the UNIX permission bits must be properly set on the HFS directories and files to enforce desired access controls.
a) Refer to the following report produced by the UNIX System Services Data Collection: - PARMLIB(BPXPRMxx) Refer to the following report produced by the Data Set and Resource Data Collection: - SENSITVE.RPT(HFSRPT) Automated Analysis Refer to the following report produced by the Data Set and Resource Data Collection: - PDI(ZUSS0031) b) If the ACP data set rules for the data sets referenced in the ROOT and the MOUNT statements in BPXPRMxx restrict update access to the z/OS UNIX kernel (i.e., OMVS or OMVSKERN) there is NO FINDING. c) If the ACP data set rules for the data set referenced in the ROOT and the MOUNT statements in BPXPRMxx restrict update and/or allocate access to systems programming personnel there is NO FINDING. d) If (b) or (c) above is untrue, this is a FINDING.
Review the access authorizations defined in the ACP for the MVS data sets that contain operating system components and for the MVS data sets that contain HFS file systems and ensure that they conform to the specifications below Review the UNIX permission bits on the HFS directories and files and ensure that they conform to the specifications below: The ACP data set rules for the data sets referenced in the ROOT and the MOUNT statements in BPXPRMxx restrict update access to the z/OS UNIX kernel (i.e., OMVS or OMVSKERN The ACP data set rules for the data set referenced in the ROOT and the MOUNT statements in BPXPRMxx restrict update and/or allocate access to systems programming personnel The ROOT parameter specifies data for the file system that is to be mounted as the root file system for z/OS UNIX. ROOT can have a number of sub-parameters; the FILESYSTEM and SETUID|NOSETUID sub-parameters have security considerations. FILESYSTEM can be used to specify the name of the MVS HFS data set that holds the root file system. As the highest point in the HFS hierarchy, this file system is critical to system operations. Therefore appropriate ACP access rules must be written to protect the named data set. Update and alter access must be restricted to the z/OS UNIX kernel and individual systems programming personnel. The SETUID|NOSETUID sub-parameter specifies whether or not the set-user-ID or set-group-ID permission bits are supported. SETUID|NOSETUID also impacts the APF authorized and program-controlled extended attributes. For the root file system, SETUID must be specified for normal operations. The MOUNT parameter specifies data for a file system that is to be mounted by z/OS UNIX. There are usually multiple MOUNT statements and each can have a number of sub-parameters. The FILESYSTEM, SETUID|NOSETUID, and SECURITY|NOSECURITY sub-parameters have significant security considerations. FILESYSTEM can be used to specify the name of the MVS HFS data set that holds the logical file system. Appropriate ACP access rules must be written to protect the named data set. Update and alter access must be restricted to the z/OS UNIX kernel and to individual systems programming personnel. The SETUID|NOSETUID sub parameter specifies whether or not the set-user-ID or set group ID permission bits are supported. SETUID|NOSETUID also impacts the APF authorized and program-controlled extended attributes. SETUID may be specified for those file systems that contain only vendor-provided software or that have been documented to the IAO as requiring this support. Otherwise NOSETUID must be specified. The SECURITY|NOSECURITY sub-parameter specifies whether security checks are performed. SECURITY must be specified unless a specific exception for the file system has been identified and documented to the IAO. Regardless of IBM defaults, the values for SETUID|NOSETUID and SECURITY|NOSECURITY must be explicitly coded to protect against potential vendor changes and to simplify security reviews. Security rules must be defined to prevent unauthorized changes to the z/OS UNIX components in MVS data sets. Because z/OS UNIX is integrated with the z/OS base control program, many of the z/OS UNIX components reside in data sets that are protected by security definitions specified elsewhere. The data set names (or masks) unique to z/OS UNIX that may require additional definitions are listed in this section. Data sets in conventional MVS formats (e.g., PDS) and those in HFS format are listed. There is also a note on security for user MVS data sets in HFS format. The following HFS format data sets are unique to z/OS UNIX and require security definitions: MVS DATA SETS CONTAINING HFS DATA DATA SET NAME/MASK MAINTENANCE TYPE SYS1.OE.ROOT Target SYS3.OE.ETCFILES Target These data sets should have all access restricted to systems programming personnel and to the z/OS UNIX kernel userid OMVS. The site may choose different names for these data sets, but the access restrictions must be maintained. There may be additional data sets that contain system HFS data. Any data set that specifies a file system that is at the root level (e.g., /tmp, /u) must also have all access restricted to systems programming personnel and to the z/OS UNIX kernel userid. Depending on the number of users defined in a given z/OS UNIX image, there may be a need to define individual MVS data sets to hold their personal HFS format data. These data sets must be protected in accordance with the existing security guidelines for user data. However, there is a need for special additions to those rules. The z/OS UNIX kernel userid OMVS must have update access to all user HFS data sets. Also, users must not have update access to the MVS data sets so that HFS permission controls cannot be altered outside of the z/OS UNIX environment.
Lavender hyperlinks in small type off to the right (of CSS
class id, if you view the page source) point to
globally unique URIs for each document and item. Copy the
link location and paste anywhere you need to talk
unambiguously about these things.
You can obtain data about documents and items in other
formats. Simply provide an HTTP header Accept:
text/turtle or
Accept: application/rdf+xml.
Powered by sagemincer