Correctly Securing Powerful and Sensitive Commands

Several IBM supplied Control Language commands have restrictions on their use. Commands like CRTUSRPRF(Create User Profile) and CHGUSRPRF(Change User Profile) require that the user have, at the minimum, *SECADM special authority. Other commands like PWRDWNSYS(Power Down System) and ENDSBS(End Subsystem) can only be used by users with *JOBCTL special authority.

Most commands, however, are available for use by any user on the system. Commands can be run directly from the command line, executed from within a program or batch job stream, or can be run through network interfaces like RMTCMD(Remote Command), FTP and ODBC/JDBC(using the QCMDEXC program).

Each command has an attribute that specifies whether limited capabilities users enter the command at the command line. A user is identified as 'limited' if their user profile specifies LMTCPB(*YES). There are only a handful of commands that allow 'limited' users to run the command at a command line. These are commands like DSPJOB(Display Job) and DSPMSG(Display Messages). We consider 'limited capability' users as being restricted from using the command line. In reality, they CAN enter commands at a command line, as long as the particular command allows for it.

Since there are so many different methods to run commands, and so many different types of user capabilities and special authorities, it is important to tightly control some of the more powerful and sensitive commands.

On most systems, a majority of the users have *JOBCTL special authority. I have heard countless reasons for this configuration debacle, which I will not rehash here. The point here is that the powerful commands available to these users must be controlled.

The ability to use commands like PWRDWNSYS, ENDSBS and ENDSYS should not be available to every user with *JOBCTL, but should be restricted to a very small group of users.

I recommend that we control access to powerful and sensitive commands using authorization lists. In this context, the authorization list is a list of users and the commands they can use.

For example, we create an authorization list named SYSADMIN. This list will identify system administrators, and the powerful commands they can use. Here is the command to create the authorization list.

CRTAUTL AUTL(SYSADMIN) AUT(*EXCLUDE)

Here, we use the setting AUT(*EXCLUDE) to specify that *PUBLIC does not have any rights to the commands that will be secured by the list. Note: If the list is not owned by QSECOFR, we assign that ownership, and revoke authority from the previous owner, using the command:

CHGOBJOWN OBJ(SYSADMIN) OBJTYPE(*AUTL) NEWOWN(QSECOFR)

Once we have created the list, we add the individual users to the list. Preferably our group profiles are implemented well enough so that we can just add group profiles to the list. If our groups are not that well planned out, now may be a good time to remedy that situation.

Each user/group that we add to the list will have the authority to run the commands secured by the list. Here we add all the users in the OPS_GROUP and the ADM_GROUP to the list.

ADDAUTLE AUTL(SYSADMIN) USER(OPS_GROUP) AUT(*USE)

ADDAUTLE AUTL(SYSADMIN) USER(ADM_GROUP) AUT(*USE)

Pulling the Trigger

Once you have determined which users need to be authorized to use a command, and have added them to the authorization list, you are now ready to actually enforce the restriction. To do this, we attach the powerful commands to the list. As soon as these commands are added to the list, the list will be controlling access to these three powerful commands.

GRTOBJAUT OBJ(QSYS/PWRDWNSYS) OBJTYPE(*CMD) AUTL(SYSADMIN)
GRTOBJAUT OBJ(QSYS/PWRDWNSYS) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*AUTL)

GRTOBJAUT OBJ(QSYS/ENDSBS) OBJTYPE(*CMD) AUTL(SYSADMIN)
GRTOBJAUT OBJ(QSYS/ENDSBS) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*AUTL)

GRTOBJAUT OBJ(QSYS/ENDSYS) OBJTYPE(*CMD) AUTL(SYSADMIN)
GRTOBJAUT OBJ(QSYS/ENDSYS) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*AUTL)

The first GRTOBJAUT command in each group secures the command for use by those with at least *USE authority to the list. The second command, changes the *PUBLIC authority from *USE, *CHANGE or *EXCLUDE to the value *AUTL. This means that the *PUBLIC authority will be determined by the *PUBLIC authority to the authorization list, not from the *PUBLIC authority listed on the command object.

The Caveats to Remember

Remember, users that have *ALLOBJ special authority specified in their user profile, will be able to execute any command to which they have the required special authorities, (e.g. CRTUSRPRF(requires *SECADM), PWRDWNSYS(requires *JOBCTL) regardless of the settings in the authorization lists and the authority set on commands.

Also, keep in mind that some often used CL commands are Proxy Commands that actually point to commands in other libraries. For example, the STRPDM(Start PDM) command in the QSYS library is actually a Proxy Command that points to the real STRPDM command found in library QPDA. You will want to secure the real command, not the Proxy Command. To determine if a command is a Proxy Command, use the command DSPCMD(Display Command). If it is a Proxy Command, the proxy chain will be listed, and you will be able to identify the real command in the actual library in which the real command resides.

Also keep in mind that if you still have the System/38 environment installed, several commands will have duplicate or similar commands in library QSYS38. (e,g, PWRDWNSYS) You will need to secure these commands also, or, if possible, remove the System/38 environment to alleviate this particular problem.

What about a Re-Do?

In performing these steps, we could have used commands like WRKAUTL, EDTAUTL, and EDTOBJAUT. But it is very important that you actually know, and retain the CL commands that were used to apply the authorization list to the powerful commands.

When you perform an upgrade to the operating system, the IBM supplied CL commands in QSYS are replaced with the new version. Since the authorization list name securing the command is stored in the command object, the authority changes we have made to the commands are lost, and must be re-applied.

It is very important that you have a special program, or series of programs that will be used after an OS upgrade to apply your OS modifications back to the new version of the OS.

In the case of these modification made to the IBM commands, you will need to be able to re-run all of the GRTOBJAUT commands listed above. I suggest that you create a CL program that includes all of the commands needed to re-apply all changes made to IBM supplied objects. Place the source code and program objects in a secure library that is routinely saved. After you install a new release, just run the program to re-apply the authorization changes.

What's Next?

Well, now you may want to add more commands to the SYSADMIN authorization list, and create a few more lists for your sensitive commands. Here are some examples.

Authorization List     Commands Secured

SYSADMIN               SAVLIB RSTLIB    SAVOBJ    RSTOBJ SAVSYS
                       CFGTCP STRTCPSVR ENDTCPSVR

PGMR                   CRTBNDRPG CRTRPGPGM CRTRPGMOD 
                       CRTDSPF   CRTPRTF   CRTCLPGM   CRTPGM

SECOFR                 CRTLIB   DLTLIB

Create the list, assign the appropriate users to the list with *USE authority, and then attach the list to the sensitive commands using the GRTOBJAUT commands.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and President and Security Specialist for the IT Security and Compliance Group, LLC.

Dan performs IBM i security assessments and provides customized security services. He also provides training in all aspects of IBM i security and other technical areas through the training company,The 400 School, Inc.