MVS and JES commands (i.e., also referred to as console commands within this article) are used to control system operations in an MVS environment. There are concerns regarding the issuance of console commands because when not used appropriately they can impact the continuity of the system operations and overall security.
The issuance of console commands to the system operations is primarily the responsibility of the console operators. However, due to the monitoring functions provided by console commands, a case could be made for allowing other data center and systems support personnel to have access to some of these commands. As of the past several releases of MVS, starting with MVS/XA release 2.2, IBM started to move many of the System Generation macros into system parameters that could be more easily be changed. The management of such parameters along with other operation and system functions were incorporated into MVS and JES commands.
Some of the sensitive operations functions that can be performed include:
Some of the sensitive functions that can be performed which impact security include:
In the early years of MVS, console commands could only be issued through one of the MVS consoles, which were directly connected to the system. The MVS console allows MVS and JES commands to be executed without requiring a user to logon to the system. Starting with MVS release 3.1.3, console operators can be required to logon to the MVS consoles by specifying the LOGON(REQUIRED) parameter within the CONSOLxx PARMLIB member. However, there is no facility to force the system console to timeout after a site specified period of inactivity. Therefore, unless each operator logs off the MVS console after each time they issue a console command, operators will share the same ID. This would not provide any accountability for each operator's individual actions. In addition, the user who executed a console command is not attached to the message that is written to SYSLOG. However, enabling the logon security for MVS console would at least allow an installation to restrict those console commands which are not the function of a system operator.
Other MVS facilities and system software products which provide for the issuance of console commands include:
JES2 allows jobs to be submit MVS and JES commands through the various facilities available, which include internal reader, card readers, STC readers, and TSO readers. Each of these facilities are assigned parameters which either allow or not allow JES and MVS commands (i.e., system commands) to be defined for execution within specific jobs being submitted.
SDSF is an IBM product which interfaces with the MVS spool and provides a tool for analyzing and controlling JES2. SDSF, which is executed from a TSO session, allows users (i.e., besides operators) to control the manner in which jobs are executed and printed and alleviates the tasks required to be performed by the operator. SDSF has the ability to issue any MVS command except for those commands that are restricted to the master MVS console, such as CONFIG, CONTROL, DUMP, FORCE, TRACE, and VARY.
TSO OPER Attribute
Users who are granted the TSO OPER attribute have the ability to execute a subset of MVS commands such as the SET command that is used to activate slip traps.
In the most recent releases of MVS many leading system software products have added the capability of issuing MVS and JES commands. Through these facilities all MVS and JES commands can be issued except for those commands that are restricted to only the master MVS console.
Although many system software products provide security to restrict access to perform console commands, they do not provide sufficient granularity for the various types of console commands that can be issued. Starting with MVS/ESA release 3.1.3, a SAF interface is provided to restrict individual MVS and JES commands regardless of the mechanism (e.g., MVS console) that is used to issue the commands.
The SAF security calls issued by MVS to perform access validation for the issuance console commands are processed by the external security systems which operate at the following release level:
ACF2 - 6.0
RACF - 1.9 and higher
Top Secret - 4.3
When using the SAF interface to restrict the access to MVS and JES commands, ACF2, RACF, and Top Secret all use the OPERCMDS Resource Class to define the individual MVS and JES commands which are to be protected.
Console commands can be protected and individuals permitted access at the commands first operand using masking characters. Also, security can be administered at the complete command level with all of its operands.
ACF2, RACF, and Top Secret require the MVS and JES commands to be restricted, and therefore there is no protection by default. In RACF all MVS and JES commands can be restricted by default by defining a profile with "JES2.*.* and MVS.*.*". In ACF2, a generalized resource rule would be required to be defined for each command or a group of commands using masking characters. In Top Secret, each MVS and JES commands would be required to be owned in order to be protected. An alternative is to protect all console commands by defining RESCLASS(OPERCMDS) ATTR(DEFPROT) in the RDT list.
The syntax of how the OPERCMDS resource class protects resources is as follows:
(MVS or JES2 or JES3).(function or first command operand).(second command operand).(third command operand)
This syntax allows the complete MVS or JES command or a portion of the command to be protected. In most cases it is recommended to use masking characters, otherwise all combinations of the second and third level operands would be required to be restricted. To restrict the use of SLIP traps the syntax of the command is "MVS.SET.SLIP.*"
The access level that a user requires in order to execute the console command is dependant upon the scope of the related function. For instance, display type commands require READ access, while system modification commands may require UPDATE access.
This article was written more than three years ago. Events may have
changed since this article was written.
For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.
Join 3,500 other subscribers
Advertise with Us