• Grant the primary ID of the OPERATIONS users all the other required forms of storage administrative authority
  • Give them an alternate ID with OPERATIONS authority
  • Remove the attribute from their primary ID.

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:

  • Undefined resources (i.e., no profile or inactive class): With datasets and many resources, no guarding profile means wide-open access. Unless the associated resource class issues a “notauthorized” return code of 8 for an unprotected resource (e.g., JESSPOOL), RACF assumes you don’t care if you don’t define it. A few resource managers take it upon themselves to protect resources when RACF doesn’t. CICS, for instance, forbids the use of transactions not defined to RACF. Some DFSMS utilities don’t perform certain functions unless RACF has given explicit approval. RACF administrators can address undefined dataset protection through activation of the SETROPTS PROTECTALL option. This option, however, is somewhat misnamed. It doesn’t really require the data to be protected; it merely requires it to be covered by a profile. The profile could have a UACC of ALTER, and this would satisfy PROTECTALL.
  • Universal Access (UACC): UACC is the default access all users are given— even those users unknown to RACF.
  • ID(*) access: ID(*) represents all users known to RACF. When permitted access in lieu of using the UACC, a prospective user must have first been authenticated by RACF before being allowed access. This is a minor step up in protection from UACC. Note to auditors: Remember when you told the RACF administrators they had to set all the UACCs to NONE? Unfortunately, when they “complied” with your audit requirement, they simply granted ID(*) whatever access level had been set for the UACC. Net change in protection: next to nil.
  • Tape dataset protection (TAPEDSN): RACF does not, by default, protect tape datasets. You need to tell it to do so by activating the SETROPTS TAPEDSN option. Certain combinations of CA-1 security options will serve the same purpose as having TAPEDSN active. New z/OS 1.8 parameters in the DEVSUPxx member of PARMLIB can ease the transition into full activation of TAPEDSN if it’s not active. Once tape protection is implemented, ensure facilities that could be used to circumvent it are controlled. These include Bypass Label Processing (BLP), which can be restricted with FACILITY class profile ICHBLP, and tape management system- specific profiles governing the use of EXPDT=98000 to bypass tape dataset name verification.
  • Global Access Table (GAT): The GAT consists of a list of resources everyone is permitted to access without requiring a full interrogation of the corresponding RACF profile. The GAT is constructed from profiles in the GLOBAL class. Each profile is itself a class name (e.g., DATASET). In each profile is the list of resources and level of access at which everyone is granted instant access. For more information on the GAT and other RACF performance tuning options, see “10 Ways to Improve RACF Performance” in the October/November 2006 issue of z/Journal.
  • WARNING: WARNING (a.k.a. WARN mode) is a profile option intended for temporary use in testing. Profiles in WARNING won’t fail a user’s access request even if the user doesn’t have sufficient access permission. If the user doesn’t have permission, RACF allows the access anyway (at up to and including ALTER level) and merely generates a console message and SMF record. Resources covered by profiles in WARNING aren’t protected.

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.


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

2 Pages