close window

Print print

Addressing Common RACF Configuration Issues

In my 15 years as a RACF* "hired gun," I've found that the issues I've been asked to resolve fall into one of two broad categories: technical and design. Generally, the technical issues are easier to solve. Often discovered in the RACF database-either accidentally or using analysis tools-most cause little real harm and are likely nuisances due to misunderstanding the provided protection levels. However, these small errors can be the root of larger exposures and must be rectified wherever possible. The following are some of the top technical issues I've encountered.

The IBMUSER default account-When installing a new RACF system, this is the only user ID available at the first IPL, and it has the default password, IBMUSER, which should be used to create another user ID with the System Special attribute. That user ID is then tested, after which you can revoke IBMUSER forever.

Subsequent attempts to delete IBMUSER generally fail because RACFs "early code" automatically recreates it. Sometimes these attempts can actually damage the database, and, in worst-case scenarios, the database may appear undamaged even though a major security exposure has been created. It's possible to "orphan" IBMUSER, leading to a situation where an administrator with Group Special authority can become IBMUSERs owner. To do this, add a RACF group with the same name as the "missing" owner of IBMUSER, and the administrator will receive Group Scope over IBMUSER, a user ID with system-wide Special authority, which can be very handy.

An all too common practice is to keep IBMUSER active and in use. This is considered a risk, as it's the only default account defined in the publicly available RACF information.

Default passwords on user IDs and the default RVARY password-When the ADDUSER command is issued with only a new user ID specified, the new user ID receives a default password. The default password of all new user IDs in RACF is the name of the default group to which the user ID is connected when created or the Administrators Default group if no group is specified.

Often a user ID is created, then moved to a default group as a separate action, which depends completely on site-procedure intricacies. In this case, an unused user ID's potential password includes the user ID's current default group and the default group of system administrators or other user IDs with Special authority that may have issued the initial ADDUSER command.

The default RVARY password is "YES," entered at the system console. Use the SETR LIST command to check if the default has been changed at your site. It's important to establish operational procedures around the use of this password so that, if the password is changed, the new value isn't forgotten or lost. As a saving grace, any RACF System Special user can use a SETROPTS command to set the RVARY password without knowing the current value.

System Special or Operations attribute on a non-personal use user ID-Except in the limited case of user IDs used to perform background RACF work-such as housekeeping reports or automatic revoke/resume actions-there should never be a requirement to grant a batch process a RACF attribute related to issuing commands.

System Special is one such attribute and should only be found on personal user IDs or highly restricted batch processes. A system-wide Operations attribute has some history of being used for batch processing. For many years now, its use has been widely discouraged and indicates poor housekeeping or a lack of appropriate RACF controls if access to data sets is granted via Operations.

This situation is privilege escalation waiting to happen. The number of people outside the authorized administrators who may have the ability to schedule or otherwise control the actions of these user IDs is potentially huge. Without a thorough understanding of the site's operations infrastructure, it's difficult to gauge just who may be able to issue RACF commands in this scenario. RACF commands must be restricted to authorized and accountable personnel only, even in a relatively low-security environment.

Authorized Program Facility (APF) library control-The ability to place a program in an APF-authorized library is a critical control point for system integrity. Security administrators should make it their responsibility to know which data sets are in the APF list; if they run with LNKAUTH=LNKLST in Parmlib member IEASYSxx for example, they must include the link list in their list of highly sensitive system data sets. They should make sure every data set in the list is protected from any form of unauthorized update and that auditing records are written for every attempted update.

Class SURROGAT profiles with very generic profiles-This class allows user IDs to access the privileges of other user IDs by submitting work under their authority without requiring a password. What administrators sometimes forget is that these profiles are just like any other RACF profile, and when defined as generic they can represent a range of user IDs. Take for example a class SURROGAT profile consisting simply of "**" or "*.*" (sometimes called a catchall profile). It applies to all user IDs that aren't matched by a more specific profile and probably covers your user ID unless steps have been taken to avoid this. Access to this kind of profile via an entry in the access list may allow someone to issue RACF commands in batch.

CICS* data sets able to be updated by the CICS started-task user ID-Often the CICS started-task user ID is given UPDATE or ALTER on all data sets used by the CICS region. Sometimes the CICS user ID is connected to the group responsible for maintaining CICS-related data sets.

Another common occurrence is that data sets used by the CICS region have a high-level qualifier the same as the user ID of the region. All these scenarios result in the CICS user ID being capable of updating the APF libraries used by CICS-a situation that leads to the aforementioned APF exposures.

CICS Category 1, 2 and 3 transaction definitions-There are clear recommendations about the use of CICS Category 1, 2 and 3 transactions in the CICS RACF Security Guide:

  • Category 1 includes system transactions that must be permitted to the CICS region user IDs and must never be issued at a terminal. There's no reason any user-even in CICS system support-should ever need access to these. Documentation warns that issuing these transactions at a terminal can have "unpredictable results"-I read that as "may crash your system." 

     

  • Category 2 includes the maintenance- and systems-programming transactions that must be restricted to appropriate support personnel only.

     

  • Category 3 includes transactions to which all CICS users must have access. These transactions work as if they had UACC(READ), no matter what definition may be placed in RACF for them, and CICS never checks access to these. Examples include CESN and CESF (sign on/off). I prefer to define these transactions with UACC(READ) or the effective equivalent, as this reflects the reality.

