How can the USS HFS and zFS file systems be protected with ACF2?
Article ID: 28771
Updated On:
Products
Issue/Introduction
How can the USS HFS and zFS file systems be protected with ACF2?
Environment
Release: ACF2 R16
Component: ACF2MS
Resolution
The following describes the two options that sites can choose from to controlling access to the Hierarchical File System(HFS) and/or zFS.
With CA ACF2 Security, there are two processes that a site can use to secure the Hierarchical File System (HFS) and zFS. The first process is internal to z/OS UNIX System Services and is based on a UNIX model of security. The second process is external security and uses standard CA ACF2 security rules to secure the HFS/zFS. These processes are mutually exclusive, so your site must select which one to use.
Process One: Native z/OS UNIX System Services
z/OS UNIX System Services files are organized in a hierarchy as in a UNIX system. All files are members of the directory. Each directory is a member of another directory at a higher level of the hierarchy. The highest level of the hierarchy is the root directory.
Security for the file system directories and files is based on a UNIX model of security. Each file and directory is assigned an owning UID and an owning GID. This assignment is defined and saved in the file system, not in the external security product.
Normally each file or directory saves the access permissions in the form of four octal numbers nnnn. The first position represents special access flags while the remaining three are the permission categories. The access flags include the sticky bit, the setuid on execution, and the setgid on execution. The other three categories of users can access each directory and file in the HFS. They are:
- The user that owns the file
- The group that owns the file
- All other users defined to z/OS UNIX System Services
Three different access levels (READ, WRITE, and EXECUTE) can be set for any of these three categories. For example, permissions can be defined so that the file owner gets READ and WRITE access, a member of the file's group gets only READ access, and all other users get neither READ nor WRITE access.
Under CA ACF2, you must define a UID for each z/OS UNIX System Services user and a GID for each group that accesses z/OS UNIX System Services. You must also assign a default group in all z/OS UNIX System Services userids and give the users access to any supplemental groups needed.
For more information about the Hierarchical File System and setting file permissions, see the following IBM guides:
- z/OS V1R2.0 UNIX System Services User's Guide
- z/OS V1R2.0 UNIX System Services Planning
Under CA ACF2, you must define a UID for each z/OS UNIX System Services user and a GID for each group that accesses z/OS UNIX System Services. You must
also assign a default group in all z/OS UNIX System Services userids and give the users access to any supplemental groups needed.
Access Control Lists (ACLs) provide more granular control over the HFS file system than native HFS security. To activate the use of ACLs in the validation process, the only requirement is to specify HFSACL in the GSO UNIXOPTS record.
For more information about Access Control Lists (ACLs) and the ACF2 HFSACL field in the GSO UNIXOPTS record see the following guide:
- CA ACF2 for z/OS, Global System Option Records (GSO) section 'UNIX System Services Options (UNIXOPTS)'.
Process Two: CA SAF HFS security
HFS files are protected by file permission bit settings. These are set when the file owner creates the file. Centralized administration can only be performed by a superuser, a user privilege that grants much more authority than just security administration. z/OS resources are protected by access and resource rules, which are usually set up in advance by security administrators. Security administrators can be scoped in a decentralized environment.
CA SAF HFS security overcomes the shortcomings of native UNIX security by providing single-point security access control, administration, and reporting for both MVS and UNIX resources. CA ENF services present access events to CA ACF2 for validation. Administrators use familiar commands and rules to protect UNIX files and functions, restricting access based upon the CA ACF2 UID-string instead of the UNIX UID or GID numbers. HFS access loggings and violations are reported in the standard CA ACF2 reports.
When using CA SAF HFS security, native file permission bit security is bypassed, as well as the superuser authority to access any file. File access is validated by CA ACF2 security using resource rules. All the benefits of resource rules can be utilized, including masking, NEXTKEY, scoping, %CHANGE, and reporting. Certain extensions are available that allow user directories to be defined and to allow users to maintain rules for their own files.
Another consideration of HFS file validation is how user files are validated. User files are those files that are below a directory entry representing a specific user. CA SAF HFS security provides the ability for users to maintain their own resource rules, can generate resource names that can be identified as existing in a user directory, and can bypass validation for user access to files within the user's own directory.
Auditing records created by HFS/zFS file access, that is, violation, trace and logging records, are accessed through the same facilities as all other resource records, namely ACFRPTRV. In addition to all the standard items reported, the original, unmodified path name, up to 256 characters, is reported.
CA SAF HFS security is an application of CA ENF/USS (UNIX System Services). This security application is activated when both of these conditions are met:
1. Enable CAIENF DCM modules for handling events.
2. CA SAF HFS security is enabled.
For complete details on implementing CA SAF HFS security please see the CA ACF2- for z/OS section Controlling Access to the
Hierarchical File System, sub-section "Implementing CA SAF HFS Security".
Feedback
