Protect Operator Commands

You can protect operator commands using CA ACF2. When an operator command is issued, SAF issues a CMDAUTH call to the CA SAF interface. This turns into a RACROUTE REQUEST=AUTH, class="OPERCMDS" call. CA ACF2 does not process REQUEST=AUTH,CLASS=OPERCMDS calls. You must create a SAFDEF record to define the SAF call, a CLASMAP record to translate the resource class into a type code, and resource rules to validate the use of the operator commands.
acf2src
You can protect operator commands using CA ACF2. When an operator command is issued, SAF issues a CMDAUTH call to the CA SAF interface. This turns into a RACROUTE REQUEST=AUTH, class="OPERCMDS" call. CA ACF2 does not process REQUEST=AUTH,CLASS=OPERCMDS calls. You must create a SAFDEF record to define the SAF call, a CLASMAP record to translate the resource class into a type code, and resource rules to validate the use of the operator commands.
2
2
Creating a SAFDEF Record
To create a SAFDEF record for the OPERCMDS class, issue these commands:
set control(gso) GSO insert safdef.opr id(opercmds) jobname(-) mode(global)- racroute(request=auth,class=opercmds) userid(-) rep
Creating a CLASMAP Record
This step is optional. If you do not add this CLASMAP record, CA ACF2 translates the class to the default, SAF. In the example, we selected OPR.
acf ACF set control(gso) GSO insert clasmap.opr resource(opercmds) rsrctype(opr)
Adding Resource Types to INFODIR Record
After you create the CLASMAP record, add the OPR type code to the GSO INFODIR record. To update the INFODIR record, enter these commands:
acf ACF set control(gso) CONTROL change infodir types(r-ropr)
Refreshing GSO Records
These changes do not take effect until you refresh the Infostorage database by issuing the following command:
F ACF2,REFRESH(infodir),SYSID(sysid),CLASS(c),TYPE(gso)
Writing Resource Rules
Now you need to decide which users can issue the SECTRACE commands. You might write a resource rule like the following:
acf ACF set resource(opr) RESOURCE compile * store .$key(trce) type(opr) . sectrace.- uid(oper-) service(read,update) allow .end
The sample rule uses the first-level qualifier of the entity TRCE.SECTRACE.- in the $KEY. The second-level qualifier is masked in the rule entry to indicate that we want the rule to apply to all SECTRACE resources. We granted access to UIDs that begin with OPER.
For some operator commands, you might have to specify a SERVICE, such as READ or UPDATE.
To write a rule, you need the name of the resource that you want to secure. In SAF, these names are referred to as entity names. In CA ACF2 these names are referred to as resource names. SAF entity names are listed in the appropriate IBM guide. The resource names for CA ACF2 operator commands are listed in Resource Names for CA-ACF2 Operator Commands later in this appendix.
Rebuilding Infostorage Directories
Anytime you create a new resource rule, you must rebuild that resource directory; otherwise, the pointers to the new rule are not built and CA ACF2 does not recognize that the new rule exists. If the class has SIGNAL defined, an ENF 62 signal will be sent as part of the REBUILD command to indicate to applications that a new rules may exist.
To rebuild the infostorage directory, issue the following operator command:
F ACF2,REBUILD(opr),CLASS(r)
Resource Names for CA ACF2 Operator Commands
The following tables list the CA ACF2 operator command, the SERVICEs required in the resource rule, and the resource name.
Operator Commands
The CA ACF2 operator commands, START, STOP, and MODIFY have the following resource names: (You cannot specify parameters, such as BACKUP, REFRESH, or SWITCH without access to the resource named below.) The resource names specified in the following table were derived with the assumption that the jobname and ID associated with the CA ACF2 started task is the literal string ‘ACF2’, as noted by the last two qualifiers in the resource names below.
Command/Keyword
SERVICE
Resource Name
MODIFY ACF2
UPDATE
MVS.MODIFY.STC.ACF2.ACF2
START ACF2
UPDATE
MVS.MODIFY.STC.ACF2.ACF2
STOP ACF2
UPDATE
MVS.MODIFY.STC.ACF2.ACF2
SECTRACE Operator Commands
The SECTRACE operator commands, the required SERVICEs, and their source names are listed in the following:
Command/Keyword
SERVICE
Resource Name
SECTRACE DELETE
UPDATE
TRCE.SECTRACE.DELETE
SECTRACE DISABLE
UPDATE
TRCE.SECTRACE.DISABLE
SECTRACE DISPLAY
READ
TRCE.SECTRACE.DISPLAY
SECTRACE LOGERR
UPDATE
TRCE.SECTRACE.LOGERR
SECTRACE MODIFY
UPDATE
TRCE.SECTRACE.MODIFIED
SECTRACE NOLOGERR
UPDATE
TRCE.SECTRACE.NOLOGERR
SECTRACE SET
UPDATE
TRCE.SECTRACE.SET
Translating SAF Levels to CA ACF2 SERVICE Keywords
IBM documents the SAF access authority level for each of the MVS console commands. These authorities have their CA ACF2 counterparts. You must use the SERVICE parameter and the appropriate keywords to properly define the validation that you want CA ACF2 to perform.
The following table lists the SAF authority levels and the CA ACF2 SERVICE keyword:
SAF Authority Level
CA ACF2 SERVICE Keyword
ALTER
ADD
CONTROL
DELETE
READ
READ
UPDATE
UPDATE
Suppose you want to write a rule to protect the following command:
MVS CANCEL jobname
The authority level is UPDATE and the SAF resource name is MVS.CANCEL.JOB.jobname. For STCs, the resource name is MVS.CANCEL.STC.jobname. Here is how you might write a resource rule to validate the authority to issue these commands:
set resource(opr) RESOURCE compile * store .$key(mvs) type(opr) . cancel.job.- uid(oper) service(update) allow . cancel.stc.- uid(oper) service(update) allow . end
This rule lets all UIDs that begin with OPER issue the z/OS CANCEL jobname command.
If you enter the SERVICE as READ,
CA ACF2
prevents the OPER logonids from issuing the commands.