5.  PJS Security Issues

 

 

Some thought must be given to system security and integrity.  Without proper precautions, it may be possible for an unauthorized user to use PJS to submit jobs with a different user‑ID.  Exit points and sample exits are provided to insure a completely secure environment.  The specific steps required to provide adequate security will vary greatly from installation to installation, so detailed instructions cannot be given.  Rather, this section is intended to give an overview of some of the things that should be considered.  Although much of the discussion assumes a RACF environment, it should be apply to other security environments as well.

 

 

5.1   Securing the PJS Software

 

The first step to securing PJS is to secure the PJS software itself.  All of the PJS libraries, in general, should be protected from unauthorized modifications just as you would protect any other production software system.  The PJSLOAD library and the PJS Request Queue should be further secured.  The programs contained in the PJSLOAD library are not generally required to be made available to users.  The PJSLOAD library should therefore be in a data set with limited access.

 

The PJS system task (PJSTASK) must be authorized so that it can send messages to online TSO users via the TSO SEND command.  Also, many security schemes (including that provided by the sample security exit provided) will require authorization.  The PJS Request Queue Maintenance Utility (PJSQMNT) requires authorization to call IEBCOPY to compress the PJS JCL Spool data set. No other programs require authorization, and should not be link-edited with AC=1.

 

 

5.2   Securing the PJS Data Sets

 

Most of the effort to secure PJS will involve protecting the PJS Request Queue and the PJS JCL Spool data sets from unauthorized access. This is complicated by the fact that the user must be able to update these data sets when using the PJS programs.  The user must not, however, be able to update them by any other means.  This can be accomplished using RACF program access control through a conditional access list.

 

To protect the data set with program access control, RACF profiles for the PROGRAM class must be created for the PJS TSO commands in the PJSCMD library (a generic profile name may be used for this purpose).  The PROGRAM profile(s) used must include the PJSCMD and PJSLINE libraries in the ADDMEM clause with the NOPADCHK option.  A RACF profile for the PJS request queue data set must be created with a conditional access list granting access when the PJS programs in PJSCMD are being executed.  Member RACFPROF in the PJSINST library contains sample RACF commands for creating the RACF profiles. Please note that this is an example only.  Some of the statements may not be appropriate for your installation, and other RACF statements may be required. Refer to the appropriate RACF documentation for authoritative information.

 

The PJS TSO commands (listed in Appendix A) may also need to be defined in the TSO authorized command table (IKJTSO00 in SYS1.PARMLIB, or CSECT IKJEFTE2).  (Although the PJS TSO commands do not require authorization, RACF program access control requires the secure environment TSO creates for a program in the authorized command list.  Since the programs are not linked with AC=1, no APF authorization is actually conveyed to the program.)  Member IKJTSO00 in the PJSINST library contains sample IKJTSO00 parameters to define the PJS TSO commands.

 

 

5.3   Securing the PJS Request Queue Records

 

The PJS Installation Security Exit can be used to define the type of access each user can have to each job request record in the PJS Request Queue.  When you define access rules, remember that if a user can add or update job requests having an Owner‑ID other than her or his own, that user may be able to submit jobs using the other user's User‑ID.  (This might depend on how you protect submitted batch jobs.)  It is recommended that either users be permitted to add and update only job requests with their own User‑ID, or that the PJS Installation Security Exit be written to record the RACF User-ID of the last user to update the request be recorded in the PJS Job Request record Installation Data Area, and use that User-ID for data set access and job submission.

 

 

5.4   Securing Batch Jobs Submitted by PJS

 

PJS submits batch jobs from the PJS System Task.  The main task attaches a subtask to perform the actual submit.  The submit subtask will terminate when the submit is complete.  The PJS Installation Security exit is called at the beginning of the submit.  The security exit can issue a RACINIT macro for the user owning the request record.  This will update the submit task's TCB to point to the ACEE created by the RACINIT for the owning user. All JCL data set access will then be done under the user‑ID of the job request owner.  Alternatively, the PJS Installation Security Exit is also called when the JCL data set is opened.

 

The PJS system task submits the job exactly as it is in the JCL data set.  The installation should take whatever steps are necessary to ensure that the job is run under the correct RACF User‑ID and Group.  In a JES2 environment, Exit 2 can be very useful for this purpose.  Exit 2 has access to the RACF User‑ID and Group of the task submitting the job. (This is in RIDSUSR and RIDSGRP in the JES2 DCT for the reader.  The DCT address is in PCEDCT in the JES2 PCE, which is in register 13 at entry to the exit.) The exit can force these fields into the job card for every batch job submitted in the system.  Once it can be certain that every job has the correct USERID and GROUP parameters on the JOB card, batch jobs can be run without further password verification.  Other schemes may also be possible.