Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Control Requirements when running MVS as a 
Guest Operating System under VM

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

At one time VM provided an invaluable function for MVS operating environments by its ability to allow multiple guest MVS operating systems to operate concurrently as separate virtual machines. This allowed installations to define separate test systems, enabling system programmers to test new releases using a separate guest operating system. With IBM's 3090 Processor Resource System Manager (PR/SM) running MVS/ESA, the machine can be logically partitioned (LPAR) so that it can run four guest operating systems without using VM. Therefore, the number of MVS operating environments and VSE operating environments (i.e., equivalent functionality provided for VSE environments that use VSE/ESA and PR/SM offered by the ES9000) that were dependant on running guest operating systems (i.e., MVS and/or VSE guests) under VM have been reduced.

Within this article the possible methods that can be used to access the resources of a MVS guest operating system from a native VM environment will be discussed. Although, this article is written based on control issues related to an MVS guest operating environment, many of the control issues discussed should also apply to a VSE guest operating system or native VM running as a guest operating system. It is a known fact that an external security system is required within an MVS operating system to assure security integrity. However, the need for an external security system within the VM environment is strongly recommended. but no arguments are made within the article since control solutions are not specifically discussed. Within the article, all security points are discussed in relation to native VM security.

Within the next issue of Audit Vision, an article is provided which discusses all of the control issues and solutions within a VM environment.

Introduction to VM

VM creates an illusion to each of its users (.e., individual user or a guest operating system) that they are operating within their own system (i.e., each user is referred to as a virtual machine).

The VM Control Program (CP) creates the environment in which virtual machines operate by providing each user the facilities of a real machine (i.e., processor, storage, I/O devices). CP runs on all real machines in the real machine's supervisor state and therefore has access to all privileged instructions. CP runs each virtual machine in real problem state.

Conversational Monitor System (CMS) is also provided within VM which is the interactive development environment utilized by the user.

A DASD volume can be dedicated to one particular virtual machine or it can be shared by more than one virtual machine. A DASD volume is normally divided by the CP into minidisks which are allocated to specific virtual machines. A minidisk can be a complete disk drive or it can consist of a specific range of cylinders. The CP handles the mapping of the minidisks to the real disks but the space within the minidisk is managed by the operating system running on the virtual machine to which the minidisk is assigned.

Preventing one guest operating system from accessing another

Isolation of the guest operating system is the strength of VM which prevents one guest from accessing the resources of another guest operating system. A user from one MVS image cannot access another MVS image unless permitted through the MVS system, even if there is shared DASD between the two systems. The only exception is when a guest operating system (i.e., virtual machine) is granted write access to a minidisk belonging to another virtual machine. This can be identified by reviewing the VM Directory which contains descriptions of each virtual machine (i.e., individual users and guest operating systems) which includes their ID, password, physical address of their console, virtual physical address of the minidisks they are assigned, and LINK entries of the minidisks they are granted access to that belong to other virtual machines (note: type of access allowed is specified).

Scope of privilege access assigned to a guest operating system

With the MVS environment, programs that execute in supervisor state have the ability to execute privileged instructions. However, since the MVS environment is running as a virtual machine, its ability to issue privileged instructions is limited to its MVS environment since the CP runs each virtual machine in problem state. When the virtual machine, which in this case is a MVS guest operating system, attempts to execute a privileged instruction, CP gains control through its system interrupts processing and traps the request to either deny the request or allowed the execution of the privileged instruction. If the instructions pertain to the MVS's own virtual machine then VM will simulate the execution of the privileged instruction. However, if the privileged instruction attempts to perform processing or access storage outside its own virtual machine, the CP will deny the request.

The types of commands that the CP will trap are privileged commands that attempt to change the state of the machine or dynamic reconfiguration commands which includes the command to redefine VM channel set.

For instance, if MVS requests to set time/day clock, CP which has supervisor state, traps that request, evaluates it and either denies it or will allow the request. The CP will then simulate the guest operating system request by setting the guest's virtual machine clock but not the actual machine's clock.

The CP supplies a virtual console to each virtual machine which allows them to execute CP commands some of which are sensitive. CP commands can be used to dump virtual storage areas, set instruction stops, monitor and change values in various locations.

VM utilizes privilege classes to identify the groups of CP commands that can be executed by various types of users. A user's (i.e., virtual machine) privilege class is defined as an entry in the VM directory. The privileges classes include: G - General user, F - Service Representative, E - Systems Analyst, D - Spooling Operator, C - System Programmer, B - System Resource Operator, A - Primary System Operator.

Privileged classes are assigned to all virtual machines which includes individual users and guest operating systems. All guest operating systems should be assigned class G (general user class) and do not require any higher privileged class. Checking the privilege class is the pennant in the VM virtual machine concept that completely isolates one virtual machine from accessing another.

Preventing a CMS user from accessing a guest operating system

CP handles the mapping of minidisks to real disks. However, the space within the minidisk is managed by the operating system running on the virtual machine to which the minidisk is assigned. CP prevents a virtual machine from accessing space on a disk volume outside the boundaries of the machine's minidisk.

Within a CMS environment (i.e., native VM environment) there is a need for users to share minidisks (e.g., system disk, tool disk). Based on the approach of each virtual machine having ownership writes to their own minidisks, and with the need to share data between various virtual machines, it is common for multiple virtual machines to have access to minidisks that are owned by one specific virtual machine. However, the sharing of minidisks between a CMS user and a guest operating system or between two guest operating systems needs to be avoided.

Allowing a VM CMS user update access to a minidisk that is created for a guest operating system would allow that individual to link to the minidisk an perform unauthorized processing. One method that can be used to prevent a VM user from accessing the resources of a guest operating system is not to define the DASD space used by the guest operating system as a minidisk. Instead, you can dedicate a DASD volume or a string of DASD to an MVS guest which only allows the MVS guest to have access. Therefore, there is no mechanism for CMS user to link to the volume.

VM system programmers have to be controlled in the same manner as MVS system programmers. VM system programmers have debugging tools that provide the capability of looking in real storage and virtual machine virtual storage to aid them in debugging. Those tools allow them to look inside an MVS virtual machine (i.e., CMS commands; DEBUG, TRACE). However, the system programmer would need to be assigned the "C" privileged class to use these tools.

The other method that can be used by a CMS user to access an MVS guest is for the CMS user is submit a job to the MVS guest from a CMS machine. However, the type of processing that the job can perform is dependant of the controls that are in place within the MVS operating since the CMS machine submits the job directly to the MVS internal reader.

VM provides limited audit trails that could be used to identify sensitive functions that are performed on the system. For instance, every LINK command that is used by a user to access minidisk would be recorded but and audit trail would not be available for the use of the debugging tools.

This article was written more than three years ago. Events may have changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.