Detecting ACEE modifications

The ACEE (accessor environment element) is a control block that contains a description of a user's security environment, including user ID, current connect group, user attributes, and group authorities. An ACEE is constructed during user identification and verification, using information in the user's RACF® profile, and is anchored in the user's address space. It is referenced by RACF during command and resource authorization processing to determine if the user is allowed to perform a given action or access a given resource.

An application running in an authorized state can make modifications directly to the ACEE in storage after its creation. Such a modification would be outside the involvement of the security product, and the application must take caution to ensure that such updates do not interfere with normal system processing. Some applications might make an ACEE change to temporarily or permanently elevate the privilege of the user. This use is not necessarily malicious, and may be beneficial. For example, consider a reporting application that must access a large number of protected resources on a user's behalf. It could be infeasible to explicitly grant permission to all of the resources, and it might result in excess auditing that is unnecessary.

A security administrator might want to be aware when an application modifies an ACEE, to make sure that any increase in the user's authority complies with the organization's security policy. This can be done using the ACEECHK class.

When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console. IRR421I contains information to possibly help you determine whether the modification is expected. See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.

If the modification is expected, a program can be added to an exception list in the ACEECHK class such that future IRR421I messages are suppressed. When RACF detects an ACEE modification, it will look in the ACEECHK class for the existence of a 'bypass' profile, indicating that the IRR421I message should be suppressed. Only the existence of the profile matters; the access list, universal access, and so forth are ignored.

To understand the bypass profiles, you must understand the ACEEs and the user IDs that are possibly involved. Every address space has an ACEE that represents the identity of the user or application associated with the address space. This ACEE is pointed to by the address space control block extension (ASXB), which can be located using well-defined system pointers. An address space might be for a single-user. For example, a TSO logon or a batch job.

An authorized application, such as a server, can work on its own behalf, or can run work under the authority of its clients. It can do the latter in one of three ways:

By attaching a task (or "thread") and associating an ACEE with it. Such an ACEE can likewise be located using well-defined system pointers to access the task control block (TCB).
By creating an ACEE for the end user and explicitly providing it to RACROUTE REQUEST=AUTH. This ACEE may be created for the life of an authorization request, or for a longer interval. The application knows the location of such ACEEs, but RACF cannot locate them using system pointers. Such an ACEE is called a 2nd party ACEE.
By specifying a user ID on RACROUTE REQUEST=AUTH. RACF creates the ACEE and anchors it in the caller's ACEE. Such an ACEE is called a 3rd party ACEE.

RACF command and authorization checking will check the task level ACEE if one exists and the address space level ACEE if not. In addition, authorization checking will check a 2nd and 3rd party ACEE. In this situation, it is possible for two IRR421 messages to be issued.

IRR421I displays a "call chain". This describes the flow of control of programs leading up to the currently running program, which is the program that triggered the IRR421I. This information might help in identifying the application responsible for modifying the ACEE, and so it is important to understand the possible program configurations that might exist in the environment. The job step task is typically the "top" program in an address space. It might call other programs, and these programs might call other programs and so forth. In a simple case where a batch job runs a single program that modifies its ACEE and then accesses a resource for which a system authorization facility (SAF) check is made, then that program is the one for which you would consider adding a bypass profile.

However, if this program calls another program, and it is the second program driving a SAF check, this second program is the one that IRR421I identifies as the currently running program. If it is a utility program from some system library, you would not want to create an exception for it because the exception would apply to the utility's use by all programs that call it. Now consider the case of a program or command invoked by a TSO user. As in the previous scenario, it calls a utility program that drives a SAF check. Again, you would not want to add an exception for the utility program. However, in this case, you would also not want to an add an exception for the job step program since that would belong to TSO. Adding such an exception would suppress IRR421I messages for all TSO users.

