search cancel

SDSF External Security with ACF2 for z/OS 2.5

book

Article ID: 28218

calendar_today

Updated On:

Products

ACF2 ACF2 - DB2 Option ACF2 - z/OS ACF2 - MISC

Issue/Introduction

System Display and Search Facility (SDSF) uses SAF to make its initial call for external security. In z/OS 2.4 and below, if external security ignores the call, then SDSF internal security is used utilizing the ISFPARMS dataset. Starting with z/OS 2.5, SDSF internal security cannot be used and setting up SAF external security is a requirement for SDSF. Possible errors seen when using internal SDSF security include ISF024I, ISF015I, ISF458E, or ISF452E.  

The benefits of using the SAF interface for SDSF security is:

  • Dynamic change of security resource rules
  • Single image of security information
  • Simple introduction of security philosophy
  • Improved auditability
  • Improved protection

SDSF interacts with SAF to control access to the following SDSF resources:

  • SDSF panels
  • SDSF authorized commands
  • Use of the / command to issue MVS and JES2 commands and receive responses
  • Overtypeable fields
  • Destination names
  • Operator authority by destination
  • Initiators
  • Printers
  • Lines
  • Nodes
  • Offloaders
  • Members of a MAS
  • Scheduling environments
  • WLM resources
  • Jobs affected by action characters and overtypeable fields
  • Output groups affected by action characters and overtypeable fields
  • SYSIN/SYSOUT data sets for browsing and viewing
  • MVS and JES2 commands that are generated by action characters and overtypeable fields
  • Use of the server MODIFY command

Environment

Release:
Component: ACF2MS

Resolution

ACF2 GSO SAFDEF/CLASMAP Configuration

SDSF resources are protected externally through the SDSF, WRITER, JESJOBS, JESSPOOL, JOBCLASS and OPERCMDS SAF resource classes. The SDSF resource class protects panels, overtypeable fields, MVS/JES line commands, initiators, lines, nodes, readers, job classes, and so forth. See the SDSF Customization and Security Guide for the full details.

By default, CA-ACF2 normally ignores these SDSF, WRITER, JESJOBS, JESSPOOL and OPERCMDS SAF calls and has internally coded SAFDEFs set to IGNORE. To enable CA-ACF2 security for any of the SDSF resources, the corresponding internal SAFDEF has to be overridden by inserting a locally defined SAFDEF. The following SAFDEF records are examples of doing this for each resource class:

SET Control(GSO)
Insert SAFDEF.SDSF ID(SDSF)MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=SDSF)
Insert SAFDEF.WRITER ID(WRITER) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=WRITER)
Insert SAFDEF.JESJOBS ID(JESJOBS) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=JESJOBS)
Insert SAFDEF.JESSPL ID(JESSPL) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=JESSPOOL) 
Insert SAFDEF.OPRCMDS ID(OPRCMDS) MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=OPERCMDS)
F ACF2,REFRESH(SAFDEF)

Note: After creating any of these SAFDEFs and refreshing the CA-ACF2 GSO SAFDEF records, validation for each of these resources is active. Before activating these classes, ensure that all of the necessary rules are in place to allow the desired accesses. Since CA-ACF2 defaults the resource classes used by SDSF to the generic type code of SAF, it is recommended that each protected class should map to its own unique type code to avoid confusion. This is done using the GSO CLASMAP record. The following are examples of setting each of the SDSF resource classes to its own unique type code:

SET Control(GSO)
Insert CLASMAP.SDSF RESOURCE(SDSF) RSRCTYPE(SDF) ENTITYLN(63)
Insert CLASMAP.JESJOBS RESOURCE(JESJOBS) RSRCTYPE(JOB) ENTITYLN(39)
Insert CLASMAP.WRITER RESOURCE(WRITER) RSRCTYPE(WTR) ENTITYLN(39)
Insert CLASMAP.JESSPL RESOURCE(JESSPOOL) RSRCTYPE(SPL) ENTITYLN(53)
Insert CLASMAP.OPRCMDS RESOURCE(OPERCMDS) RSRCTYPE(OPR) ENTITYLN(39)
F ACF2,REFRESH(CLASMAP)

The ISF.CONNECT.xxxx validation is issued via RACROUTE REQUEST=FASTAUTH,CLASS=SDSF call. For this process to work successfully, the rules and directory for the type must be globally resident as follows:

SET CONTROL(GSO)
CHANGE INFODIR TYPES(R-RSDF) ADD
F ACF2,REFRESH(INFODIR)
F ACF2,REBUILD(SDF)

Class SDSF Resources


ISF.CONNECT Class SDSF resource

With z/OS 2.2 and above, there is a new resource for the ISF.CONNECT.system resource profile. To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class.

SDSF resource class ISF.CONNECT rule example to allow a user to connect to the SDSF server follows:

