Admin Alert: The Dangers of User Profiles with Privileges

Published: December 10, 2008

by Joe Hertvik

Handling user profile authorities is one of the more critical i5/OS administrative duties. In particular, there are three crucial user parameters that must be set up correctly to prevent your users from inadvertently accessing objects and functions that they should not be using. Today, I'll look at how you can work with these values to prevent several avoidable security pitfalls.

The Hierarchy of User Authority

Before you can work with user authorities, you must understand what they do. Here is the basic hierarchy of user profile security settings and how they relate to each other.

1. System privileges--Eight user profile settings that tell i5/OS exactly what a user is allowed to do on the system. These settings control whether the user can perform service functions, how they interface with spooled files and jobs, how they can access system objects, whether they can save and restore system objects, and whether they can control system auditing.
2. Privilege class--Privileged classes are prepackaged roles that can be assigned to new or existing user profiles. When creating a new user profile, the privilege class automatically grants specific system privileges to the user profile.
3. Groups--Allows you to enroll a user profile as a member of an i5/OS group. A user profile can be enrolled in several groups at the same time. In addition to the system privileges a user profile may already have, group members also inherit the system privileges of any user profile groups that they are enrolled in.

These values can be changed by using the green screen user profile commands or by using the Capabilities feature inside the iSeries Access (OpsNav) user properties screen. For this article, I'll demonstrate how to manipulate these features by using OpsNav.

System Privileges--The Core Element

It's important to understand that all user profile-based authorities are controlled through a user's system privileges. Also known as special authorities, eight separate system privileges can be assigned to each user profile. These privileges can be individually assigned or they can be assigned as a group when the user profile is created or modified.

To work with a user's system privileges, open the Users and Groups→All Users→user profile name node in OpsNav. On the user properties screen, click on the Capabilities button then click on the Privileges tab inside the Capabilities window. Under the settings that appear, you'll be able to set the following system privileges for the user.

• All object access--This setting gives the user carte blanche to access any system object on the partition. All object access is the most dangerous user profile setting in the system. When a user possesses this authority, there is literally no object that they cannot access or update. That's why the rule of thumb is to only provide all object access on an as-needed basis, giving it sparingly to system administrators. It's also wise to keep this privilege away from your applications staff.
• Auditing control--This setting allows a user to perform auditing functions, including turning auditing on and off, as well as the ability to control user and object level auditing.
• Job control--This setting is ideal for operational personnel as it allows users to display, hold, change, release, clear, and cancel any jobs running inside a subsystem. With job control, a user can manipulate jobs sitting in job queues or in output queues. It also allows users to work with printer writers and to start and stop subsystems.
• Save/restore--Allows the user to save, restore, and free storage for system objects. Save/restore authority is in force regardless of whether the user has private authority to the object that is being saved or restored. Save/restore is another setting that is usually reserved for system operations personnel.
• Security administration--This setting allows users to create, change, or delete user profiles. However, security administration does not allow the user to work with every user profile in the system. Security administrators can only manipulate user profiles if they are authorized to run the user profile commands and if they have authority to the user profiles that they want to change. Security administrators also cannot provide user profiles with more system privileges than the administrator possesses. This can be handy for setting up departmental security officers who can handle simple user profile administration for a group of people.
• Spool control--Allows the user to perform any command or function that deals with spooled files. Spool control is the safest system privilege you can provide for a user.
• System configuration--This privilege allows the user to change system I/O configurations. System configuration is best reserved for system operations and administrators who may need to create and modify system devices.
• System service access--Allows the user to perform service functions on the system. Best used for service personnel and system administrators.

Besides using OpsNav's user capabilities features, system privileges can also be set inside the green screen Create User Profiles (CRTUSRPRF) and Change User Profiles (CHGUSRPRF) commands. System privileges are called "special authorities" within these commands, each privilege has a slightly different name on the green screen commands, and privileges are changed in the command's Special Authorities (SCPAUT) parameter list. Here's a quick cheat sheet for how you map each system privilege to a special authority setting in the CRTUSRPRF and CHGUSRPRF special authorities list.

Privilege Classes--Assigning System Privileges by Roles

When you create a user, you also need to assign them a privilege class. A privilege class does two things. It designates what type of user you are adding to the system, and it automatically assigns system privileges that are appropriate for the privilege class that the user belongs to.

In OpsNav, the class is assigned to newly created users by using the same Capabilities screen where you assign or modify their system privileges. Here you can assign a user's privilege class and the accompanying system privileges that each class will automatically set up for the user. The available classes and the system privileges they enable are the following:

• User--When you assign user as the user privilege class, OpsNav will not assign any system privileges to that user. You need to manually select which privileges that you want the user to have.
• Programmer--Same as user. No system privileges are automatically assigned.
• System Operator--Automatically assigns Job Control and Save/Restore privileges.
• Security Administrator--Assigns Security Administration privileges to the user.
• Security Officer--Automatically assigns ALL system privileges to the user. Should be used sparingly and only for your most trusted users, those who need all of these authorities.

When changing a user's privilege classes, OpsNav will automatically reset the system privileges for that user to match its new class value. So if I change a user from a Security Officer class to a User class, OpsNav will take away all of the system privileges that were assigned to the user when it had its Security Officer class.

Privilege classes and associated privileges are also assigned to users through the User Class (USER) parameter in the CRTUSRPRF and CHGUSRPRF commands. In both commands, privilege class is called user class and the class value can be found in the User Class parameter (USRCLS). The settings for each privilege class (user class) are called the following in the green screen commands.

• User = *USER
• Programmer = *PGMR
• System Operator = *SYSOPR
• Security Administrator = *SECADM
• Security Officer = *SECOFR

There is one other difference in setting privilege class with green screen commands, as opposed to setting it through the OpsNav Capabilities screen. With OpsNav, if I change a privilege class from one class to another, the system will automatically change all the user's system privileges to match the privileges that are always assigned to the new class. However, if I use the CHGUSRPRF command to change a user's class value, the user profile will retain the system privileges (special authorities) that the user had under the old privilege class. CHGUSRPRF does not automatically adjust system privileges to match a new privilege class, the way that OpsNav does. If you're using the CHGUSRPRF command to change a user's privilege class, be sure to also manually check and change the system privileges so that they match the new privileges you want the user to have.

User Groups--The Wild Card In Assigning System Privileges

Similar to other systems, i5/OS allows you to assign individual users to one or more user groups. Also like other systems, when a user is assigned to a group, the user inherits any system privileges the group possesses that aren't already possessed by the user. In OpsNav, you can assign a user to as many groups as you would like by clicking on the Groups button inside the user properties screen (again, you can get to the OpsNav User properties screen by opening the Users and Groups→All Users→user profile name node). For example, let's say that I have a user called JOE who has a privilege class of User, and that user profile doesn't possess any system privileges. If I change JOE's user profile to enroll it in a user group profile called SECUSERS that has a user class of Security Officer, JOE will now inherit all of SECUSERS' system privileges just by being a member of the SECUSERS group profile. Because of this security loophole, JOE instantly went from being a security slug to being a security powerhouse, which may not be desirable.

User groups can also be assigned to a user by using the CRTUSRPRF and CHGUSRPRF commands. You can assign one primary group profile to the user by entering a group name in the Group Profile (GRPPRF) parameter. If you want to assign the user to more group profiles, you can enroll the user in several more user groups by entering each group name into the Supplemental Groups (SUPGRPPRF) parameter list.

Lessons To Be Learned

Besides understanding how to use privilege classes and group profiles to set up a user's system privileges, these features can also create a few system pitfalls when creating and modifying i5/OS users. In particular, beware of the following security issues that can occur when you don't set a user's system privileges, privilege class, and user groups properly.

1. Be careful when manually assigning any system privilege to a user, as each of these privileges can open up security holes on your system. Only assign those system privileges that a user truly needs.
2. Be extremely careful when assigning all object access and save/restore privileges to a user. All object access allows a user to possess carte blanche access to all system objects (modify, copy, delete, etc.), while save/restore allows a user to save copies of system objects (possibly for transport off the system) and to restore new objects over existing objects. In general, only system administrators should have all object access. System operators responsible for backup and restore operations should be the only ones to possess save/restore authority.
3. When using the Change User Profile (CHGUSRPRF) command to change a privilege class (user class), be sure to inspect and modify the system privileges (special authorities) associated with that user. CHGUSRPRF does not modify a user's system privileges to match his privilege class when the privilege class is changed.
4. Be careful which group profiles that you assign your users to, because the user may inherent unintended system privileges from any group profile that he belongs to. Make sure that your users don't accidentally inherit all object access from a group that they belong to.

About Our Testing Environment

This article was tested on a System i 550 partition running i5/OS V5R4. We tested the OpsNav features by using the iSeries Navigator program that came with iSeries Access for Windows V5R4M0. Information presented here may also work with earlier versions of the i5/OS and OS/400 operating systems and with pre-V5R4M0 versions of iSeries Navigator. However, earlier versions may have slightly different features due to improvements that were made from release to release.

RELATED STORIES

A Checklist for Creating OS/400 User Profiles, Part I

Creating an i5/OS User Profile Architecture

Six Simple Rules for Group Profiles

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot