Outq vor Neugierige schützen

[Bau]

Hallo i5 Spezialisten,

Ich habe eine Outq XXXX die folgende Objektberechtigung hat:
*PUBLIC = *EXCLUDE und *GROUP(ZZZ) = *ALL
Das heisst ich möchte diese Outq nur der Gruppe ZZZ zur Verfügung stellen und den anderen Neugierigen den Zugriff verweigern. Das System i5 erstellt aber automatisch bei allen Outq zusätzlich die Berechtigung QSPL = *CHANGE. Diese kann auch nicht entzogen werden.

Im Userprofile haben alle Benutzer die Sonderberechtigung *SPLCTL. Obwohl ich die Outq als *PUBLIC = *EXCLUDE definiert habe, können alle Benutzer auf diese Outq zugreifen.
Ich kann das Sonderrecht *SPLCTL beim Benutzer entfernen und dann haben Sie keinen Zugriff mehr.

Frage:
Gibt es noch einen andern Weg, wo ich das Sonderrecht *SPLCTL beim Benutzer stehen lassen kann ?

[Pikachu]

Benützer mit dem Sonderrecht *SPLCTL dürfen alle Spooldateien verwalten. Und das Spoolsystem (Benützer QSPL) benötigt natürlich auch bestimmte Berechtigungen an den Ausgabewarteschlangen, um die Spools darin zu verwalten.

[TARASIK]

Hallo,
hier ein ganz interessanter Artikel, der etwas Licht in das Dunkel bringt:
Security Patrol: Securing Your Output
by Carol Woodbury
Learn how to secure confidential output from prying eyes.

Published September 2003
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:
CRTOUTQ OUTQ(HR_LIB/HR_OUTQ) DSPDTA(*YES) OPRCTL(*NO) +
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.
CHGOBJOWN OBJ(HR_LIB/HR_OUTQ) OBJTYP(*OUTQ) NEWOWN(HR_GROUP)
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:
CRTOUTQ OUTQ(ACCT_LIB/ACCT_OUTQ) DSPDTA(*OWNER) OPRCTL(*YES) + AUTCHK(*OWNER) AUT(*EXCLUDE)

Grant authority to Accounting so they can use the OUTQ:
GRTOBJAUT OBJ(ACCT_LIB/ACCT_OUTQ) OBJTYP(*OUTQ) USER(ACCT_GRP) + AUT(*CHANGE)
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@mcpressonline.com.

[Bau]

Ich habe nun den Benutzern die Sonderberechtigung *SPLCTL entzogen. Dadurch können die Benutzer aber die Outq/Dev nicht mehr steuern (Start, Stopp, Meldung etc.).

Deshalb musste ich die Objektberechtigung für die Outq
auf die Sie Zugriff haben sollen wie folgt ändern:
PUBLIC = *CHANGE

Auch musste ich die Paramter der Outq wie folgt setzen:
CHGOUTQ OUTQ(YYYY) DSPDTA(*NO) OPRCTL(*NO) AUTCHK(*DTAAUT)