Command Authority and LOGCMD

Hey, Wayne O.:

Is there a security exposure if a user has command line access plus special authorities, such as job control (*JOBCTL) and spool control (*SPLCTL), with the *PUBLIC authority is set to *USE for commands such as CRTUSRPRF, DLTUSRPRF, CHGUSRPRF, GRTUSRAUT, DLTLIB, CLRLIB, CRTLIB, CHGSYSVAL, CHGOBJOWN, GRTOBJAUT, CHGDSTPWD? Do you need to set the *PUBLIC authority to *EXCLUDE for these commands? What harm can the users with command line do? Sometimes, programmers (the vendors) ask for *ALLOBJ authority. They say that if they don't have *ALLOBJ authority, they can't provide technical support or help us to trouble shoot. Is this true?

--John

You asked several questions. Let me handle them one at a time.

AUTHORITY TO COMMANDS

You can leave the *PUBLIC authority to commands at *USE for the commands you mentioned in your note because there are other controls. (The only exception would be the CRTLIB command, if you want to prevent users from creating libraries.) The additional controls on commands are as follows:

The commands for user profiles (DLTUSRPRF, CHGUSRPRF CRTUSRPRF) require that the user have *SECADM (security administration) special authority.

The CLRLIB and DLTLIB commands require that the user be authorized to the library so the user will be prevented from accessing most production libraries.

The CHGDSTPWD command must be issued by the QSECOFR user profile. You can change the public authority on the command to *EXCLUDE, but it's not necessary.

The CHGSYSVAL is shipped by IBM with *PUBLIC authority of *EXCLUDE. In addition, the security-related system values require that users have *ALLOBJ and *SECADM special authority.

In V5R2, IBM added a feature that allows you to restrict users from changing the security-related system values. System service tools (SST) and dedicated service tools (DST) provide an option to lock these system values. By locking the system values, you can prevent even a user with *SECADM and *ALLOBJ authority from changing these system values with the CHGSYSVAL command (I described this feature in "V5R2 Security System Value Lock").

The CRTLIB command is the only command that you may want to restrict if you want to prevent users from creating libraries.

The CHGOBJOWN command requires that you be the owner or have object management authority to the object.

Appendix C and Appendix D of the IBM security reference manual (SC41-5302, in PDF format) provides additional information on the security of commands and the authority required to issue specific commands.

PROGRAMMER'S REQUEST FOR *ALLOBJ SPECIAL AUTHORITY

A programmer's request for *ALLOBJ special authority is probably the most common security question I am asked. The answer is no. Programmers should not have *ALLOBJ special authority on a system with production data. I know that programmers will tell you they can't do their job unless they have *ALLOBJ special authority, but in a well-run installation there are some alternatives.

First, *ALLOBJ special authority is very powerful. The *ALLOBJ special authority allows programmers to do anything, so I teach that *ALLOBJ is *GOD. I know programmers think that they are God, but actually most programmers are just humans.

There are two alternatives. Give programmers a test environment separate from development where they can test and debug problems.

This can be a separate machine or copies of the production data libraries in test libraries. The programmers are authorized only to the test data, not production data. This option may require significant effort and cost to set up, but is the most secure.

LOGCMD is a tool that I developed that gives programmers temporary access to *ALLOBJ. You can control what users are allowed to run LOGCMD. When users run LOGCMD, they are given a command entry screen with adopted *ALLOBJ special authority, but every command they enter while running with *ALLOBJ authority is recorded in the audit journal.

I have installed LOGCMD for many of my clients, and programmers are allowed to do their work, but there is an audit log of their activity. After programmers get used to LOGCMD, they appreciate that they do not have *ALLOBJ authority and can accidentally modify or delete production objects.

You can get a detailed write up and copies of the LOGCMD code from my Web site, www.woevans.com. There is no charge, but I do request that you make a donation to charity if you find the tool useful. I recommend LOGCMD to my clients because it allows programmers to do their job but has a method to audit their activities.

*SPLCTL AUTHORITY

You did not ask about *SPLCTL authority, but your note implies that you have given this authority to many users. If you have sensitive data (payroll, human resources, or client records), you need to prevent users from viewing the printed output. You did not indicate your company, but from the e-mail address it appears that it is a financial intuition, and very likely has sensitive client data.

Users do not need special authority to view their own spool files. If you give users *JOBCTL authority, they can view the spool files created by other users unless they are in a restricted output queue. (See "Secure Spool File Management" for more details.)

--Wayne O. Evans

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