Control-O Security

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:

• Ordering rules.

• Triggering rules.

• Use of DO statements and ON statements. Controls the authority of the owner of a rule to specify DO statements or ON statements (for example, access or modify prerequisite conditions, issue certain operator commands, issue restricted TSO commands).

• Use of the Rule Status screen (screen OS) and authority to access rules within this screen.

• Execution of DO statements according to the authorization of the user ID associated with the rule. The user ID can be the owner of the rule or the user ID that issued the message or command that triggered the rule.

• Execution of TSO commands, KOA scripts, and z/OS shell scripts by applying the security specification associated with the rule for the command execution.

• Use of the Automation Options screen (screen OA) and authority to perform actions on Automation Options entities.

• Use of the XAM Interface. Verifies the authority of the user to execute a function using the XAM Interface.

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.

Implementing Control-O Security

This chapter details the steps required to implement the Control‑O security interface.

The Control-O security interface can be installed either as part of the customized installation path, or during the Customization process after installation. Both options use the INCONTROL Installation and Customization Engine (ICE) application. If you are not familiar with the ICE interface, see the INCONTROL for z/OS Installation Guide: Installing.

The Control‑O security interface cannot be implemented until IOA security is implemented. Verify that IOA security is installed before implementing Control‑O security.

For Control‑M Event Manager (CMEM) Users

If CMEM security is already implemented, it is not necessary to implement Control‑O security. Part of the Control‑O security implementation is already handled using CMEM security. However, it is necessary to review all the required security definitions described below to protect the additional elements in Control‑O.

To install the Control-O security interface

1. Enter the main ICE screen.

2. Select Customization.

3. Enter CTO in the Product field.

4. Select Security Customization.

5. Perform all major and minor steps required to install the security product.

Step 1. Implement Control-O Security

Follow the steps below to implement Control‑O security.

Step 1.1 Grant Access Permissions

1. Collect the data you need to define the INCONTROL entities and user authorizations to the security product.

2. In ICE, run the steps "ControlO Security Definitions (Sample)" and "Functions Security Definitions (Sample)" to create two sample jobs.

3. Submit the jobs to define security to IOA and ControlO.

Step 1.2 Customize Security Parameters

Table 58 Security Parameters

Step 1.3 Save Security Parameters into Product

This step saves all the security parameters specified for Control‑O.

When this step completes, the Status column is automatically updated to COMPLETE.

Step 2. RACF Security Definition Samples

Step 2.1 Control-O Security Definitions

Step 2.2 Function Security Definitions

Step 2.3 Control Program Access to Datasets

Select these steps to edit members CTOSRAC2, CTOSRAC3, and CTOSRAC4.

Perform the following steps to define the required permissions.

1. Associate Users with Extended Definition Mode

   1. To define the entity $$CTOEDM.qname, use the following command:

      Copy

      RDEFINE FACILITY $$CTOEDM.qname UACC(NONE)

   2. To authorize USERA to Extended Definition mode, use the following command:

      Copy

      PERMIT $$CTOEDM.qname ID(USERA) CLASS(FACILITY) ACCESS(READ)

   3. Submit the CTOSRAC2 job.

      This job must be run under the user ID of an administrator who has authorization to enter these commands.

   4. Scan the output of the job for information and error messages. All job steps must end with a condition code of 0.

2. Define entities and user authorizations.

   For more information about entities and user authorizations, see Control-O Basic Definition Security Calls, and Control-O Extended Definition Security Calls.

   To define and authorize the entity in Extended Definition mode to protect ordering of Control‑O rules beginning with SYS, specify the following command:

   Copy

   RDEFINE FACILITY $$CTOORD.qname.SYS* UACC(NONE)
   PERMIT $$CTOORD.qnam.SYS* CLASS(FACILITY) ID(USERA) ACCESS(READ)

   where qname is the name used to assign different authorizations to different ControlO environments (for example, Test and Production). This parameter is specified during IOA installation.

   To authorize USERA access to a given Control‑O entity, use the following command:

   Copy

   PERMIT $$CTOnnn.qname CLASS(FACILITY) ID(USERA) ACCESS(READ)

   where CTOnnn is the name of the ControlO entity to be accessed.

   All entity names for each ControlO protected element appear in Basic Definition Mode and Extended Definition Mode.

   For samples of user authorizations, review member CTOSRAC3 in the IOA INSTWORK library.

