VM Operating System Review Following was contributed to AuditNet LLC by (Rey LeClerc) rey@massusa.net Objectives: To ensure that adequate security procedures have been established over VM. General Description The VM operating system was developed during the mid-1960s in order to create a virtual system that would appear to each user as a dedicated machine. Requirements vary among organizations of different sizes. Because of this, there are different variations of VM to better meet these needs. Virtual Machine/System Product (VM/SP) is really VM in its simplistic form. Running VM/SP requires system programmer expertise for both installation and maintenance, but provides flexibility to meet the needs of the organization. VM/SP is generally considered to consist of two components: the Control Program (CP) and the Conversational Monitor System (CMS). CP is a set of programs which manages the real machine resources and creates the virtual machine environment. The major functions of the CP can be summarized as follows: o user scheduling and dispatching; o real storage management; o virtual memory management; o spool management; o CP command processing; o error recovery and recording. CMS is an interactive operating system within VM, that operates under the control of CP to manage the virtual machine environment. The basic components of CMS are: o editor; o EXEC processor; o Debug environment; o OS simulation; o commands, e.g., COMPARE, SORT, COPYFILE, etc. Because of its capabilities of CP, VM is often referred to as the perfect host. A myriad of different operating systems can coexist in the same machine under the umbrella of VM's Control Program. These other operating systems CMS
are called guest operating systems. VM handles guest operating systems in much the same way as multiple on-line users. Guest operating systems used for production work should be subjected to complete audits as if they were running in native mode. System generation is the process that compiles the selected operating features into an executable version of the operating system. System generation options are specified in one of three CP source modules: DMKSYS, DMKSNT and DMKRIO. DMKSYS, also known as the CP System Control File, consist of macro statements that describe the following: o CP system residence device; o system storage device; o CP-owned direct access devices; o system operator's user identification; o system timer value; o system pointer variables; o automatic performance monitoring parameters; o accounting parameters; o system identification; o system spool parameters; o security journalizing parameters; o system dump space parameters; o system T-DISK security parameters; o missing I/O interruption timer intervals. The Real Input/Output Configuration File (DMKRIO) consists of macros that describe the input/output devices, control units, and channels attached to the real processor. The System Name Table (DMKSNT) consists of entries that identify the name and location of saved systems or discontinuous saved segments. After the three system generation modules are ready, the CP nucleus is generated through a program called VMFLOAD. The CP nucleus can basically be defined as the core of the VM system. It is the brains of the system, or the code that gives the environment its basic VM attributes. After the system generation is completed, and VM has gone through the Initial Program Load (IPL), CP exists. The new CP resident nucleus is now loaded in real memory and VM is available for further use.
The newly created VM system contains a CP directory, which is basically a list of User-IDs and information about the virtual machines identified by User-IDs. Audit Program 1. Obtain listings of DMKSYS, DMKRIO, DMKSNT and the CP Directory. 2. Check the value of the SYSCLR operand of the SYSRES macro in DMKSYS; SYSCLR=YES should be specified to prevent unauthorized access to sensitive data placed on T-disks. SYSCLR=YES is default. If SYSCLR=NO is specified, the installation should have a published disclaimer for T-DISK security. 3. Check the SYSJRL macro specification in DMKSYS. JOURNAL=YES should be specified to detect access attempts by unauthorized users. JOURNAL=NO is default. PSUPRS=YES should be specified to suppress passwords as they are being entered into the system. PSUPRS=NO is default. 4. Inspect the DMKRIO to verify that device specifications reflect the actual hardware configuration and that excessive number of additional devices have not been defined. 5. Verify the specifications of shared and saved systems in DMKSNT and check for overlapping assignments on DASD. 6. Inspect the load list used by VMFLOAD and compare it with the IBMsupplied list to ensure that no critical system modules have been deleted; verify that deleted modules do not implement facilities that have been implied in DMKRIO or DMKSYS and review any frequently used pagable modules that are or should be resident. VM OPERATING SYSTEM REVIEW VM/SP Modifications Objective: To determine whether VM/SP modifications are tested, documented and performed according to established procedures. General Description: VM Maintaining the VM operating system revolves around
product releases, which introduces new VM capabilities, and Program Update Tapes (PUT), which provide fixes for previous problems. PUTs contain various files that establish the system code at a specified PUT level. Typically, the systems programmer applies an entire PUT. However, the programmer can also apply a modification individually from the PUT to resolve a critical problem. The systems programmer should maintain a log of all these changes, whether they are IBM-supplied or local, including the date of the application, modules affected, PTF (program temporary fix) number, and reason for the change. All changes should be reviewed by the technical support manager so that users and operations staff are aware of modifications that might affect them. Audit Program 1. Review the latest PUT process output to verify that IBM-supplied maintenance has been properly installed. 2. Confirm that all local modifications to CP have been properly installed, adequately logged, and documented; review the justification for each local modification. 3. Spot-check the CP nucleus map to verify that both IBM- and usersupplied modifications have been included in the system nucleus. 4. Determine whether the systems supervisor or systems staff, other that the original systems programmer, reviews all system and utility testing before cataloging into production.
VM OPERATING SYSTEM REVIEW Access Controls Review General Description: The CP directory, also more broadly termed the VM directory, serves as a repository for information including the definitions of users, their CP privileges and classes, and the locations of their minidisks
where data is stored. There are two types of data sharing in VM. The first is the directory link, which is used mainly for common applications like CMS. This is automatically executed when a user logs on, and is maintained until the user explicitly detaches this link. User may also share data through user links. A user may explicitly link to share another user's minidisk. There are four options that may be specified in designating a password: o READ - permits access to data on a minidisk in a read-only mode; o WRITE - permits users access to both read the data on the minidisk as well as modify it; o MULTIREAD - permits more that one user to read the minidisk at one; o MULTIWRITE - more that one user can read and write into a minidisk at one. This option has the potential for creating a nightmare, because data can be modified concurrently with other users. This option is not supported for CMS use because of its potential data destruction. The logon password, which may also be up to 8 characters in length, is required to log on to a User-ID, thereby gaining access to the system. The UserID is associated to one or more privilege class: o Class A - Primary System Operator. This individual is allowed to control and even terminate the total VM operation. o Class B - System Resource Operator. At this level, the user is allowed to examine the status of the system-owned units and make allocations for requesting users. o Class C - Systems Programmer. A Class C user can examine and modify real storage, including the ability to examine and modify the main storage of other users. o Class D - Spooling Operator. This individual can alter the characteristics of real spooling devices and queues. This would affect, for example, the queues for printers and other devices. o Class E - System Analyst. This class allows the examination of real storage, but without the ability to modify it. o Class F - Engineer/Service Representative. A Class F user is allowed use of extended I/O capabilities, preventing error recording while running. This individual might be inclosed in making modifications to enhance response time.
o Class G - General User. system.
This class is reserved for most users of the
It is also possible to tailor user privilege classes. With VM/SP Release 4, installations have the ability to create up to 32 CP privilege classes as well to dynamically assign capabilities. Audit Program 1. Check user privilege classes against authorization forms to ensure that users have proper resource accessibility. 2. Confirm that critical user IDs have password protection on their minidisks. Verify that users have adequate level of privilege class. 3. Review the directory update directory for disk password changes. If directory maintenance is performed manually, a log of all changes should be kept. It an automatic system (e.g. DIRMAINT) is used, the system administrator should retain all pertinent log information. Ensure that passwords are not vendor supplied, easily guessed, repeated or users have multiple UserIDs. 4. Check the journal data for improper access attempts; note and check write accesses to nonowner disks. 5. Determine whether User-ID AUTOLOG1 is defined in the user directory. The user with this ID is automatically logged on at the conclusion of the system initialization. 6. Inspect the file PROFILE EXEC on the 191 disk of user AUTOLOG1; review the sequence of actions performed with AUTOLOG1 activated. 7. Review the VM utilities (e.g. VMFZAP, GENERATE) and determine if access to them is adequately controlled. VM OPERATING SYSTEM REVIEW Tuning and Performance Efforts
Objective: efforts.
To assess the quality of system performance and tuning
General Description: VM/SP has a built-in system activity monitor. VMAP program product can produce a detail performance report. The review of this is important because in addition to overall performance, we can see if there are any overlapping minidisks. With overlapping minidisks, the process of getting into data of others becomes easier because as this can be accomplished without the need of a password. If not carefully mapped, it is easy to assign the same minidisk space to two different users or simply waste the space contained in the gap. Audit Program 1. Obtain a DISKMAP listing and determine if gaps or overlaps affect system performance or integrity. VM OPERATING SYSTEM REVIEW Sources/References Auditing VM/SP by David M. Leonard (Auerbach Publishers Inc., 1985) Handbook of EDP Auditing by Halper, Davis, O'Neil-Dunne, and Pfau (Warren, Gorham & Lamont, 1985) VM and Departmental Computing by Gary R. McClain (McGraw-Hill Book Company, 1988) VM/SP General Information Manual (GC20-1838-4) VM/SP Installation Guide (SC24-5237-2) VM/SP Introduction (GC19-6200-3) VM/SP Planning Guide and Reference (SC19-6201-04)