May 1 ’07

RACF Self-Assessment: Three Critical Areas to Examine

by Robert S. Hansel in z/Journal

Most large organizations continue to rely on the z/OS mainframe platform for support of their mission-critical core businesses and internal administration. So the security of the mainframe remains vital. Many z/OS installations rely on IBM’s RACF to protect their systems. RACF is a feature-rich product that can fully protect mainframe resources if implemented properly.

This article covers three areas of concern with RACF implementation—SURROGAT profiles, storage administration authority, and excessive access granted by default—and offers suggestions for addressing them.

SURROGAT Profiles

Surrogate authority lets a user perform tasks using another user’s identity and authority. In RACF, profiles in the SURROGAT class govern the use of surrogate authority. There  are four types of SURROGAT class resources:

  1. userid.SUBMIT lets a user submit a batch job with the identity and authority of user userid simply by coding USER=userid on the JOB card and without having to code the ID’s password. This authority is typically used to let a process, such as a job scheduler, automated operations task or CICS region, submit jobs with application batch IDs.
  2. userid.DFHSTART lets a user start a CICS transaction that will run with the identity and authority of user userid. The userid is specified in the EXEC CICS START command in a program. Selection of the ID is under the control of the programmer, not the user. Generally, only certain, designated IDs created specifically for this purpose should be used for started transactions. This check is made only if the CICS Systems Initialization Table (SIT) parameter XUSER= has been set to YES; otherwise, the action is allowed without any checking. The CICS systems programmer is usually responsible for setting this option.
  3. userid.DFHINSTL lets a) a CICS region use user userid as its default ID, b) a CICS region use user userid to execute its Program Load Table Post-Initialization (PLTPI) programs, c) a CICS administrator assign user userid as the pre-set ID for a terminal, and d) a CICS region or a terminal user use user userid for Automatic Transaction Initiation (ATI) (a.k.a. trigger transactions) associated with a transient data queue. The CICS default ID and PLTPI ID are assigned in the SIT parameters. Terminal pre-set IDs are defined in the CICS Systems Definition (CSD) file. ATI IDs are assigned in either the CSD or an EXEC CICS SET TDQUEUE program command. Ideally, only certain, designated IDs should be used for these various purposes. Again, these checks occur only if the SIT parameter XUSER= is set to YES. The CICS systems programmer is usually responsible for setting this and most of the other options previously mentioned.
  4. BPX.SRV.userid lets a user perform a z/OS Unix switch user (su) to change identities to user userid without having to enter the user’s password. The initiating user temporarily becomes user userid and acquires all the user’s authorities to include both Unix and z/OS access. This is primarily intended for use by z/OS Unix processes in conjunction with various default IDs.

Common problems that occur with SURROGAT profiles are threefold:

  1. CICS XUSER= SIT parameter is set to NO (the default value). This enables anyone with control over the CICS commands and parameters to assign any ID of their choosing and acquire whatever authority it might have.
  2. CICS-related SURROGAT profiles are too generic. Due to an apparent lack of understanding of their purpose, profiles of *.DFHSTART and *.DFHINSTL are found in many installations.
  3. SURROGAT userid.SUBMIT profiles let unprivileged terminal users (as opposed to process-type users) use IDs with higher-level permissions and privileges such as OPERATIONS authority. One installation had a single ID with OPERATIONS authority and more than 150 users with permission to submit jobs via a userid.SUBMIT profile. This is especially problematic when the installation has defined a profile such as *.SUBMIT or **. The latter could conceivably cover all forms of SURROGAT resources. Preferably, terminal users should never be given SURROGAT authority to any other IDs, but instead should perform tasks under their own IDs, which would be given whatever access authority they need. Adhering to this practice also makes it easier to trace the actions of a terminal user, since all work would be attributed to the user’s own ID.

Storage and Catalog Administration Controls

Storage administration is the management of data residing on DASD and tape; it entails such tasks as moving, copying, backing up, restoring, defragmenting, and compressing datasets and formatting volumes. Catalog administration involves managing these catalogs and catalog entries. These responsibilities are often assigned to the same individual. Some RACF authorities that allow administrators to perform their duties include:

Author’s Note: Having to control ISMF with PROGRAM class profiles is cumbersome and error-prone (e.g., failure to cite the correct programs and libraries). Please contact your IBM representative and request ISMF be re-designed to check STGADMIN resources to govern their use.

