|Partner TechTip: Do Your Profiles Have (User) Class?|
|Tips & Techniques - Security|
|Written by Robin Tatam|
|Friday, 16 July 2010 01:00|
Be sure you understand the impact of a profile's user class on user capabilities.
One of the security issues most frequently cited by auditors is the existence of (overly) powerful users on a system. Unfortunately, there are no hard and fast guidelines of what defines a powerful user on the IBM i platform. Too often, administrators and auditors focus almost exclusively on a profile's User Class (USRCLS) parameter.
In my opinion, a powerful user is anyone who can operate outside the confines of an application. This includes users with command-line access in conjunction with special authorities or users with public or private authority to libraries and objects. Command-line access is possible through legacy green-screen command functions, as well as through network interfaces such as FTP and REXEC. Some of these network interfaces even allow user profiles with "limited capabilities" to run commands.
What Exactly Does the User Class Control?
According to the IBM i Security Reference, the primary purpose of the user class is to control the options that display on IBM i menus. For example, Main Menu option 5 (Programming) isn't visible to *USER-type users. However, when asked for a list of "security officers," many administrators limit the list to profiles running with a USRCLS of *SECOFR without looking at other authorities a profile may have. One reason USRCLS is often confused with the capabilities of a user is that the class names suggest roles with specific responsibilities: security officer, security administrator, programmer, and system operator.
The reality is that the user class parameter does play a significant role when you create or change a profile and set the SPCAUT (special authority) parameter to *USRCLS. This tells the operating system to look to the user class to determine which special authorities to grant, based on a predetermined IBM template. Once the special authorities are assigned, *USRCLS is replaced with these authorities, and the user class is no longer used.
The following table shows the special authorities that are granted for each user class at the system security level defined by the QSECURITY system value and using a SPCAUT value of *USRCLS:
Since the user class parameter is used only when the special authority parameter is set to *USRCLS, you can override the special authorities at any time—with no permanent tie to the user class value. If you assign special authorities that don't match the user class defaults, you see this warning: "User class and special authorities do not match system supplied values." This means that it's possible for a profile that was originally designated as a *USER-class profile to be granted all eight special authorities of a security officer. Similarly, a *SECOFR-class profile can have its special authorities removed to reduce its capabilities to those of an end user.
Who Has the True Power?
You can use the Print User Profile (PRTUSRPRF) command to see a simple listing of profile information. However, PowerTech's Compliance Monitor auditing solution provides comprehensive information that isn't available through the operating system, including:
In addition, many administrators are unaware that special authorities can be inherited from group profiles. It's critical to review this information to ensure that powerful users aren't overlooked. Compliance Monitor includes this inherited authority information on a number of user reports (see Figure 1).
Figure 1: The Powerful Profile report includes both user class and inherited special authority information. (Click image to enlarge.)
Review Your Own Powerful Users
To determine how many overly powerful users are on your system, register for a no-cost PowerTech Compliance Assessment. Or try Compliance Monitor free for 30 days. Learn more about Compliance Monitor by clicking here!
|Last Updated on Friday, 16 July 2010 01:00|