How to Protect the Use of JES Operator Commands Issued from SDSF

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 for zVM
• ACF2 - z/OS
• ACF2 - MISC
• PanApt
• PanAudit

Issue/Introduction

Description:

If there is a need to allow JES commands issued in background by SDSF but prevent JES commands issued directly from SDSF, it may be difficult to do because the OPERCMDS AUTH requests look identical. If a user PURGEs a job by entering a P beside the job on the SDSF ST display, SDSF generates the command '$CJ(nnnnn),P'. If the user enters a JES2 command directly in SDSF by issuing '/$CJOBnnnnn,P' the OPERCMDS validation that is generated looks exactly the same: the entity is JES.CANCEL.BAT with a SERVICE of UPDATE. There is no way to refine this validation by using a PROGRAM or LIBRARY in an ACF2 resource rule as that information is not available in the OPERCMDS request.

Solution:

When SDSF is used to generate the JES command the token is updated with a POE of SDSF. This allows ACF2 resource rules to be written with a SOURCE restriction. Example:

$KEY(JES****) TYPE(OPR)
CANCEL.BAT UID(xxxx......) ALLOW SOURCE(SDSF) 
CANCEL.BAT UID(xxxx....) SERVICE(READ) ALLOW
CANCEL.BAT UID(xxxx.....) PREVENT
  - UID(xxxx.....) ALLOW SOURCE(SDSF)
  - UID(xxxx.....) SERVICE(READ) ALLOW
  - UID(xxxx.....) PREVENT

This rule would allow selected users to purge a job as long as it was done using the 'p' on the ST display, but it would prevent these users any other access to the CANCEL command. Other commands with the format JESxxxxx.whatever would be validated the same.

A similar rule could be written for MVS commands:

$KEY(MVS) TYPE(OPR)
START.- UID(xxxx.....) ALLOW SOURCE(SDSF)
START.- UID(xxxx.....) SERVICE(READ) ALLOW
START.- UID(xxxx.....) PREVENT
  - UID(xxxx.....) ALLOW SOURCE(SDSF)
  - UID(xxxx.....) SERVICE(READ) ALLOW
  - UID(xxxx.....) PREVENT

Environment

Release:
Component: ACF2MS