The management of APF is central to maintaining z/OS integrity. Let’s start with the linkage editor SETCODE control statement. SETCODE has an important role to play. Suppose APF program “A” performs checks to determine why it’s being run. Satisfied, it calls program “B,” which calls program “C.” How can we prevent a malicious user from bypassing the checks in “A” by directly calling “B” or “C”? MVS lets us enforce our calling sequence by marking “A” with SETCODE AC (1) and “B” and “C” with SETCODE AC (0).
To ensure we actually follow through on this, MVS requires the initial program of an APF authorized job step be marked AC (1) and then monitors all subsequent program loads to make certain they come only from APF libraries. Any attempt to load programs from a non-APF library results in a system 306 ABEND.
The most important step in managing APF is protecting its program libraries from unauthorized use or modification. Once we’ve identified all the libraries, it’s a straightforward exercise to protect them using our security software. But determining the APF libraries can be complicated. The place to start is the System Parameter Library (SYS1.PARMLIB) concatenation. Although IBM supplies extensive documentation for Parmlib, there are specialized publications that can help us sort out the security implications of Parmlib’s myriad options and parameters. Two of my favorites are OS/390- z/OS Security, Audit and Control Features by Peter Thingsted and A Guide to SYS1.PARMLIB by Mark Hahn. Both are available through ISACA (see www. isaca.org for details).
The APF environment may be defined as static or dynamic and if console operator commands are allowed, a careful review of SYSLOG will be necessary to assess their impact. Fortunately, MVS provides several methods, such as System Authorization Facility (SAF) facility-class profiles, to control operators. Determining exact APF library usage can be challenging because libraries can be both explicitly and implicitly defined. For example, certain libraries, such as SYS1.SVCLIB are always authorized, while others such as the SYS1.LPALIB concatenation are authorized only under certain conditions. Still others, such as the SYS1.LINKLIB concatenation, may or may not be authorized, depending on option choices.
Authorization also may be specified via LNKLSTxx, PROGxx, IEAAPFxx, LPALSTxx, IEALPAxx, and IEAFIXxx. The SCHEDxx member of Parmlib allows installation additions of APF programs to the PPT.
All these choices provide important tools and valuable flexibility for securely integrating system-level software into the MVS base. But it’s probably obvious why people have written books about this subject and why we must defer getting any deeper into Parmlib for another time. Although APF is the system’s primary authorization mechanism, there are others. The system protects the Pageable Link Pack Area (PLPA) from update, and controls access to the Prefixed Save Area (PSA) in low memory. To dig deeper into the technical details of Service Request Blocks (SRB), Dispatchable Unit Access Lists (DUAL), as well as a contemporary discussion of integrity exposures, refer to the “Protecting the System” chapter in IBM’s MVS Programming: Authorized Assembler Services Guide (SA22-7608).
Looking beyond the mechanisms singled out by the integrity statement, we can see how legacy design decisions have both directly and indirectly contributed to the robustness of the mainframe environment. For example, MVS used a modular design with independent subsystems in separate address spaces communicating with each other through formally defined interfaces. This kind of architecture is reminiscent of the new “micro kernel” architectures that are currently all the rage. The mainframe had it decades ago. An important factor in MVS success is the System Modification Program (SMP/E). It has provided automated program maintenance for MVS system software for decades and has undoubtedly contributed to system integrity. SMP/E makes certain that Program Temporary Fixes (PTF) prerequisites and other dependencies are met, and allows the testing and rollback of fixes. Non-mainframe vendors are now realizing the value of change control to system stability.
Other important contributions are provided by System Management Facility (SMF) and console operator (SYSLOG) journals, tools for performance monitoring, tuning, and access control software such as IBM’s RACF, CA’s eTrust CA-ACF2 and eTrust CA-Top Secret, or JME Software’s DEADBOLT.
In keeping with the modular design of MVS, these security products all use the SAF to interface with the operating system. They add extensive authentication and authorization services to control user’s access to system resources (see Figure 5).
The integrity statement also says the protection of assets by OS passwords and RACF is part of MVS integrity. We must use our security software to control access to the operating system’s data files and program libraries. In turn, MVS must provide a solid foundation upon which to build security. External security managers depend on this. For mainframes, the interrelationship of security and system integrity had been recognized by developers such as Barry Schrager (ACF2) and Eldon Worley (RACF), since the early ’70s. After decades of refinement, the System z security environment is feature rich and second to none with numerous options and parameters. While the complexity can be intimidating, all those choices provide enough flexibility and granularity to address almost any situation. Users aren’t pushed into the “one size fits all” environment of some platforms, where too many things wind up needing powerful “root” access. Many resources are available to help us achieve effective MVS security. Also, unlike other platforms, today’s mainframe user has a choice of multiple access control software systems.
While security is concerned with controlling who gets the key to the lock, integrity is concerned with the correct functioning of the lock. Because MVS was designed and optimized for a specific hardware platform, it can do far more than so-called “platform agnostic” operating systems. In a mainframe environment the operating system works with the hardware to ensure data is protected from both accidental and malicious modification and that only authorized programs are able to manipulate system resources. The mainframe’s careful attention to system integrity provides a solid foundation for building effective system security. It’s reassuring to note that today’s System z mainframe and its z/OS operating system have had so much protection built into them, from their very beginnings, 42 years ago. Now if we could only figure out how to transfer some of the hard lessons learned to the people living in the “Patch Tuesday” world …