Excessive assignment of OPERATIONS authority almost always tops the list of common problems with RACF implementations . OPERATIONS authority certainly enables systems programmers, storage administrators, and even RACF administrators to do everything they presumably need to do . Unfortunately, it lets them go far beyond their needs with little or no limitation. Being one of the original RACF features, OPERATIONS was assigned to their IDs way, way back when, and once acquired, users are reluctant to relinquish it. OPERATIONS authority, however, is both inefficient and risky. If used exclusively for data management, bulk administrative actions result in a RACF access check for every individual dataset affected and, if OPERAUDIT is enabled as it should be, an SMF record is generated for each access as well. Conversely, a single check to a STGADMIN.ADR. STGADMIN profile may be sufficient to perform the entire task without another call to RACF.

Think of OPERATIONS as a double-edged sword. It will let you modify or delete almost any dataset, including ones you didn’t intend to affect. Remember what ALTER access to the catalogs allows; OPERATIONS may give you that ALTER access. It’s similar to Unix uid(0): if you don’t have it, you can’t shoot yourself in the foot. Replacement of OPERATIONS with STGADMIN profiles should be a priority in every installation. One successful approach is to:

This tends to placate them until they discover they don’t really need OPERATIONS. Once they’re satisfied, these authorities will meet their needs, and the alternate OPERATIONS ID can be eliminated.

Tip: To purposely block the use of OPERATIONS authority, do the following. Create a group (e.g., #NOOPER), connect all the OPERATIONS users to this group, and then permit this group access to the profiles guarding the resources you want to restrict. The access authority of the OPERATIONS users will be capped at whatever access level you specify in the permit. This is particularly effective for guarding catalog and DASDVOL resources.

Implementing STGADMIN profiles is clearly beneficial, but great care and caution are required in setting them up. Default access is frequently set too high, whether Universal Access (UACC) or permission to ID(*), thus giving everyone in the system the equivalent of OPERATIONS authority. The same is true for DASDVOL profiles for installations that use them. Only a few of the STGADMIN profiles are appropriate for granting all users access by default. Contrary to what is found on occasion, these profiles should never be put in WARN mode. Last, don’t forget to protect the ISMF programs.

Tip: To perform high-powered ISMF functions, users must make themselves an “Administrator.” They do so by changing their “user mode” via a series of ISMF panels that alter the user’s profile options. The act of changing oneself into an administrator turns on a bit in the user’s own ISPF profile. The ISMF program that turns on this bit is DGTFPF05. If you need to control the ISMF programs and don’t yet have the time to fully protect them, a quick fix is to define a profile to protect this one program. Granted, it doesn’t restrict anyone who has already turned this bit on nor would it stop someone from manipulating his or her own ISPF profile (if they could figure out which bit to activate), but it’s a start. This is a stopgap measure, not a long-term solution.

Excessive Access Granted by Default RACF guards only those resources you’ve told it to protect and only to the extent you specify. Here are some issues to consider in determining if you’re giving away too much:

Unprotected resources continue to plague most implementations. In particular, classes related to OPERCMDS and JES resources are often inactive. A major area of concern is FACILITY class resources. An amazingly wide array of resources can be protected using this class, but few installations know they exist.

Tip: To see what FACILITY class resources are being used in your environment, try turning on SETROPTS LOGOPTIONS(ALWAYS(FACILITY)). In some installations, doing this may generate an excessive number of SMF records, but most will find it acceptable. What it will reveal is sure to be most enlightening.

In the realm of excessively high UACCs and ID(*), focus most closely on operating system-related datasets. Of particular concern is default access of UPDATE or greater to Authorized Program Facility (APF) libraries—a common problem. The same goes for the linklist libraries, SMF archives, and Job Entry Subsystem (JES) spool and checkpoint datasets, to name a few. Of equal importance is ensuring default access is NONE for the RACF databases and any backups containing a copy.

Whereas tape dataset protection is usually active, effective control of the means of circumvention isn’t. Ensure BLP and use of EXPDT=98000 are strictly controlled.

While intended to serve as a performance enhancement feature, the GAT is often a security hole. Access permitted by the GAT overrides restrictions set in the profile. For instance, an entry in the GLOBAL DATASET profile of SYS1.**/ READ would allow all users READ access to RACF databases protected by profile SYS1.RACF* with UACC of NONE. GAT entries undercutting profile protections is a common problem, as is assigning WARNING to highly sensitive resources and leaving it on for years. Unless your installation generates and reviews daily monitoring reports of WARNINGs and weekly listings of profiles in WARN mode, you’re apt to overlook them.

Conclusion

RACF can provide excellent protection if properly implemented. Common areas of concern can be found in SURROGAT profiles, storage administration authority, and excessive access granted by default. Future articles will cover other areas of concern.

You now have the opportunity to address these issues before they become a problem. Remember, your auditor may have read this article, too, so be prepared for questions. Z