|
|
|
|
|
This section describes the procedure used to implement the Control‑O security interface. It is recommended that you first review the following information about the elements that are protected in Control‑O and then proceed to the step-by-step instructions.
Protecting Control‑O Elements
The security interface protects the following Control‑O elements:
Rule Ordering
Each Control‑O rule is defined with an OWNER parameter. The OWNER is the user ID to which the rule belongs. To order a rule, the user must have authorization to access the owner of the rule. The CTOSE01 Control‑O security module verifies that the current user has the authorization to order the rule, using the OWNER field of the rule.
The CMEM default rules in the IOACMEMR table are provided with the OWNER user ID of IOADMIN.
You must grant the user who orders these rules (either CTMCMEM or CONTROLO) permission to load the rules on behalf of the IOADMIN user ID, and grant the IOADMIN user permissions to the perform ON and DO statements in these rules.
Rule Triggering:
Events such as messages, commands, and the other event types defined by the ON statement can cause rules to be triggered if a rule with a matching ON statement is active.
Before triggering the rule, the Control-O CTOSE10 security module validates that the user associated with the event is authorized to trigger the rule. This protection is selective and it is performed if the feature is enabled and only for those rules that request it explicitly by specifying the following anywhere inside the rule:
DO SET = %%PROTRULE=Y
There is no security exit CTOX010 and there is no distinction between basic and extended security mode in security module CTOSE10.
Use of Control‑O Functions (DO Statements and ON Statements): Rule execution consists of reacting to the events defined in the rule’s ON statement and performing actions defined in the rule’s DO statement. The security interface verifies if the owner of the rule is allowed to perform these actions. The CTOSE02 Control‑O security module performs an authority check for each rule statement before the rule is loaded. If one of the authority checks fails, the entire rule load is canceled.
Access to and Use of the Rule Status Screen:
The Rule Status screen lists the active rules currently handled by Control‑O and their status. The user can issue inquiries about a rule in the list or change its status. The CTOSE08 Control‑O security module verifies the user’s authorization to access the Rule Status screen and perform actions (hold, delete, and so on) on the rules displayed.
Use of Control‑O Commands (DO Statements):
Rule execution consists of performing various actions defined in DO statements. The security interface verifies the authority of the user ID associated with the rule to execute each of the DO statements in the rule. The user ID associated with the rule can be the owner of the rule or the user ID of the user who issued the message or command that triggered the rule, depending on the value of the rule’s RUNTSEC parameter.
The IOASE07 security module checks for authorization to update conditions. The IOASE12 security module checks for authorization to execute operator commands. The CTOSE03 security module checks for authorization to execute DO KOA, DO TSO, and DO SHELL statements.
Use of TSO Commands, KOA Scripts, and z/OS Shell Scripts:
A rule can request execution of a TSO command (or REXX/CLIST) or activation of a KOA script or z/OS shell script. The command or script can access datasets and various resources in the system. To protect these resources, the command’s execution environment inherits the security environment associated with the rule. This means that the command’s successful execution is dependent on if the user ID associated with the rule has the authority to execute the command. This user ID is either the owner of the rule or the user ID of the user who issued the message or command that triggered the rule, depending on the value of the rule’s RUNTSEC parameter.
Access to the Automation Options Screen:
The Automation Options screen (screen OA) handles various aspects of the Automation environment (for example, issuing operator commands, listing and controlling Control‑O servers, checking resource queuing information, viewing the operator console display). The CTOSE04 Control‑O security module verifies user authorization to access Automation Options and protects actions performed on entities handled in these screens.
Use of the XAM Interface:
A TSO user, REXX, CLIST or user–written program can request services from the XAM interface. The security interface verifies the authority of the user ID associated with the XAM request to execute the requested function.
When XAM functions are requested under a Control‑O server, the user ID is either the OWNER of the rule or the requester (TRIGGER) of the XAM function, depending on the value of rule’s RUNTSEC parameter.