Spool Control Authority Is a Security Risk

October 27, 2004 Hey, Wayne O

I gave many of our users spool control special authority (*SPLCTL) so they can view their reports and start print writers. Our auditor says spool control authority is a security exposure and should be removed from user profiles, including the user profiles of system operators. I do not want to disrupt our users, so I have not removed *SPLCTL. Can I safely remove it from user profiles?

–John

Thanks for your note. It gives me an opportunity to discuss a security problem that I see in about nine out of 10 installations. I want to be very clear on this topic: users and system operators do not need *SPLCTL special authority. There are alternatives that are much better, but first I want to tell you why OS/400 includes the *SPLCTL special authority.

As you realize, spool files are not objects to which you can grant and revoke access; therefore, the *ALLOBJ special authority does not give access to spool files. On the S/38, the predecessor of the AS/400, there was no spool control authority, and sometimes the security officer (QSECOFR) could not access spool files. There were many cards and letters requesting that the security officer be allowed to view all spool files. So when OS/400 was introduced, the *SPLCTL authority was added to provide a method of unrestricted access to spool files. I consider *SPLCTL to be to spool files what *ALLOBJ authority is to objects. The conscious security officer would never give *ALLOBJ to users, and in the same spirit *SPLCTL special authority should not be given to users.

Let me take a moment to explain how OS/400 determines access to spool files. The rules for printed output are as follows.

First, users can view the spool files they create with no special access. If you want to limit users to viewing only their spool files, do not give them any special authority.

Second, users with job control special authority (*JOBCTL) can view the spool files of other users, except those on secured output queues. I will explain the use of secure output queues later. If you want a user, such as a system operator, to be able to view and manage the spool files for others, give the user *JOBCTL special authority. (Caution: when a user has *JOBCTL special authority, he can also hold, cancel, and change the priority of other users’ jobs.) A user must have *JOBCTL authority to start a print writer. If you have users who need to view only their spool files but also need to start a print writer, create a program that runs with the adopted authority of a user that has *JOBCTL. This program can be a menu option for users.

Third, users with *SPLCTL authority can view any output queue, since *SPLCTL is like *ALLOBJ for spool files. I recommend that no user profile except QSECOFR should have *SPLCTL special authority. Restricting *SPLCTL special authority allows you to define sensitive output queues, such as for payroll, where you want to limit the users that can view the information.

SENSITIVE OUTPUT QUEUES

As I explained earlier, spool files are not objects to which you can grant or revoke access and therefore control who can view the output. If you do not give users *SPLCTL special authority, you can define an output queue (*OUTQ) that can be viewed only by selected users.

To create a sensitive output queue, use the following attributes of the Create Output Queue (CRTOUTQ) command.

DSPDTA(*NO)	OPRCTL(*NO)	AUTCHK(*OWNER)

Users who have *JOBCTL authority but not *SPLCTL authority won’t be able to access the spool files on output queues that are created with this combination of attributes. Only the owner of the output queue can view all of the spool files on the output queue. If you have several people, such as all the people in the payroll department, then have the output queue owned by a user profile like GRPPAYROLL and give the members of the payroll department that group profile.

I hope you see that an advantage in not giving users *SPLCTL special authority is that you can create sensitive output queues. If users such as operators and help desk users need to view other user output (but not sensitive output), specify *JOBCTL special authority. This allows them to do their job but also protects sensitive information.

–Wayne O. Evans

Security articles authored by Wayne O. Evans can be found on his Web site, www.woevans.com. Click here to contact Wayne O. Evans by e-mail.