Output Queue Security

Question: I have users who place spool files into an out queue via a program. Once the spool files are in the out queue, I do not want users to have the ability to delete or move the spool file from that out queue. Is there any way to accomplish this using security features on the out queue or otherwise?

Answer: That depends on whether the user is the owner of the spool file in question. Let me state unequivocally that users will always have complete authority over any spool files that they own. If users are able to view the spool file through the Work with Output Queue (WRKOUTQ) command or the Operations Navigator interface, they will always be able to modify or delete the spool files they own.

I have done extensive research on this topic. Specifically, I was trying to prevent a user from deleting the audit trail that DFU or other database file editors generate whenever production data is changed by a user. I came to the conclusion that users will always have authority to delete a spool file that they own. You just can’t stop that authority. I was able to significantly hinder deletion to the point that I was reasonably sure it wasn’t happening, but I could not completely guarantee that I’d stopped it. If a user does not own the spool file, there are effective means of securing the spool file from manipulation. If the user does own the spool file in question, he will always have authority to delete it. If you try to hide a spool file from the user, he may find a way around your obfuscations anyway.

The essence of the solution is to change the ownership of the spool file to someone other than the user in question. One simple way to accomplish this is to use the profile- swapping APIs to make the job run under another user’s authority before the action that creates the spool file is performed. This way the profile that owns the spool file is different from that of the original user.

Simply put, if user Tim is about to execute the DFU command and you want to be sure that Tim does not delete his audit trail report when he alters the data, you could build a new front-end process to DFU’s Update Data (UPDDTA) command that would swap Tim to run under the authority of a new profile called ZSECOFR. While the UPDDTA command is executing, any spool files created by that job would be owned by user profile ZSECOFR, not by Tim. When the UPDDTA command is completed, the job would revert to running under the authority of Tim.

Of course, you would also want to take steps to ensure that profile ZSECOFR could get the appropriate authority to handle the change being requested. This can be accomplished in a number of ways. The way I would choose to do this is have the program that Tim can call adopt *ALLOBJ authority, but before the program would actually permit access to any given file, the program would authenticate Tim’s authority to that file via the Check Object (CHKOBJ) command. Figure 1 shows an example of how this might be accomplished. Note that the code in Figure 1 uses the Swap User Profile (SWPUSRPRF) command, which was featured in the January 2001 “Security Patrol” column.

Keeping a User from *PUBLIC Authority

Question: I need to create a user profile that doesn’t expire and has access only to a library called WEBLIB. On our system, we have a daily process that involves Microsoft SQL Server 7 connecting to the AS/400 and transferring data up to the AS/400. The live data remains on the AS/400. I want to create a user called WEBLIB and lock that user down so that the user can only use this ODBC connection to see the WEBLIB library.

Right now, user WEBLIB can FTP any file from the AS/400 to its machine and open the file with Notepad. (I haven’t tried deleting live data yet—yikes!) I need help locking down user WEBLIB. What must I do?

Answer: The problem you are facing is a common one for AS/400 shops. Most objects allow *PUBLIC to have direct read or change. It is somewhat difficult to secure any user profile from everything on the system, because every user is a member of *PUBLIC and, therefore, has access to everything that *PUBLIC has access to. Years ago, some colleagues and I asked IBM Rochester for a “No *PUBLIC” bit in the user profile that would allow us to create a user profile that was not allowed to receive its authority from *PUBLIC. I understand that Rochester took a hard look at that request, but the request never made it into any OS/400 release plan.

In the meantime, when I have to secure against *PUBLIC authority, I use one of two methods.

Users with One or More Group Profiles

If all of your users belong to one or more group profiles. Choose this first method:

1. Create a network access user profile called WEBLIB.

2. Change the authority on every library so that the group profiles have the same authority to the library as *PUBLIC. (If *PUBLIC has *USE, give the groups *USE. If *PUBLIC has *CHANGE, give the groups *CHANGE.)

3. Revoke *PUBLIC’s authority to every user library. As a general rule, I would not recommend that a novice security officer modify the IBM libraries. The modification can be done, and there are a lot of smart folks who can work through the process with you. It would be unwise to just jump in and start ripping authorities off of the IBM objects unless you understand what those objects do.

4. Grant WEBLIB-specific authority (*USE or *CHANGE) to the specific objects that you want the users to have access to.