Groups owned by user IDs and user IDs owned by user IDs-This is somewhat of a pet dislike of mine and, while not actually a configuration error, it often causes confusion if someone receives unexpected administrative rights over resources in the database due to ownership. Some sites choose to exploit this to their advantage. However, in my experience, where user IDs own individual profiles in the RACF database, this is usually accidental or an error. Specific analysis tools, or a relational database representing RACF, are usually required to reveal these instances.

Global Access Table (GAT) not synchronized with profiles in the matching resource class-It's recommended that any profile in the GAT be backed by a profile granting the same level of access in any resource classes the GAT covers. This preserves access granted via the GAT, in the event a GAT profile is accidentally deleted.

 

GAT profiles are a Resource Grouping profile and grant access to many resources via their Member resource list. If GAT profiles arent backed up by normal RACF profiles in the matching class, the accidental deletion of one GAT profile can be catastrophic, affecting many users system access. Remember, the GAT is often used to grant access to resources necessary just to logon; without these the system can't be accessed. Always consider carefully the ramifications of using the GAT, because access granted in this way provides no SMF Audit trail.
 

Tasks unnecessarily running Trusted or Privileged-A CICS region, running as a started task with either the Privileged or Trusted attributes, will pass these high-level security privileges to any batch job submitted from a CICS transaction to the z/OS* Internal Reader. Unless further controls are in place-even if a CICS region isn't running as a started task-any high-level system access is inherited by "spawned" batch jobs.

 

If CICS is running as a started task with the Trusted or Privileged attributes, it potentially opens up RACF command authority to the development community. Only the most rigorous of Change Control and Peer Review processes can compensate for an exposure of this magnitude.

 

No catchall in STARTED and poor definition in ICHRIN03-Similar to badly defined SURROGAT class profiles, this allows privilege escalation by default. Without a catchall generic profile of some kind in the class STARTED, a previously undefined started task will fall back to the contents of ICHRIN03. A local-systems programmer who has been content to leave it completely alone since RACF introduced the STARTED class nearly 10 years ago probably maintains this. If fallback to ICHRIN03 can happen, you need to know what privileges it's granting. These can include the same Privileged and Trusted attributes that can be used to bypass both security and the audit trail.

 

Additionally, the catchall profile must be carefully designed to limit the user IDs that can be used as a Started Task. All undefined Started Tasks inherit a previously defined user ID that possesses little or no access. Another approach is to allow the Task to run with the same user ID as the Task Name and enforce that this user ID be connected to a specific Group. This way, the task wont initiate unless the Group connection is present and you have maintained control as a RACF administrator. The following RACF command provides an example of this second method:

 

RDEFINE STARTED *.* STDATA(STUSER(=MEMBER) STGROUP(STCGROUP))

 

Enhanced Generic Naming (EGN) conversion hangovers and the double-asterisk versus single-asterisk profile-Most sites converted to EGN many years ago when it was first introduced in RACF. This standardized the approach to resource names across all RACF classes and is highly encouraged to avoid confusion in resource definitions. A typical example of the hangover created by the conversion is the existence of dataset profiles like CICS.*.** and CICS.**. Given the data set CICS.TEST, which profile will RACF select for access-list checking? Ill leave the answer as an exercise for the curious (consult the URL at the end of the article).

 

A similar issue is the inability to use RACF commands to view a profile consisting solely of a single asterisk: "*". RACF command processing treats an RLIST STARTED * as a request to list every profile in the class STARTED rather than list the single-asterisk profile. For this reason, I recommend never creating a single-asterisk profile. Always use a double asterisk "**" and then both forms of the command will return the expected results.

 

User IDs that have never logged on-Do a search of your database for user IDs that have never logged on and those with a Passdate field of all zeroes and expiration of all nulls. Some of these user IDs are likely to have passwords the same as their Default Group and, because they've never logged on, the revoke count in days since the last sign on has never started. I recommend that all user IDs be created "revoked" until ready for use. Another equally effective method is to issue the ALTUSER RESUME command on any newly created user ID. This has the effect of setting the Last Use date to today, and the user ID will now be revoked according to the expected RACF password-age processing.

 

The magic Supervisor Call routine (SVC)-This is a tool used widely in the past by systems programmers to gain emergency access when repairing a system. An SVC is trusted system code and can invoke machine instructions normally unavailable to end users.

The magic SVC-or authorization SVC-is no longer required. All of the abilities required to perform this function can now be done using z/OS operator commands under the control of RACF profiles, and auditability and accountability can be properly maintained.

PROGRAM class profiles out of synchronization with actual programs on disk-The use of PROGRAM class profiles is problematic during system upgrades and other operational changes. Used to control access to specific program copies contained in a specific data set on a specific DASD volume, PROGRAM class profiles are affected by changes in DASD volume labels and/or data-set names. Many sites discover problems during an upgrade when and if these values are changed. It's good practice to have at hand the contents of your PROGRAM class profiles and to use the generic six asterisks to stand in for the system IPL volume wherever possible. For recent releases of RACF, you can also leave the volume serial entirely.

These are only a few of the most prevalent issues I encounter as a consultant. Until my next article, may your RACF database stay in referential integrity with itself.

In my 15 years as a RACF "hired gun," I've found that the issues I've been asked to resolve fall into one of the two broad categories: technical and design.