To many shops, how to secure spooled files (output)--including output containing confidential data--is a mystery that desperately needs to be solved. The solution lies somewhere in the appropriate assignment of special authorities, output queue (OUTQ) attributes, and the OUTQ's object authority.
To other shops, controlling which users can start a particular writer is another mystery that needs to be solved. This column attempts to take the mystery out of securing spooled files and controlling writers so you can be assured that confidential output remains confidential. I'm going to first describe the elements of securing spooled files--special authorities and OUTQ attributes--and then see how they work together by describing a few scenarios.
Special Authorities
Two special authorities--*SPLCTL (spool control) and *JOBCTL (job control)--are major factors in determining who can see and manage spooled files as well as who can start printer writers. *SPLCTL is the equivalent of *ALLOBJ special authority for spool files. Just as you can't prevent a user with *ALLOBJ authority from accessing any object on the system, you cannot prevent a user with *SPLCTL authority from accessing a spooled file. What about securing the OUTQ in which the spooled files are contained, you ask? A user with *SPLCTL only needs *EXECUTE authority to the library containing the OUTQ. No authority to the OUTQ itself is required when the user has *SPLCTL. Besides, the user can get to the spooled files through all of the spooled file commands even if the user has been excluded from the OUTQ. Rather than spend the energy trying to limit what a user with *SPLCTL can see, your time will be better spent removing the user's *SPLCTL special authority and determining the appropriate OUTQ settings that will allow them to do their jobs.
When an OUTQ is created with the default settings, *JOBCTL special authority enables the management and display of all spooled files; the management of output queues; and the starting, stopping, and holding of writers. If your OUTQs were created with and left at the default settings, all those user profiles that were created back when the *PGMR user class included *JOBCTL as well as all those developers who have been made members of the IBM profile QPGMR can display and control the printed output on your system. For some of you, that should be a very scary thought.
Security-Relevant Output Queue Attributes
There are three security-relevant OUTQ attributes: Display Data (DSPDTA), Authority Check (AUTCHK), and Operator Control (OPRCTL). Each has a role in determining which users can see or manage spooled files that belong to another user. The settings of these attributes apply to all spooled files in a particular OUTQ. You cannot secure an individual spooled file differently from the other spooled files in the OUTQ. Regardless of the settings of the DSPDTA, AUTCHK, or OPRCTL attributes, you can always display and manage spooled files that you own.
Display Data
Display Data's purpose is to protect the contents of spooled files. In other words, it restricts who can view a spooled file owned by another user. The settings of DSPDTA determine whether a user can run the following commands:
- Display Spooled File (DSPSPLF)
- Copy Spooled File (CPYSPLF)
- Send Spooled File (SNDNETSPLF)
- Change Spooled File Attributes (CHGSPLFA) to move the spooled file between OUTQs
DSPDTA has three values: *NO (the default), *YES, and *OWNER.
If DSPDTA is *NO (the default), one of the following must be true to be able to display, send, or copy a spooled file owned by someone else:
- The OPRCTL parameter is *YES, and the user has *JOBCTL special authority.
- The AUTCHK parameter is *DTAAUT, and the user has *CHANGE authority to the OUTQ.
- The AUTCHK parameter is *OWNER, and the user trying to perform the operation owns the OUTQ.
If DSPDTA is *YES, any user with *READ authority to the output queue can display, copy, or send a spooled file that is owned by someone else. (I should mention here that if you own a spooled file, you can always manage it, regardless of the setting of the DSPDTA, AUTCHK, or OPRCTL attributes.) Because the default *PUBLIC authority setting for OUTQs is *CHANGE, setting DSPDTA to *YES without changing the *PUBLIC authority setting to *EXCLUDE allows anyone on the system to see and manage all spooled files contained in the OUTQ. If you want a publicly available OUTQ, then *YES is the setting you want.
If DSPDTA is *OWNER, the following rules apply:
- Only the owner of the spooled file (or a user with *SPLCTL special authority) can display, copy, send, or move the file.
- If OPRCTL is *YES and the user has *JOBCTL, the user will be able to hold, change, delete, and release the spooled files on the OUTQ. However, the user will not be able to display, copy, send, or move the spooled files. The idea is that an operator (a user who would normally be given *JOBCTL) can manage the entries on an OUTQ but not see the contents.
Authority Check
Authority Check's purpose is to control who can manage spooled files owned by others, who can manage the output queues containing spooled files owned by others, and who can start and stop the writers associated with the OUTQs. OS/400 checks the AUTCHK parameter to determine which users are allowed to run the following commands:
- Change Spooled File Attributes (CHGSPLFA)
- Delete Spooled File (DLTSPLF)
- Hold Spooled File (HLDSPLF)
- Release Spooled File (RLSSPLF)
- Change Output Queue (CHGOUTQ)
- Clear Output Queue (CLROUTQ)
- Hold Output Queue (HLDOUTQ)
- Release Output Queue (RLSOUTQ
AUTCHK has two parameters: *OWNER (the default) and *DTAAUT.
If AUTCHK is *OWNER (the default), only the owner of the OUTQ can change or delete (in other words, manage) the spooled files of other users contained in the OUTQ.
If AUTCHK is *DTAAUT, the user must have *READ, *ADD, and *DLT authority (or *CHANGE authority) to the OUTQ containing the spooled files.
Operator Control
Operator Control's purpose is to control whether users with *JOBCTL are allowed to manage the OUTQ and associated writers and work with (display and manage) spooled files owned by others.
OPRCTL has two values: *YES (the default) and *NO.
If OPRCTL is *YES (the default), users with *JOBCTL special authority can view spooled files, manage (hold, release, and delete) spooled files, manage (change, clear, and hold) the OUTQ containing other users' spooled files, and start the writers associated with the OUTQ.
If OPRCTL is *NO, the user is not explicitly prevented from displaying or managing spooled files or managing OUTQs and writers, but the user's the ability to do so must come from the user meeting the criteria of one of the other attributes.
Scenarios
Scenario 1: The HR Department prints reports with salary information. Only the users in the HR Department should be able to see these reports and manage how and when they're printed. Create the OUTQ with the following attributes:
AUTCHK(*OWNER) AUT(*EXCLUDE)
Have the HR group own the OUTQ so they can manage the spooled files as well as start the writer to print the documents.
Scenario 2: The Accounting Department prints confidential reports, but the operators need to manage the spooled files and route them to the writer loaded with the appropriate form. Create the OUTQ with the following attributes:
Grant authority to Accounting so they can use the OUTQ:
How Do I Determine if My Output Is "Viewable" by the Public, and Where Do I Go for Help?
IBM has provided several tools to help you determine if access to spooled files is an issue. The Print Queue Authority (PRTQAUT) command provides a list of all OUTQs and job queues along with the values of the security-relevant attributes and *PUBLIC authority. Use this report along with the special authority portion of the report produced by the Print User Profile (PRTUSRPRF) command to determine which users can access what spooled files. Your first priority should be to eliminate *SPLCTL from all but security officer profiles, and it is even questionable whether security officers need this special authority.
Next, identify the OUTQs that you know contain sensitive output. Then, identify the users who should be allowed to see that output as well as the operations they should be able to perform against the output. For example, perhaps they should only be able to "manage" the output--that is, hold, change, delete, or release the output but not see it. A chart that I've found extremely helpful for this step is found in chapter 6 of the iSeries Security Reference manual (available at the iSeries Information Center), Chapter 6 of my book Implementing AS/400 Security, and chapter 8 in my soon-to-be released book, Experts' Guide to OS/400 Security. This chart lists the commands that can be performed against spooled files, OUTQs and writers along with the OUTQ security-relevant attributes and the operations users will be able to perform given the setting of each attribute.
The other charts that are very useful are found in the iSeries Security Reference manual, Appendix D. Appendix D lists all OS/400 commands and the authorities required to run them. Look for the Spooled File, Output Queue, and Writer command sections for the specific authorities required to run these commands.
If I Do Nothing, What Is the Risk to My Output?
If you leave the OUTQ attributes set to their default settings--DSPDTA(*NO), AUTCHK(*OWNER), and OPRCTL(*YES)--users with *JOBCTL special authority can see and manage all spooled files in that OUTQ. Users who do not have *JOBCTL will only be able to see and manage their own spooled files.
Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online