5. Use exit programs to regulate access to the data. My exit programs allow valid users to sign on using FTP or ODBC, but as soon as they do sign on, I perform a profile swap and cause the users to run under the authority of WEBLIB. This way, no matter which data access methods users try to use, the WEBLIB profile will only get access to a restricted set of data (the data authorized to WEBLIB in Step 4).

6. Change the System Value Create Default Public Authority (QCRTAUT) to *EXCLUDE so that all new objects are created with *PUBLIC=*EXCLUDE.

7. Change the Create Authority (CRTAUT) parameter on library QSYS back to *CHANGE so that you don’t have problems with virtual devices that are created and deleted on the fly. (Actually, you can get around this by using authority lists. But, for the sake of explanation, I’m trying to keep it short.)

A benefit of this design over letting multiple users sign on with a generic WEBLIB profile is that you can tell who the original user is yet still restrict that user to only the libraries and objects that WEBLIB has authority to. There also is no need to change any of the user’s regular green-screen authorities; those authorities will work as they have always worked.

Users without Group Profiles

If you don’t use group profiles, then the steps are a little different and more long-term diligence is called for. Without group profiles, I would recommend you do the following:

1. Complete Step 1 from above.

2. Grant WEBLIB *EXCLUDE authority to every library on the system that you want to keep users out of. (No need to exclude users from each object, because if they don’t have *USE authority to a library, they will never be able to see any of the objects in that library.) As a general rule, you don’t have to do any of these steps with IBM libraries (libraries that start with a Q), because IBM has done a good job of securing those libraries, at least in post-V3R7 versions of OS/400.

3. Skip Step 3 from above.

4. Complete Step 4 from above.

5. Complete Step 5 from above.

6. Skip Step 6 from above.

7. In the No Group Profiles option, you’re going to have to police new libraries that are created and remember to *EXCLUDE WEBLIB from them. This will be a manual (and, therefore, error-prone) process. In the meantime, you can plot how to create working group profile for all of your users.

REFERENCES AND RELATED MATERIALS

• OS/400 Security—Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)
• “Security Patrol: Watching QSECOFR,” MC, January 2001

PGM PARM(&LIBNAME &FILENAME)

DCL VAR(&FILENAME) TYPE(*CHAR) LEN(10)

DCL VAR(&LIBNAME) TYPE(*CHAR) LEN(10)
/****************************************************************/

/* GLOBAL MESSAGE MONITOR DECLARATIONS */
/****************************************************************/

DCL VAR(&LOOPCHECK) TYPE(*LGL) VALUE('0')

DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(132)

DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)

DCL VAR(&MSGF) TYPE(*CHAR) LEN(10)

DCL VAR(&MSGFLIB) TYPE(*CHAR) LEN(10)

/****************************************************************/

/* GLOBAL MESSAGE MONITOR */
/****************************************************************/

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ESCAPE))

CheckAut:

CHKOBJ OBJ(&LIBNAME/&FILENAME) OBJTYPE(*FILE) +

AUT(*CHANGE)

/* Swap authority to ZSECOFR */

CALL SWPUSRPRF

/* Update File Name */

UPDDTA FILE(&LIBNAME/&FILENAME)

/* Swap authority back to original user */

CALL SWPUSRPRF

RETURN

Escape:

/****************************************************************/

/* ERROR TRAPPING ROUTINE FOR UNMONITORED MESSAGES */
/*--------------------------------------------------------------*/

/****************************************************************/

IF COND(&LOOPCHECK = '1') THEN(DO)

RETURN

ENDDO

CHGVAR &LoopCheck '1'

Diag: RCVMSG MSGTYPE(*DIAG) MSGDTA(&MSGDTA) MSGID(&MSGID) +

MSGF(&MSGF) MSGFLIB(&MSGFLIB)

IF COND(&MSGID *NE ' ') THEN(DO)

SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +

MSGDTA(&MSGDTA) TOPGMQ(*PRV) MSGTYPE(*DIAG)

GOTO CMDLBL(DIAG)

ENDDO

RCVMSG MSGTYPE(*EXCP) MSGDTA(&MSGDTA) MSGID(&MSGID) +

MSGF(&MSGF) MSGFLIB(&MSGFLIB)

SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +

MSGDTA(&MSGDTA) TOPGMQ(*PRV) MSGTYPE(*ESCAPE)

Exit:
ENDPGM

Figure 1: Use this code to secure spool files.