The resources that RACF can protect are divided into two categories: data sets and general resources. Classes of general resources are defined in a class descriptor table and include DASD volumes, tape volumes, terminals, applications, and IMSjVS and CICSjVS transactions. This section describes considerations related to using RACF with these resources.
General Resource Classes
With the exception of the DATASET, USER, and GROUP classes, all resource classes are represented in the class descriptor table (CDT). The CDT consists of two modules: ICHRRCDX is for IBM-supplied entries; ICHRRCDE is for installation-defined entries. The IBM-supplied CDT contains class descriptors for the following classes:
• DASDVOL (DASD volumes)
• TAPEVOL (tape volumes)
• TERMINAL (terminals)
• TIMS (lMSjVS transactions)
• GIMS (IMSjVS transactions group)
• AIMS (IMSjVS application group names)
• APPL (applications)
• TCICSTRN (CICSjVS transactions)
• GCICSTRN (CICSjVS transactions group)
• PCICSPSB (CICSjVS program specification blocks or PSBs)
• QCICSPSB (CICSjVS PSBs group)
• GMBR (global access checking group)
• GLOBAL (for global access checking)
• DSNR (DB2)
• FACILITY (bypass label processing)
• SCDMBR (security classification of users and data member)
• SECDATA (for security classification of users and data)
• FCICSFCT (file control table)
• HCICSFCT (file control table group)
• JCICSJCT Gournal control table)
• KCICSJCT Gournal control table group)
• DCICSDCT (destination control table)
• ECICSDCT (destination control table group)
• SCICSTST (temporary storage table)
• UCICSTST (temporary storage table group)
• MCICSPPT (processing program table)
• NCICSPPT (processing program table group)
• ACICSPCT (program control table)
• BCICSPCT (program control table group)
• PROGRAM (for programs)
RACF commands and SVCs reference the CDT whenever a class name other than DATASET, USER, or GROUP is received as input. Each IBM class descriptor is a CSECT in load module ICHRRCDX. The last CSECT in the load module is ICHRRCDE, which indicates the end of the descriptor table.
Note: The class descriptor table must be the same for each system sharing the RACF data set. If they are not the same, you might get unpredictable results when using the SETROPTS command to activate or deactivate RACF.
Defining New Classes to RACF
An installation can, as needed, add new class descriptors or modify or delete old class descriptors in the CDT for installation-supplied entries (ICHERCDE). You use one of the following methods:
• Invoke the class descriptor macro ICHERCDE for each resource class and do an assemble, then link edit the result to produce the load module used by RACF. When you use this method, the ICHRRCDE macro cross-checks class descriptors to ensure that no errors exist (for example, that the first four characters of class names are unique). If you are installing RACF for the first time, use this method.
• Link edit the object module(s) for the class(es) you are adding or modifying together with the existing load module ICHRRCDE in SYSl.LINKLIB to produce a new load module. Be sure that the last CSECT in the load module is ICHRRCDE. You can delete a class from the descriptor list by specifying the name of the class to be deleted using the linkage editor REPLACE statement. (Do not delete or modify any IBM -supplied classes from the load module,ICHRRCDX.) When you use this method, you can add object modules for new classes to the load module without reassembling. If you have made changes after installing RACF, use this method. However, if you do not completely reassemble the class descriptor table, you lose the cross checking that the ICHERCDE macro performs.
Defining the Class Descriptor Table
The ICHERCDE macro generates entries for the resource class descriptor table.
The class descriptor table contains information that directs the processing of general resources. The table consists of two load modules, ICHRRCDX, which contains IBM-defined entries and ICHRRCDE, which contains installation defined entries. The table has an entry for each class except the USER, GROUP and DATASET classes. To generate the table, you must specify the macro once for each class. To identify the end of the class descriptor table, you invoke the macro without specifying any operands.
Note: Iran entry added to the class descriptor table is to be accessed by the RACROUTE macro instruction, you should also code an ICHRFRTB macro instruction for the entry. See "RACF Router Table" later in this chapter.
The ICHERCDE macro produces a CSECT for each invocation. If the CLASS operand is present, the CSECT name is the name of the class being defined;
otherwise, the CSECT name is ICHRRCDE.
Resource Groups
For information on coding the ICHERCDE macro, see "ICHERCDE Macro" in Chapter 10.
Resource groups protect, with one RACF profile, a set of resources that have the same security requirements (for example, a given user or group has the same authority to all the resources in the group). Figure 5-1 provides a sample of the creation of resource groups and resource group classes.
Chapter 5. RACF Options
5-11
COT
-4--Resource class containing individual members ....- Resource class containing resource group / - - - 1 (resource group class) add the members ADD and SUBT that also have resource profiles in the TIMS class.
• The resource group LOGIC is defined to RACF and the ADDMEM operand is used to add the members AND and OR to the group profile. No individual resource profiles need to be defined for AND or OR.
Figure 5-1. Creating Resource Groups
To make use of resource groups for a given class of resources (for example, TIMS), the installation defines a resource group class (in this example, GIMS) associated with the given class of resources. To groupa set of resources in the given class, the installation defines an entity in the associated resource group class and makes each resource in the set a member of the grouping entity. When a user is allowed to access the grouping entity (with the PERMIT command), RACF propagates the authority to each member resource. RACF also propagates the universal access of the grouping entity to each resource.
When planning for the use of resource groups, consider the following:
• Resource groups are effective only when used in combination with the RACLIST facility. RACF does not automatically propagate the access list information and universal access of a grouping entity to its member resources when the resources are made members of the grouping entity or when users or groups are allowed access to the grouping entity with the PERMIT command.
Instead, this propagation takes place when the RACLIST facility is used to construct in-storage profiles for a given resource class. Resource grouping is possible, therefore, only for those classes of resources for which the resource manager (for example, IMS) invokes the RACLIST facility prior to
performing authorization checking.
• A grouping entity is a RACF-protected resource. Thus, RACF controls access to the entity and any user accessing that entity must have sufficient authority to perform the desired operation. A resource grouping class is associated with one and only one resource class and cannot be used to group resources from two different classes; nor can a class be grouped by two different resource group classes.
• The resource group classes cannot include generic profile definitions, but a grouping entity can contain generic names as members.
System Authorization Facility (SAF)
MVS Router
The system authorization facility (SAF) provides a system that gets control in response to a request from a resource manager. SAF conditionally directs control to RACF, if RACF and/or an installation-supplied processing routine is present.
SAF does not require any other program product as a prerequisite, but overall system security functions are greatly enhanced and complemented by the concurrent use of RACF. The key element in SAF is the MVS router.
SAF provides an installation with centralized control over system security processing by using a system service called the MVS router. The MVS router provides a focal point and a common system interface for all products providing resource control. The resource managing components and subsystems call the MVS router as part of certain decision-making functions in their processing, such as access control checking and authorization-related checking. These functions are called "control points." This single SAF interface encourages the use of common control functions shared across products and across systems.
The router is always present whether or not RACF is present. If RACF is available in the system, the router passes control to the RACF router (ICHRFROO) that invokes the appropriate RACF function based on the
parameter information and the RACF router table (ICHRFROX or ICHRFROI), which associates router invocations with RACF functions. For more information on the MVS Router, see "MVS Router" in Chapter 7.
Chapter 5. RACF Options 5-13
Router Table Entry Definition
The RACF router table consists of two parts: ICHRFRO I, the installation.;defined module, and ICHRFROX, the IBM-supplied module. You can use the
ICHRFRTB macro to generate entries in the optional installation-defined part of the RACF router table, ICHRFROI. This table controls the action taken by the RACF router, ICHRFROO, when it is invoked by the RACROUTE macro instruction.
The IBM-supplied module ICHRFROX contains one entry for each entry in the class descriptor table, plus one entry each for DATASET and USER. For all entries, the operands REQSTOR and SUBSYS have the default value (all blanks), and the ACTION operand is set to RACF.
Note: If an entry added to the class descriptor table is to be accessed by the RACROUTE macro instruction, you should also code an ICHRFRTB macro instruction for the entry. Do not modify the IBM-supplied table, but, instead, create your own table called ICHRFROI.
ICHRFRTB concatenates the values specified for the REQSTOR, SUBSYS, and CLASS operands to form a 24-character string defining the entry. The macro matches these values against the string formed by the values specified on the RACROUTE macro instruction.
For information on coding the ICHRFRTB macro, see "ICHRFRTB Macro" in Chapter 10.
For information on creating ICHRFROI, see member RACINSTL in SYSI.SAMPLIB.
Selecting Options with SETROPTS
You can select the following options on the SETROPTS command:
• Universal access authority for terminals
• General resource protection
• Generic profile checking
• Global access checking
• Maximum password change interval
• Password syntax rules
• List-of-groups authority checking
• Refreshing of in-storage generic profile and global access checking lists
• Extended password processing
• Data set modeling options
• Bypassing automatic data set protection (ADSP)
• Bypassing RACINIT statistics
• Bypassing resource statistics
• Logging RACF -command and RACDEF SVC activity
• Use of real data set names in messages and SMF records
• Bypassing logging of activity of users with the SPECIAL attribute
• Bypassing logging of RACF command violations
• RACF protection for data sets with single~level names
• JES2 or JES3 RACF support
• Activating tape data set protection
• Selecting a security retention period for tape data sets
• RACF-protecting all new data sets
• Erasing scratched DASD data sets
• Logging the activities of users with the OPERATIONS attribute
• Activating program control
• Setting the RV ARY passwords
• Activating security classification of users and data
The security administrator is the primary user of the options on the SETROPTS command. F or a description of these options, see the Security Administrator's Guide. For a complete description of the SETROPTS command, see the Command Language Reference.