Secure Spool File Management

June 30, 2004 Hey, Wayne O.

I want to allow a user to view spool files that were created by other users. Is there a way to allow this access without giving the user *SPLCTL or *JOBCTL special authority? I am trying to implement your recommendation that users should have no command line access or special authority.

–Jeannette

I get this request very often. Most installations take the easy way out and give users *JOBCTL or *SPLCTL. This works well in a low security environment, but in a financial institution you need to be very careful about what output you allow users to view.

Before I answer your question, let me explain the dangers of giving users either *SPLCTL or *JOBCTL special authority.

SPECIAL AUTHORITY *SPLCTL

The special authority *SPLCTL allows users unrestricted access to all spool files. It is similar to *ALLOBJ (all object authority), which allows unrestricted access to spooled data. Users with *SPLCTL can view, delete, and manage sensitive output like payroll and personal data. I am sure you do not want your last payroll information viewed by unauthorized persons.

I recommend that you not give users *SPLCTL if you have any sensitive output on your system (payroll, human resources, customer data). If you restrict *SPLCTL, it is possible to create output queues that can be viewed only by selected individuals. For example, users in the payroll department can view the PAYROLL output queue, but other users, including system operators with *JOBCTL special authority, cannot view the spool files.

SPECIAL AUTHORITY *JOBCTL

The special authority *JOBCTL has much less power over spool files than *SPLCTL but allows users to operate on the jobs of other users. The *JOBCTL authority would normally be given to system operators.

I recommend that you not give users *JOBCTL special authority. Users do not need special authority to manage their own jobs. If users do not have *JOBCTL, they are prevented from accessing the jobs and spooled output of other users. In a tightly controlled environment, programmers should not have *JOBCTL special authority.

USING *JOBCTL and *SPLCTL

The special authorities *JOBCTL and *SPLCTL are designed to allow selected users access to resources that are not objects (such as spool files) and cannot be controlled through object authorities. However, you can protect spool files by setting the attributes of the output queue where the spool files reside.

The output queue attributes DSPDTA, AUTCHK, and OPRCTL are used to limit the access by users. (You can use the command Work with OUTQ Description, or WRKOUTQD, to view the attributes of output queues.) You cannot directly grant or revoke authority to view and manipulate a spool file. The authority to a spool file is controlled by several parameters on the output queue that holds the spooled file.

DISPLAY ANY FILE (DSPDTA)

*NO means that a user cannot display, send, or copy spool files owned by other users, unless the user has one of the following:

• *JOBCTL special authority if the OPRCTL parameter is *YES.

• *READ, *ADD, and *DLT authority to the output queue, if the *AUTCHK parameter is *DTAAUT. Ownership of the output queue, if the *AUTCHK parameter is *OWNER.

*YES means that any user with *READ authority to the output queue can display, copy, or send the data of spool files owned by others.

*OWNER means that only the owner of a spool file or a user with *SPLCTL (spool control) can display, copy, send, or move the file. If the OPRCTL value is *YES, users with *JOBCTL special authority can hold, change, delete, and release spool files on the output queue, but they cannot display, copy, send, or move the spool files. This is intended to allow operators to manage entries on an output queue without being able to view their contents.

AUTHORITY TO CHECK (AUTCHK)

The AUTCHK parameter determines whether *READ, *ADD, and *DLT authority to the output queue allows a user to change and delete spool files owned by other users.

The possible values for AUTCHK are:

• *OWNER specifies that only the user who owns the output queue can change or delete spooled files owned by others.

• *DTAAUT specifies that any user with *READ, *ADD, and *DLT authority to the output queue can change or delete spool files owned by others.

OPERATOR CONTROL (OPRCTL)

The OPRCTL parameter determines whether a user with *JOBCTL special authority can control the output queue.

Possible values for OPRCTL are:

• *YES means that a user with *JOBCTL special authority can perform all functions on the spool files, unless the DSPDTA value is *OWNER. If the DSPDTA value is *OWNER, *JOBCTL special authority does not allow the user to display, copy, send, or move spool files.

• *NO means *JOBCTL special authority does not give the user authority to perform operations on the output queue. Normal authority rules apply to the user.

If you have sensitive spool files such as payroll data that you do not want operators or users with *JOBCTL special authority to view, set the output queue attributes to:

DSPDAT(*NO)   AUTCHK(*OWNER)  and OPRCTL(*NO)