Note: It is entirely possible that the program that modified the ACEE is not in the call chain. For example, imagine if someone implemented an SVC in an authorized library to turn on a bit in the ACEE and also wrote a TSO command processor to call it. If someone issued the TSO command, then ran a different program which triggered an IRR421I message, the TSO command program name would not be identified in the call chain. As another example, the program might actually have been in the call chain, but was not the first program of a parent task with respect to the currently running program (only the first program of ancestor tasks is displayed in the call chain in IRR421I).

RACF exception checking is performed for every program in the displayed call chain, starting at the currently running program and ending with the job step program, until a matching exception is located. Therefore, it is important to understand the application environment before adding an exception.

A bypass profile name is of the format:

IRR.EXCLUDE.program-name[.user1[.user2]]

Where:

"IRR.EXCLUDE." is a constant prefix
program-name is the name of a program in the chain of execution
user1 is the user ID from the address space ACEE
If user1 is a server running work on behalf of a different user, then user2 is the user ID from the end user ACEE that is being checked (the task-level, 2nd or 3rd party ACEE). Note that 2nd and 3rd party ACEES apply only to RACROUTE REQUEST=AUTH processing (ACEEs cannot be passed to RACF commands. The command issuer's ACEE will always be located environmentally; from either the TCB or ASXB).

RACF will look for a matching profile in the following order.

If the ACEE being checked is the address space ACEE:

IRR.EXCLUDE.program-name.user1
IRR.EXCLUDE.program-name

If the ACEE being checked is not the address space ACEE:

IRR.EXCLUDE.program-name.user1.user2
IRR.EXCLUDE.program-name.user1
IRR.EXCLUDE.program-name.user2
IRR.EXCLUDE.program-name

Note: For authorization checking, if both a task level and 2nd or 3rd party ACEE are found to have been modified, the list is checked for each user ID separately.

Examples:

The installation knows that program ABCXYZ modifies ACEEs in a safe manner and wants to suppress IRR421I messages when any user is running the program. Defining a profile named IRR.EXCLUDE.ABCXYZ accomplishes this.
A started task is designed to safely alter its own ACEE. It runs a program named STCPROG1. The administrator has set up the started task to run under user ID STCUSR1. The message is to be suppressed when STCUSR1 is running STCPROG1, but not when any other user is running STCPROG1. Defining a profile named IRR.EXCLUDE.STCPROG1.STCUSR1 accomplishes this.

Notes:

It is recommended to audit changes to the ACEECHK class using SETROPTS AUDIT(ACEECHK)
ACEECHK supports generic profile names. However, profiles named "*" and "**" are ignored since they would cause every program to be exempted from privilege escalation detection.
When RACF program control is active, the exception list will not be checked if the environment is uncontrolled ("dirty"). IBM® recommends activating program control when activating the ACEECHK class so that any program added to the exception list is known to come from a library defined to program control. See Protecting programs for more information.
If the modification is detected in the user ID field of either of the possible ACEEs involved, the profile qualifier corresponding to the modified ACEE is not considered when looking for a match. For example, if the user ID was modified in a 2nd-party ACEE, RACF will not check for IRR.EXCLUDE.program-name.user1.user2 or IRR.EXCLUDE.program-name.user2.
A unix program cannot be added to the exception list. If you wish to suppress IRR421I messages for a unix file, it will first need to be moved into an MVS library.

Failure option

You can request that RACF abend the running program when a modified ACEE is detected. This will result in a 4C6 abend with reason code X'ACE'. The abend is issued only if an exception was not located for a program in the call chain.

To request this failure option, define the IRR.ABEND.ON.FAILURE resource profile in the ACEECHK class and REFRESH the class. As with the exception profiles described above:

only the existence of the profile matters.
"backstop" profiles (* or **) are ignored.

Careful thought and planning should precede the decision to enable the failure option. You should only do so after running in production under normal workloads for a long enough interval that you are confident that you have identified all programs that are known to modify ACEEs. The results of an abend on an application can be unpredictable and largely depend on the recovery mechanisms in place for the programs running in the environment.