Step 3. TopSecret Security Definition Samples

Step 3.1 Control-O Security Definitions

Step 3.2 Function Security Definitions

Step 3.3 Control Program Access to Datasets

Step 3.4 Define CTO to TopSecret Facility Matrix

Select these steps to edit members CTOSTSS2, CTOSTSS3, CTOSTSS4, and CTOSTSS5.

Perform the following steps to define the required permissions.

1. Define ControlO to the TopSecret Facility Matrix.

   The ControlO monitor must be defined in the TopSecret Facility Matrix. The CTOSTSS2 member in the IOA INSTWORK library contains the necessary command to dynamically define ControlO in the TopSecret Facility Matrix.

   1. Modify USER4 in the Facility definition command to a free entry in the Facility Matrix, as follows:

      TSS MODIFY FAC(USER4=NAME=CTO)

      This command defines ControlO in the Facility Matrix until the next IPL.

   2. To permanently define the facility, update the TopSecret parameter member. This member is usually called TSSPARM0.

   3. Copy the ControlO facility definition from member CTOSTSS5 in the IOA INSTWORK library to member TSSPARM0.

   4. Update the Facility Matrix entry name with the same name that is specified in the TSS MODIFY command above.

2. Define ControlO ACID to TopSecret by changing the value of parameter DEPT from sec-administrator-dept to the appropriate ACID: as follows:

   TSS CRE(CONTROLO) NAME (...) DEPT(sec-administrator-dept)

3. Define ControlO started tasks to TopSecret by changing the ACID definition in the following commands to the appropriate ACID:

   TSS ADD(STC) PROC(CONTROLO) ACID(CONTROLO)

4. Allow ControlO ACID to ControlO datasets.

   Authorizations to access ControlO datasets are defined during the ControlO installation process. This step must be completed before proceeding with security implementation. For information about how to grant users access to ControlO datasets, see the ControlO chapter of the INCONTROL for z/OS Installation Guide: Installing.

5. Connect the appropriate profile to the ControlO ACID with the following command:

   TSS ADD(CTO) PROF (profile-name)

6. Define entities and user authorizations in TopSecret.

   For information about entities and user authorizations, see Control-O Basic Definition Security Calls and Control-O Extended Definition Security Calls.

   1. Modify the following command to establish ownership of the resources in TopSecret to the appropriate owner:

      TSS ADD(sec-administrator-dept) IBMFAC($$CTO)

      For samples of user authorizations, review member CTOSTSS3 in the IOA INSTWORK library.

      All entity names for each ControlO protected element appear in Control-O Basic Definition Security Calls for Basic Definition mode and in Control-O Extended Definition Security Calls for Extended Definition mode.

7. Associate users with Extended Definition Modes.

   1. Customize the following TopSecret command to establish Extended Definition mode for the ControlO installer.

      TSS PERMIT(USERA) IBMFAC($$CTOEDM.qname) ACC(READ)

   2. Modify USERA to the UID of ControlO installer.

      Do not define the $$CTOEDM entity to operate in warning mode because this causes all users to operate in Extended Definition mode.

8. Authorize the ControlO installer to use ControlO facilities.

   1. Customize the following command to authorize USERA access ControlO:

      TSS ADD(USERA) IBMFAC($$CTO)

   2. Modify USERA to the user ID of the ControlO installer.

   3. Customize the following command to authorize the ControlO installer to use ControlO facilities:

      TSS PERMIT(USERA) IBMFAC($$CTO) ACC(READ)

