Security

Continuing our discussion of paths into the system, here we consider security over system access through batch jobs. You want to ensure that only users defined to the security software (RACF, ACF2, or TopSecret) can submit batch jobs, both to prevent unauthorized use of your system and to protect sensitive data.

All three security software products share complications you need to understand. We’ll show you recommended batch security options, the complications, and practical approaches to address the complications. 

Batch job JCL can enter the system from the internal reader, TSO SUBMIT commands, Network Job Entry (NJE), Remote Job Entry (RJE), and File Transport Protocol (FTP, which on the mainframe can be configured to support submission of batch jobs over the Internet).

With RACF, you control batch access with a systemwide switch named BATCHALLRACF. When this is active, any batch job without a valid RACF userid is failed. (A related switch named XBMALLRACF applies only if you use the JES eXecution Batch Monitor. Ask your JES systems programmer.)

With ACF2, by default no batch job is allowed to execute unless it’s associated with a valid ACF2 userid (LOGONID). You control batch access further by setting the Global System Option (GSO) JOBCHECK, which specifies that only userids with the JOB attribute can submit batch jobs. 

You can tighten ACF2 security beyond use of JOBCHECK by assigning these userid attributes: SUBAUTH, PGM, and LIBRARY. The PGM and LIB attributes in a LOGONID record specify that only the indicated program from the indicated library is permitted to submit batch jobs for that userid. The SUBAUTH attribute on a LOGONID record specifies that batch jobs for that user can be submitted only from an APF-authorized program. 

The PSWD-JES GSO option in ACF2 specifies that invalid passwords in JOB cards should be counted when deciding to suspend a userid. This prevents someone from making unlimited guesses of another user’s password until he guesses it correctly.

With TopSecret, only userids permitted to the BATCH FACILITY can be used to execute batch jobs.   

The first batch security complication is userid inheritance. (We will address further complications in the next column.)

If I logon to TSO with my userid STU and submit JCL for a batch job, the batch job inherits my userid STU, unless I specify a different userid on the JOB card. (Another way of saying this is that my userid is propagated onto the batch job I submit.) This works fine for a TSO user submitting his own work. However, weak security can result when the job scheduling software submits a production batch job. Suppose the job scheduling software is a started task named SCHED, with the userid SCHEDUSR. If it submits a production Marketing job and then a production Payroll job, the same inheritance applies. The Marketing job inherits the userid SCHEDUSR, and so does the Payroll job. Then both production applications look the same to the security software. It is then practically impossible to prevent a Marketing job from updating a Payroll data set, since all production jobs share the same inherited userid.

The solution to this is to include a USER= parameter on each production JOB card (or for ACF2, a LOGONID card), specifying a userid unique to that application. So, all the Payroll jobs execute with USER=PAYROLL, etc. In addition, the data set rules for Payroll data sets permit only userid PAYROLL to access them.

Specifying a different userid with USER= on a JOB card generally requires you to specify the password as well. Of course, you don’t want to specify passwords here. There are several ways to finesse this problem. Most common (since it works with all three security software packages) is the SURROGAT resource class. This is used to permit the userid SCHEDUSR to submit batch jobs with USER=PAYROLL, etc. without having to provide the password. 

ACF2 offers another approach with less specific control. In ACF2, the JOBFROM attribute on a userid lets that user submit batch jobs for any userid without having to provide the password. ACF2 installations may prefer the greater control provided by SURROGAT over the use of JOBFROM, since JOBFROM permits submission for any userid, not just specified userids.

TopSecret gives us both types of permission. Like JOBFROM in ACF2, the TopSecret privilege NOSUBCHK permits a userid to submit batch jobs for any userid without having to specify the password. For greater control, TopSecret installations can use either SURROGAT or the ACID(xxx) permission to let one userid submit batch jobs for specified other userids.

Stay tuned, as the next column will continue with batch job security complications and solutions.