Only the owner of the output queue, the creator of the spool file, and users with *SPLCTL special authority can view or manage the sensitive output. If you want several users in the payroll department to share the data, assign the individual users in the payroll department the same group profile (GRPPAYROLL) and have the PAYROLL output queue owned by the group profile (GRPPAYROLL).

To keep the PAYROLL output queue private, you must limit the users with *SPLCTL special authority.

Let’s go back to your request to find a way to allow a user with NO COMMAND LINE and NO SPECIAL AUTHORITY a way to view spool files on the OVERNIGHT output queue. To answer your request, it will take some simple CL programs that you can create. Before I get into the details let me give you an overview.

Create a CL command WRKOUTQSPC (Work Output Queue Special), which will allow a user adopted access to spool files. To allow viewing of spool files for other users, the program adopts *OWNER authority and is owned by a user profile that has *JOBCTL special authority. The AUT(WRKOUTQSPC) secures the CL command with the authorization list WRKOUTQSPC. However, option 4 of WRKOUTQ allows a user to delete spool files, and it is desirable to prevent that option. Before calling the program that issues the WRKOUTQ command, a first program, WRKOUTQ1, revokes access to the DLTSPLF command for the duration of time the user is running the program.

The second program, WRKOUTQ2, is changed to have the USEADPAUT(*NO) attribute. This drops all previous adopted access before the program runs. Note that the second program also adopts *OWNER access but the owner is different. (The source for program WRKOUTQ2 uses question marks to allow the user to prompt for the name of the OUTQ. If you wish to restrict the user to a specific OUTQ, remove the question marks.)

For an alternative that is more secure, see Ed Fischel’s suggestion below. I agree it is more secure, but also more complex, to implement, because it requires using CL exit programs.

Here are the implementation steps.

Step 1. Sign on as a user with *ALLOBJ and *SECADM special authorities.

Step 2. Create an authorization list that will be used to determine who has access to the WRKSPLFSPC function.

CRTAUTL AUTL(WRKOUTQSPC)   AUT(*EXCLUDE) +
        TEXT('Uses with access to WRKOUTQSPC) command.')

Step 3. Add users to the authorization list who will be allowed to run the WRKOUTQSPC command.

ADDAUTLE   AUTL(WRKOUTQSPC)  USER(user-profile)  AUT(*USE)

Step 4. CREATE a user profile that will be adopted by the programs and gives the user *JOBCTL special authority. This profile has no need to sign on and is used to adopt *JOBCTL special authority.

CRTUSRPRF	USRPRF(OWNOUTQSPC)  PASSWORD(*NONE) +
     INLPGM(*NONE)  INLMENU(*SIGNOFF) STATUS(*DISABLED) +
     SPCAUT (*JOBCTL) +
    TEXT('Owner of WRKOUTQSPC programs and commands')

Step 5. Use PDM to create the following members. Note that there is a slight security exposure in these example CL programs because they adopt *ALLOBJ and *JOBCTL special authorities. The commands and programs used by programs that adopt authority should be qualified (that is, the library name is hard-coded) to prevent Trojan horse exposures.

WRKOUTQ1 type CLP:

 PGM                                                                 
/*******************************************************************/
/*  PROGRAM: WRKOUTQ1 - REVOKE access to the DLTSPLF command to    */
/*  prevent use of option 4 from WRKOUTQ command.                  */
/*  This program needs to be owned by a user with *ALLOBJ . . .    */           
/* This program must be owned by a user with authority to modify   */
/* access to DLTSPLF command.                                      */
/* The program must adopt its owners authority  USRPRF(*OWNER)     */
/*******************************************************************/
              DCL        VAR(&USER) TYPE(*CHAR) LEN(10)   
              RTVJOBA    CURUSER(&USER)
              GRTOBJAUT  OBJ(DLTSPLF) OBJTYPE(*CMD) USER(&USER) +
                           AUT(*EXCLUDE) REPLACE(*YES)    
              CALL       PGM(WRKOUTQ2)               
              MONMSG     MSGID(CPF0000)
              RVKOBJAUT  OBJ(DLTSPLF) OBJTYPE(*CMD) USER(&USER) +
                           AUT(*ALL)    
 ENDPGM

WRKOUTQ2 type CLP:

/****************************************************************/
/*  PROGRAM WRKOUTQ2 - DROP adopted authority and adopt *JOBCTL */
/*                       authority before issuing WRKOUTQ       */
/*                                                              */
/* This program must be owned by a user with authority with     */
/* *JOBCTL special authority                                    */
/*  This program must be created with USEADPAUT(*NO) to prevent */
/*  command line access with adopted authority                  */
/*                                                              */
/*  The question marks in front of the command name and         */
/*  OUTQ parameter prompt the user to specify the OUTQ name     */
/****************************************************************/
PGM
             ?WRKOUTQ    ??OUTQ(OVERNIGHT)
ENDPGM

WRKOUTQSPC type CMD:

CMD        PROMPT('Work OUTQ with Adopted Access')

Step 6. Create the program WRKOUTQ2 using the command below, which will secure this program with the authorization list WRKOUTQSPC. The program will adopt the authorities of its owner.

CRTCLPGM        PGM(WRKOUTQ2)  USRPRF(*OWNER) +
                SRCFILE(source-file)  AUT(WRKOUTQSPC)

Step 7. Create the program WRKOUTQ1 using the command below, which will secure this program with the authorization list WRKOUTQSPC. The program will adopt the authorities of its owner.

CRTCLPGM        PGM(WRKOUTQ1)  USRPRF(*OWNER) +
                SRCFILE(source-file)  AUT(WRKOUTQSPC)

Step 8. Change the program to drop adopted authority using the following command:

CHGPGM    PGM(WRKOUTQ1) )  USRPRF(*OWNER) +
          USEADPAUT(*NO)

Step 9. Change the owner of the program to a user profile with *JOBCTL special authority, using the following command:

CHGOBJOWN   OBJ(WRKOUTQ1)   OBJTYPE(*PGM) +
                  NEWOWNER(OWNOUTQSPC)

Step 10. Create the WRKOUTQSPC command and specify that the command can be used by users with command line restrictions.

CRTCMD      CMD(WRKOUTQSPC)  PGM(WRKOUTQ1) +
            ALWLMTUSR(*YES)  SRCFILE(source-file) +
            AUT(WRKOUTQSPC)

Step 11. Move the programs and commands into a library that is on the user library list. If the current library was QGPL (*CRTDFT), library QGPL is likely on the library list. If so, this step is not required.

MOVOBJ           OBJ(WRKOUTQ1)  OBJTYPE(*PGM)  TOLIB(to-lib)
MOVOBJ           OBJ(WRKOUTQ2)  OBJTYPE(*PGM)  TOLIB(to-lib)
MOVOBJ         OBJ(WRKOUTQSPC) OBJTYPE(*CMD)  TOLIB(to-lib)

Alternative Solution Suggested by Ed Fischel

My colleague Ed Fischel, from IBM, points out a limitation with this approach and suggests an alternate one.

I do not like the idea of revoking access to a command from within a program. There are several problems with doing this. First, if the program does not complete, the user will not regain authority to the command. Because the WRKOUTQ command will be used, all it would take to cause this problem is someone using a system request to sign off, or they could enter the SIGNOFF command on the command line of WRKOUTQ.

Second, if the user does not have authority to the command in the first place, the normal cleanup operation of this program will cause that user to be authorized to a command he should not be authorized to. So to do this right you need to save the user’s current authority to the command and then restore it later. Of course, if you do that, the first problem I just discussed is a bigger one.

Third, any batch job for that user that is running at the same time will not have authority to the command.

Here is how I recommend preventing the user from using DLTSPLF. Of course, if you follow this suggestion, you do not need to create the WRKOUTQ1 program below and do not have the exposures of a program that adopts a profile with *ALLOBJ and *SECADM.

First, change the WRKOUTQ2 program to create a data area in QTEMP named NODLTSPLF. It should be created before the WRKOUTQ command and then deleted after it.

Next, create a validity-checking program for the DLTSPLF command that checks for the existence of the NODLTSPLF data area in QTEMP and does not allow the command to be used when it exists. As you know, the validity-checking program needs the same number of parameters as the CPP for the command. Several tools exist (aside from IBM’s) to determine these parameters, or you could use the Retrieve Command Definition (QCDRCMDD) API to determine that information.

–Wayne O. Evans

Security articles authored by Wayne O. Evans can be found on his Web site, www.woevans.com. E-mail: woevans@itjungle.com