9. Submit the job.

   This job must be run under the ACID of the general security administrator (SCA) who has authorization to enter these TopSecret commands.

   All job steps must end with a condition code of0.

Step 4. ACF2 Security Definition Samples

Step 4.1 Control-O Security Definitions

Step 4.2 Function Security Definitions

Step 4.3 Control Program Access to Datasets

Select this step to edit member CTOSSAF2, CTOSSAF3, and CTOSSAF4 in the IOA INSTWORK library.

1. Define ControlO started tasks under ACF2.

   1. Define the ControlO started tasks (CONTROLO and the ControlO servers CTOSRVxx) as valid started tasks under ACF2.

   2. Add the multi-user address space (MUSSAS) parameter to the logon ID record that is created for the ControlO started task.

2. Associating users with Extended Definition Mode.

   1. Edit member CTOSSAF2 in the IOA INSTWORK library, add the following ACF2 commands to define the $$CTOEDM entity to ACF2/SAF, and authorize users to this entity.

   2. Define and authorize the entity $$CTOEDM.qname to ACF2 using the following commands:

      Copy

      SET RESOURCE(CMF)
      COMP
      $KEY($$CTOEDM.qname)
       UID(USERA) ALLOW

3. Define Entities and User Authorizations to CAACF2/SAF

   For more information about entities and user authorizations, see Control-O Basic Definition Security Calls, and Control-O Extended Definition Security Calls.

   To authorize USERA (the user ID of the Control‑O installer) access to a given Control‑O entity, use the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$CTOnnn.qname) TYPE(CMF)
    UID(USERA) ALLOW

   where qname is the name used to assign different authorizations to different ControlO environments (such as Test and Production). This parameter is specified during IOA installation.

   Change USERA to the UID string of the ControlO installer.

   All entity names for each ControlO protected element appear in Control-O Basic Definition Security Calls for Basic Definition mode and Control-O Extended Definition Security Calls for Extended Definition mode.

   For samples of user authorizations, review the CTOSSAF3 member in the IOA INSTWORK library.

4. Submit the Job

   This job must be run under a user of an ACF2 administrator who has authorization to enter these ACF2 commands.

   Scan the output of the job for information and error messages produced by ACF2. All job steps must end with a condition code of 0.

Control-O Security Interface Modules

This section describes the Control‑O security interface modules.

Control-O Basic Definition Security Calls

Table 59 Control‑O Basic Definition Security Calls

Control-O Extended Definition Security Calls

Table 60 Control‑O Extended Definition Security Calls

Module CTOSE01

The CTOSE01 module is the security module of Control‑O Exit CTOX001. It is used to verify that the user is authorized to order the Control‑O rule. A security check is issued to verify if the logged on (current) user is allowed to order rules on behalf of the user ID specified in the OWNER field of the rule definition.

In TSO or ROSCOE/ETSO, the CTOSE01 module is executed under the address space of the logged on user. In the IOA Online monitor environments (CICS, IMS, ROSCOE, VTAM, and so on) the CTOSE01 module is executed under the address space and TCB of the Online monitor.

Basic Definition Mode

A security check verifies if the user is authorized to use the user ID (owner) in the rule definition.

RACF Security

For this verification:

Entity Checked: owner.SUBMIT

Class: SURROGAT

where owner is the user ID specified as the owner of the Control‑O rule.

A user who is authorized to submit a job on behalf of another user is also authorized to order Control‑O rules owned by that user.

TopSecret Security

The TopSecret Application Interface module (TSSAI) is called with the following parameters:

Resource Class: ACIDCHK

Resource Name: owner

where owner is the user ID specified as the owner of the Control‑O rule.

A user who is authorized to submit a job on behalf of another user is also authorized to order Control‑O rules owned by that user.

The following TopSecret command permits USERA to order a rule with ownerid set to USERB:

TSS PERMIT(USERA) ACID(USERB)

ACF2/SAF Security

For this verification:

Entity Checked: $SUBMIT.owner

Class: FACILITY

where owner is the user ID specified as the owner of the Control‑O rule.

Extended Definition Mode

A security check verifies if the user is authorized to specify the user ID (owner) in the rule definition. The class checked is always FACILITY.

RACF Security

The entity checked for this verification is:

$$CTOORD.qname.owner

where owner is the user ID specified as the owner of the Control‑O rule.

TopSecret Security

The entity checked for this verification is:

$$CTOORD.qname.owner

where owner is the user ID specified as the owner of the Control‑O rule.

Use the following command to permit USERA to order Control‑O rules owned by USERB:

TSS PERMIT(USERA) IBMFAC($$CTOORD.qname.USERB) ACC(READ)

ACF2/SAF Security

The entity checked for this verification is:

$$CTOORD.qname.owner

where owner is the user ID specified as the owner of the Control‑O rule.

Use the following command to permit USERA to order Control‑O rules owned by USERB:

SET RESOURCE(CMF)
COMP
$KEY($$CTOORD.qname.owner) TYPE(CMF)
 UID(USERA) ALLOW

Module CTOSE02

The CTOSE02 module is the security module of Control‑O Exit CTOX002. It is used to verify that the owner of a Control‑O rule is allowed to specify the DO statements or ON statements specified in the rule definition. The module builds a list of security calls, one call for each DO statement and one call each for certain ON statements. For the rule to be loaded, the owner of the rule must have the authority to request all of the statements specified in the rule definition. If authorization fails for one of the calls, the entire rule load is canceled.

IOA performs a security check in which the CLASS checked is always FACILITY. The entity checked for each DO statement depends on if Basic Definition mode or Extended Definition mode is used.

Basic Definition Mode

The structure of the entity is as follows:

Table 61 CTOSE02 Basic Definition Entity Structure

In the above entities, command-text or msg‑text represents the first 21 characters of the command text or message text. Note the following points regarding text of commands and messages within these entities:

• Multiple nonalphanumeric characters are replaced by one period.

• The period at the end of the text is dropped.

• All nonalphanumeric characters (blanks, commas, and so on) are replaced by periods.

For more details and examples, see IOA Security including Module IOASE12.

Extended Definition Mode

The structure of the entity is as follows:

Table 62 CTOSE02 Extended Definition Entity Structure

In the above entities, command-text or msg‑text represents the first 21 characters of the command text or message text. Note the following regarding text of commands and messages within these entities:

• Multiple nonalphanumeric characters are replaced by one period.

• The period at the end of the text is dropped.

• All nonalphanumeric characters (blanks, commas, and so on) are replaced by periods.

For more details and examples regarding this issue, see Module IOASE12.

Module CTOSE03

The CTOSE03 module is the security module of Control‑O Exit CTOX003. This module verifies that the user ID associated with the rule is authorized to execute a DO TSO, DO KSL, or DO SHELL statement before the statement is executed. Depending on the value of the rule’s RUNTSEC parameter, this user ID is either the owner of the rule, or the user ID of the user who issued the message or issued a command that triggered the rule.

Basic Definition Mode

Two security checks are performed for different entities:

• The first check verifies that the user is authorized to use the specific environment procedure for execution of a DO TSO or DO KSL statement. The environment is determined by subparameter INITPROC of the DO TSO/KSL statement. IOA issues a security check to verify authorization in which the CLASS checked is FACILITY and the entity checked is:

  Copy

  $$CTOPRC.qname.envprc

• The second check verifies that the user is authorized to execute the specific DO TSO, DO KSL, or DO SHELL statement. IOA issues a security check to verify authorization in which the CLASS checked is FACILITY and the entities checked are:

  Copy

  DO TSO
  $$CTOTSO.qname.commandtext

  Copy

  DO KSL
  $$CTOKSL.qname.commandtext

  Copy

  DO SHELL
  $$CTOSHL.qname.command text