$KEY(ISF) TYPE(SDF)
CONNECT.system UID(user UID string) SERVICE(READ) ALLOW

SERVER.NOPARM Class SDSF resource

When a user accesses SDSF, the SDSF client program attempts to connect to the SDSF address space (also referred to as the SDSF server). To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class.

If the SDSF address space is not active, or if access to the ISF.CONNECT.system resource fails, SDSF allows for users to have limited functionality if they have READ access to the SERVER.NOPARM resource in the SDSF class so that ISFPARMS can be used instead of ISFPRMxx. 

Class SDSF resource SERVER.NOPARM rule example:


$KEY(SERVER) TYPE(SDF)                                           
NOPARM UID(021**********USRTEST) PREVENT                      
 NOPARM UID(*) SERVICE(READ) ALLOW                               
 - UID(*************LSLESEC) ALLOW 

NOTE 1: If a user does not have access to ISF.CONNECT.system SDSF class but you have access to SERVER.NOPARM(Read access):

  • Message ISF458E Not authorized to connect to the SDSF server is received
  • The user can connect to the SDSF server and access the product in a limited capacity to resolve the issues. 

NOTE 2: The resource check for the SERVER.NOPARM resource is only done if the the SDSF address space is not active, or if the validation for the ISF.CONNECT.system resource fails.
 

ISFCMD Class SDSF resource

SDSF resource class ISFCMD rule example to protect access to the SYSLOG panel:

$KEY(ISFCMD) TYPE(SDF)
ODSP.SYSLOG. jesx UID(uid string) SERVICE(READ) ALLOW

SDSF resource class ISFCMD rule example to protect access to the DA panel:

$KEY(ISFCMD) TYPE(SDF)
DSP.ACTIVE.jesx UID(uid string) SERVICE(READ) ALLOW

ISFINIT Class SDSF resource

SDSF resource class ISFINIT rule example to protect initiators:

$KEY(ISFINIT) TYPE(SDF)
Ixx.jesx UID(uid string) SERVICE(READ) ALLOW (to allow displays)
Ixx.jesx UID(uid string) SERVICE(DELETE) ALLOW (to allow updating or overriding)

ISFOPER SDSF Class resource 

SDSF resource class ISFOPER rule examples to protect the use of operator commands, but not check the actual command:

$KEY(ISFOPER) TYPE(SDF)
SYSTEM UID(uid string) SERVICE(READ) ALLOW

ISFATTR Class SDSF resource Names and Overtypeable Fields

The resource names for the overtypeable fields are in the SDSF class or the GSDSF class and have a high level qualifier of ISFATTR. A user must have UPDATE authority to the ISFATTR resource to overtype a field. See IBM z/OS SDSF Operation and Customization Tables of overtypeable fields for the resource names for each overtypeable field.


SDSF resource class ISFATTR rule examples:

$KEY(ISFATTR) TYPE(SDF)
JOB.CLASS UID(uid string) SERVICE(UPDATE) ALLOW
OUTPUT.DEST UID(uid string) SERVICE(UPDATE) ALLOW
- UID(uid string) SERVICE(UPDATE)ALLOW

GROUP Class SDSF resources for Setting up rules for SDSF Group Authorization

If a name is not assigned a group, SDSF generates one format: ISF plus the index value of the group, in the format ISFnnnnn.

The ISFPARMS and statements shipped with SDSF use the following group names:

ISFSPROG for group 1 resource: GROUP.ISFSPROG.SDSF
ISFOPER for group 2 resource: GROUP.ISFOPER.SDSF
ISFUSER for group 3 resource: GROUP.ISFUSER.SDSF

The ISFPARMS can be found in SYS1.PARMLIB(ISFPRMxx) member and GROUP NAME shows all group names defined on the system. A name can be assigned to a group or the above SDSF groups can be used. Starting in z/OS 2.5, permits(rules) must be created to allow users READ access to the appropriate SAF resource GROUP.group-name.server-name in the SDSF class. If the user is authorized to the group, then the user is assigned to the group, regardless of whether the user is authorized to groups that occur later in ISFPARMS. If the user is not authorized to the group through the SAF profile, SDSF goes on to the next group.

SDSF works through the groups in ISFPARMS, checking for READ access to the SAF resource GROUP.group-name.server-name in the SDSF class.

Example SDSF resource class GROUP rule to allow user usera access to the appropriate group:

$KEY(GROUP) TYPE(SDF)
ISFSPROG.SDSF UID(usera uid string) SERVICE(READ) ALLOW
ISFOPER.SDSF UID(usera uid string) SERVICE(READ) ALLOW
ISFUSER.SDSF UID(usera uid string) SERVICE(READ) ALLOW

When using SAF to define who belongs to an ISFPARMS group, assign a name to each group, as follows:

  • With a GROUP statement, using the NAME parameter.
  • With an ISFGRP macro, using the macro label. The label must start in column 1 and be 1-8 characters. It must conform to standard assembler language programming conventions and be unique within ISFPARMS.


