Security

Which RACF class has grown from housing a few profiles to housing more than 100? Which class has grown into a major player in the control of many key z/OS services? It also has recently grown from a single class into one with a companion member-grouping class pair. You’d be correct if you answered the FACILITY class. But what services are taking advantage of this long-standing class and why has a new member/grouping class pair been created?

 This article explains the base concepts and use of the FACILITY class and its new companion classes, XFACILIT and GXFACILI. These new classes were introduced in z/OS 1.7 and can be rolled back to z/OS 1.4 with APAR OA10774. Currently, only the IBM Health Checker for z/OS uses XFACILIT. While we’ll discuss the FACILITY class from a RACF perspective, the information provided applies to other mainframe security products that respond to RACROUTE calls to the System Authorization Facility (SAF). Instead of the FACILITY class, CAACF2 knows this as FAC and CA-Top Secret uses IBM-FAC.

Early in RACF’s evolution, the developers recognized a need for a general-purpose resource class available to any system service with too few resources needing protection to justify a separate class. This was back when the maximum number of resource classes was relatively small and implementation of an additional class required an Initial Program Load (IPL), a constraint that has only recently been lifted with the Dynamic CDT introduced in z/OS 1.6. The FACILITY class was born in response to these original requirements.

 Over the years, an increasing number of system services used the FACILITY class to protect their growing list of functions. From its humble beginning of just a few system services and a handful of their related resources, the FACILITY class has grown to dozens of system services and more than 100 different resources. Many third-party products also have chosen to use the FACILITY class because it was readily available in all MVS, OS/390 and z/OS systems, and required no modification to the RACF tables.

 FACILITY Classes Characteristics

 The FACILITY classes and their characteristics are defined in the RACF Class Descriptor Table (CDT). Figure 1 describes a few of the more pertinent characteristics.

 The FACILITY class maximum of 39 characters is quite limiting when creating descriptive names for newer resources. This RACF limitation, which wasn’t lifted until the restructured database in RACF 1.9, has been addressed in the new XFACILIT and GXFACILI classes, where resource names can be up to 246 characters. This is needed by the IBM Health Checker for z/OS, since it addresses the increasingly complex system environment by including such information as the system name, owner name and function in the resource name for authorization. Two such examples appear in Figure 2.

 Resource Naming Conventions

 Most system services using the FACILITY classes follow the naming conventions used by data sets: Names are constructed of one or more qualifiers (i.e., nodes) separated by periods such as BPX.DEFAULT.USER. Most qualifiers are eight characters or less in length. Unlike data sets, the names aren’t restricted to alphanumeric and national characters. The class description, shown earlier, allows any character to be used in the first (FIRST=ANY) and all other positions (OTHER=ANY). The IBM Health Checker for z/OS exploits this capability by using the underscore character (‘_’) in resource names.

 With so many system services sharing one class, a means of segregating their different resource names was needed to avoid duplicate profile names. To address this need, each system service selects a specific prefix in naming all their associated resources. Often, these prefixes match the prefix of their program names. Examples include BPX for Unix System Services and IRR for RACF.

3 Pages