• In the above entities, command text represents the first 21 characters of the command text. Note the following regarding text of commands within these entities:

  • Multiple nonalphanumeric characters are replaced by one period.

  • The period at the end of the text is dropped.

  • All nonalphanumeric characters (blanks, commas, and so on) are replaced by periods.

For more details and examples, see the description of the IOASE12 IOA security module in IOA Security.

Extended Definition Mode

Under this mode of operation, the security module verifies the user’s authorization to execute a specific DO TSO or DO KSL statement within a specific environment procedure. The environment is determined by subparameter INITPROC of the DO TSO/KSL statement. IOA issues a security check to verify authorization, in which the CLASS checked is FACILITY and the entities checked are:

DO TSO: $$CTOPTS.qname.env‑prc.command‑text
DO KSL: $$CTOPKS.qname.env‑prc.command‑text

For a DO SHELL statement, the security module verifies that the user is authorized to execute a specific statement. IOA issues a security check to verify authorization, in which the CLASS checked is FACILITY and the entities checked are:

DO SHELL: $$CTOSHL.qname.command-text

In the above entities, command‑text represents the first 14 characters of the command text. Note the following regarding text of commands within these entities:

• Multiple nonalphanumeric characters are replaced by one period.

• The period at the end of the text is dropped.

• All nonalphanumeric characters (blanks, commas, and so on) are replaced by periods.

For more details and examples, see the description of the IOASE12 IOA security module in IOA Security.

Module CTOSE04

The CTOSE04 Control‑O security module is used to verify the user’s authority to access Automation Options screens and perform actions on specific Automation Option entities and on specific Control‑O/COSMOS Online entities.

The Automation Options screen handles various aspects of the automation environment. Valid Automation Options: COMMAND, CONSOLE, ENQINFO, GLOBALS, OPERATOR, SAMPLES, SERVERS and SUBSYS. Additional Automation Options can be defined at your site (by the system administrator).

For a detailed description of each Automation Option, see the Online facilities chapter of the Control‑O User Guide.

Basic Definition Mode

Initial Access to the Automation Options Screen (OA)

IOA security performs a security check to verify authorization for the option. The CLASS checked is FACILITY. The entity checked is:

$$CTOAOP.qname.option‑name.ENTRY

Subsequent Operations in Screen OA

For every action that is performed on this screen, security is checked to verify authorization for the action. The CLASS checked is FACILITY. The entity checked is:

$$CTOAOP.qname.option.object

where

• option is the name of the Automation Option selected under screen OA.

• object is the text (1– 8 characters) identifying the object on which the action is performed.

Extended Definition Mode

Initial Access to the Entry Panel for the Automation Options Screen

A security check verifies authorization for the option in which the CLASS checked is FACILITY and the entity checked is:

$$CTOAOP.qname.option name.ENTRY

Subsequent Operations in Screen OA

For every action that is performed on this screen, security verifies authorization for the action in which the CLASS checked is FACILITY and the entity checked is:

$$CTOAOP.qname.option.object.action

where

• option is the name of the Automation Option selected under Screen OA.

• object is the text (1 through 8 characters) identifying the object on which the action was performed. When the CTOSE04 module cannot determine the object on which the action was performed, the word ACTION is used for the object.

• action is the action (one character) entered in the Automation Options screen.

For a description of the actions supported for each option, see the online facilities chapter in the Control‑O User Guide.

Module CTOSE08

The CTOSE08 Control‑O security module verifies the user’s authority to perform actions (hold, delete, and so on) on rules displayed in the Rule Status screen (Screen OS).

Functions performed by this security module depend on if Basic Definition mode or Extended Definition mode is used.

Basic Definition Mode

Initial Entry to the Rule Status Screen (Screen OS)

For every action that is performed on this screen, security verifies authorization for the action in which the CLASS checked is FACILITY and the entity checked is:

$$CTOPNLOS.qname

Subsequent Operations in the Rule Status Screen (Screen OS)

For all actions (hold, free, delete, and so on) that are performed on this screen, security verifies authorization.

The check verifies that a user who submits jobs with parameter USER has authority equal to that of the rule’s owner. A user who is authorized to submit a job on behalf of others is also authorized to perform specific actions (hold, delete, and so on) on rules belonging to other users. If the user is the job’s owner, the security check is bypassed.

RACF Security

The CLASS checked is SURROGAT. The entity checked is:

owner.SUBMIT

where owner is the user ID assigned to the accessed rule.

TopSecret Security

TopSecret Application Interface module (TSSAI) is called with the following parameters:

Class Name: ACIDCHK

Resource Name: ownerid

where ownerid is the user ID assigned to the accessed rule.

ACF2/SAF Security

For all actions (hold, free, delete, and so on) that are performed on this screen, IOA security verifies authorization. The CLASS checked is FACILITY. The entity checked is $SUBMIT.owner

where owner is the user ID assigned to the accessed rule.

Extended Definition Mode

Initial Access to the Rule Status Screen (Screen OS)

For every action that is performed on this screen, security verifies authorization in which the CLASS checked is FACILITY and the entity checked is:

$$CTOPNLOS.qname

Subsequent Operations to the Rule Status Screen (Screen OS)

The actions (hold, free, delete, and so on) are separated into different categories of access authority. The CLASS checked is FACILITY, and the entity checked is:

$$RULxrrr.qname.owner

where

• owner is the owner specified in the rule definition.

• x is the one digit action identifier.

• rrr is the three character identifier for each action.

Valid actions and action identifiers are listed in the table below.

Table 63 Action Identifiers

The CTOSE08 module can be used to check for authorization to display individual lines on the Rule Status screen. Since a line-by-line authorization check affects performance, Control‑O invokes the CTOSE08 module when a user enters the Rule Status screen, but does not perform security checks. Users who want to limit the lines displayed on the Rule Status screen can use the Control‑O call to the CTOSE08 module to apply security checks at this stage.

To permit USERA to hold rules owned by USERB, use the following command:

For RACF:

PERMIT $$RUL2HLD.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$RUL2HLD.qname.USERB) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$RUL2HLD.qname.USERB) TYPE(CMF)
 UID(USERA) ALLOW

Module CTOSE10

The CTOSE10 Control‑O security module supports protection of Control-O rule triggering. CTOSE10 is invoked before triggering a rule to check if the user who issued the triggering event (message, command, and so on) is authorized to trigger the rule.

There is no security exit CTOX010 and there is no distinction between basic and extended security mode.

CTOSE10 will be invoked if the feature is enabled (variable DFMO10 set to PROD or TEST, as described in Class name customization) and the rule includes the following statement anywhere in the rule:

DO SET =  %%PROTRULE=Y

The entity name that represents the rule and which is protected by SAF (for example, RACF) is constructed as follows:

$$CTOSRL.ioaqname.rule-name.type.table.dsn

where

• ioaqname is the IOA QNAME of the installation

• rule-name is the name of the rule which is taken from the first ON statement in the rule

• type is the rule type and can be of the following:

  Copy

  COMMAND

  Copy

  DSNEVENT

  Copy

  MESSAGE

  Copy

  CTOPCMSG

  Copy

  JOBARRIV

  Copy

  STRING

  Copy

  JOBEND

  Copy

  STEP

  Copy

  OMEGAEXP

  Copy

  SYSOUT

  Copy

  RULE

  Copy

  MVALARM

  Copy

  SMS

• table is the rules table (member) name

• dsn is the rules library name

The constructed entity name is not necessarily unique, since it is possible to define multiple rules in the same table with the same first ON statement

Class name customization

