By Rich Loeber
Normally, you would not think of system performance in terms of a security issue. But, if someone with the right know-how is abusing privileges on your system, then it becomes a security issue. This tip will help you to identify some performance issues that fall into this category.
A performance issue that has security implications can happen when someone with the right special authorities on their user profile abuses those and consumes excessive system resource in their own interest. This can happen, for example, when programmers boost the execution priority for their jobs at the expense of interactive processing. It can also happen when someone runs a batch job interactively, thereby bringing other interactive users to a crawl. When this occurs, it is clearly a security issue as the user or users in question are abusing their assigned privileges.
Controlling the execution priority of a job is a function of the Job Priority. This is set by the Job Description that is used for the job. It can also be changed on the fly by someone with *JOBCTL special authority associated with their user profile. If you see this happening, you might want to just remove *JOBCTL from their user profile. Restricting access to the CHGJOB command can also help. The CHGJOB command is shipped from IBM with public access set to *USE, so any user profile can use the command. Restricting access could affect applications running on your system, so you should consider this change carefully.
To restrict access to the CHGJOB command, run the following command on your system:
GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(*PUBLIC)
This will change the command so that only authorized user profiles can use it. To add a user profile to those allowed access to this command, use the following command:
GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(MYUSRPRF)
This will allow the profile MYUSRPRF to use this command while excluding all others. Of course, any user profile with All Object Authority (*ALLOBJ) will still have access, so that wrinkle also has to be allowed for.
Limiting access to command objects on your system is a good way to control who can do what. Another command that you should consider for similar treatment is the Change Shared Storage Pool (CHGSHRPOOL) command. This command can be used to control performance characteristics for jobs running on your system through the allocation of memory resources and processing time slices.
If you still have problems with performance issues preventing production from getting done efficiently, there may be a problem of users running batch jobs interactively. If your applications are running from IBM i OS commands, you can change the commands so that they will not function when called in an interactive environment. You can do this using the Change Command (CHGCMD) command, setting the ALLOW parameter to remove the *INTERACT, *IPGM and *REXX options.
If you make changes to any IBM i OS commands, you should keep a list of the commands changed and the specific changes made. Installing PTFs or OS upgrades from IBM could change them back, so you should keep your list with your IBM i OS documentation to serve as a reminder to check the commands following a PTF install or OS upgrade.
If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot. All email messages will be answered.