Class JESJOBS Resources


JESJOBS validation controls both job submit and job cancel activity. The resource name formats are:

SUBMIT.nodename.jobname.userid
CANCEL.nodename.userid.jobname

The following example shows a rule to allow only CA7 to submit production jobs on the production node (production jobs always start with the letter p). Anyone can submit production jobs on the test node, but they are logged.
JESJOBS resource class rule examples:

$KEY(SUBMIT) TYPE(JOB)
 prodnode.p-.- UID(ca7lid) ALLOW
 prodnode.p-.- UID(*) PREVENT
 testnode.p-.- UID(*) LOG
-.- UID(*) ALLOW

Class JOBCLASS Resources

There are two SAF calls available with JES2 and JES3 two SAF that control the use of specific job classes in z/OS 2.1 and above. These SAF calls are triggered by the existence of either of the following FACILITY class profiles.

JES.JOBCLASS.OWNER - Checks if the execution owner has access to the job class
JES.JOBCLASS.SUBMITTER - Checks if the submitting userid has access to the job class.


FACILITY resource class rule examples:

$KEY(JES.JOBCLASS.OWNER) TYPE(FAC)
uid(-) ALLOW

$KEY(JES.JOBCLASS.SUBMITTER) TYPE(FAC)
uid(-) ALLOW

Class JESSPOOL Resources

The JESSPOOL class protects Jobs, output groups, and SYSIN/SYSOUT data sets. Validation of the JESSPOOL resource class provides the ability to protect the JES2 and JES3 data sets that are generated when a job runs. JESSPOOL data sets include those created by JES such as joblog, JCL and allocation messages data sets, and user-created data sets such as SYSIN and SYSOUT.

The JESSPOOL resource name consists of a node name, userid, job name, job number, data set ID, and data set name. 

JESSPOOL resource class rule examples:

$KEY(NODE1) TYPE(SPL)
userid.jobname.- UID(prodcntl) ALLOW
userid.jobname.- UID(-) PREVENT
userid.- UID(-) LOG

Note: If a user has access to the resource class SDSF resource ISFOPER.DEST.JES2 along with access to resource class SDSF resources ISFAUTH.DEST.LOCAL.DATASET.******** SDSF will specify the RECVR parameter in the RACROUTE JESSPOOL call which will override JESSPOOL rules that would prevent access to JESSPOOL print jobs if the RECVR parameter matches the logonid accessing the JES2 datasets.

Class OPERCMDS Resources

System operator commands can be controlled through use of OPERCMDS validation. The OPERCMDS class protects generated MVS/JES commands and server Modify commands. Users issuing commands can be signed-on consoles, SDSF users, TSO/E Extended MCS consoles, or NJE commands. 

The resource name format is:

subsys.command.operand

OPERCMDS resource class rule to allow anyone to issue JES2 display commands but limit other commands to systems people would be:

$KEY(JES2) TYPE(OPR)
DISPLAY.- UID(*) ALLOW
- UID(systems) ALLOW

NOTE: A SDSF task often requires access authority to more than one class and resource name. In order to perform the task, a user must have proper authority to all of the required resources. For example, to overtype a field, a user must have access to the panel, to the overtypeable field, to the MVS or JES2 command that will be generated, and to the object (for example, the job, output group, initiator, or printer) being acted upon. The SDSF Customization and Security Guide shows these relationship for many different possibilities. Following is a specific example of rules based on the SDSF Customization and Security Guide needed to control the cancelation of a batch job from the Active jobs (DA) panel. 

OPERCMDS resource class jesx.CANCEL and MVS.CANCEL rule examples to protect the operator command follow.

To protect the operator command of canceling the job from SDSF using the '$C' command:

$KEY(jesx) TYPE(OPR)
CANCEL.type.- UID(uid string) SERVICE(UPDATE) ALLOW


To protect the operator command of canceling the job from SDSF DA Panel using the 'C U=' or 'C jobname,A=' command:

$KEY(MVS) TYPE(OPR)
CANCEL.type.jobname UID(uid string) SERVICE(UPDATE) ALLOW

Class WRITER Resources

The WRITER class protects printers and punches. With WRITER validation, you can control where data is sent. This includes output to a printer, or jobs sent through NJE to another node. Examples of resource names are:

subsys.LOCAL.device
subsys.NJE.nodename


WRITER resource class rule protecting certain printers and NJE destinations:

$KEY(JES2) TYPE(WTR)
LOCAL.printer1 UID(systems) ALLOW
LOCAL.- UID(*) ALLOW
NJE.prodnode UID(produid) ALLOW
NJE.testnode UID(*) ALLOW
- UID(*) LOG

 

Additional Information

Further details for SDSF 2.5 can be found in knowledge document 233042