The entity name may exceed 39 characters, and therefore a class that supports a higher limit should be used instead of the FACLITY class. The XFACILIT class is used as the default class. The class name can be customized by setting parameter IOAXCLASS as follows:

1. Enter ICE and select Customization.

2. In the Customization window, set the Product to IOA and select Security Customization.

3. Press Enter to display the Major Steps Selection screen.

4. Select major step 1, "Implement IOA Security."

5. Select minor step 2, "Customize Security Parameters."

To activate rule protection

1. If not yet applied, apply IBM APAR OA10774, which supports the XFACILIT class on z/OS systems earlier than V1R7.

2. Add the following to each rule that should be protected:

   Copy

   DO SET= %%PROTRULE=YGLOBAL  N

3. Grant READ authorization to the appropriate entities who represent the protected rules, to the users that are allowed to trigger them.

4. Customize the DFMO10 variable as follows:

   1. Enter ICE and select Customization.

   2. In the Customization window, set the Product to CTO and select Security Customization.

   3. Press Enter to display the Major Steps Selection screen.

   4. Select major step 1, "Implement Control-O Security."

   5. Select minor step 2, "Customize Security Parameters."

   6. The following values can be specified for DFMO10:

      • NO – disables the feature (default)

      • TEST – in TEST mode, the authorization is checked and RACF error messages are issued if the user is not authorized, but the rule is still invoked

      • PROD – enables the feature

5. Stop and then restart the Control-O or CTMCMEM monitor, or start a new monitor and issue the following command:

   Copy

   F <monitor>,RELOAD=CTOWTO

Module CTOSE15

The CTOSE15 Control‑O security module verifies the user’s authority to request services (INIT, RESOLVE, and so on) from the XAM (Extended Automation Mechanism) and CTOSCMD interface. For information about the XAM interface, see the Extended Automation Mechanism chapter in the Control‑O User Guide.

The function performed by this security module depends on if Basic Definition mode or Extended Definition mode is used.

Basic Definition Mode

For all actions (INIT, RESOLVE, and so on) performed by the XAM interface, IOA performs a security check for authorization. The class checked is FACILITY. The entity checked is:

$$CTOXAMF.qname

Extended Definition Mode

Actions (INIT, RESOLVE, and so on) are separated into different categories of access authority. The CLASS checked is FACILITY. The entity checked is:

$$CTOXAM.qname.TYPExrrr

where

• x is the one-digit action identifier.

• rrr is the three-character identifier for each action.

Valid actions and action identifiers are listed in the table below.

Table 64 Action Identifiers

To protect the Control‑O CTOSCMD function, the CTOSCMD rule should be protected, in addition to INIT and TERM.

Optionally including the target rule name in the checked entity

By default the security validation of the Control-O XAM DORULE action does not restrict users from invoking only specific target rules. If such restriction is required, use the option to include the target rule name in the checked entity (in extended definition mode). This option is controlled by parameter ADDRULNM in the SECPARM parameter member.

When ADDRULNM=N (default) the checked entity is:

$$CTOXAM.qname.TYPE3RUL (default).

When ADDRULNM=Y the checked entity is:

$$CTOXAM.qname.TYPE3RUL.rulename (where rulename is the target rule name of the DORULE action).

To set the option for including the target rule name in the checked entity

1. Invoke ICE.

2. On the ICE Main screen, select "Customization".

3. Select Product "CTO", "Security Customization".

4. Select step 1.2 "Customize Security Parameters".

5. Set parameter ADDRULNM to either Y or N.

6. Recreate SECPARM with a new parameter by selecting the step 1.3 "Save Security Parameters into Product".

APAR BO10168 is needed for this option.

To permit USERA to set a local variable using the XAM interface, use the appropriate command.

For RACF:

PERMIT $$CTOXAM.qname.TYPE2* ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTOXAM.qname.TYPE2) ACCESS(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTOXAM.qname.TYPE2*************) TYPE(CMF)
 UID(USERA) ALLOW