December 20, 2011 - Vol 1, Issue 6
The Problem With Too Many IBM i Private Authorities
By Dan Riehl
When an object is created, it is owned by either the user that created the object or by the user's primary group profile. Ownership depends on the OWNER attribute of the user profile. If the value is set to OWNER(*GRPPRF), objects created are owned by the user's primary group, if OWNER(*USRPRF) is specified, objects are owned by the user, not the group.
To view objects owned by a user profile you can use the command:
In addition to ownership, a user can be assigned explicit private authority to an object using the command GRTOBJAUT(Grant Object Authority), or by adding a user from the EDTOBJAUT(Edit Object Authority) display.
Normally, we want to avoid adding private authorities to an object. We typically want all of our User objects to be secured by an authorization list containing group profile names, and not individual user names.
Once we start down the path of assigning private authorities at the user level, rather than at the group profile level, we begin to build an overly complex security scheme that will require constant maintenance as users come and go. Using Authorization Lists and Group Profiles in our authorization settings provides the least complex configuration, and requires the least amount of on-going maintenance. We do not have to make additions and changes every time a new user is added, or when a user's job function changes. In those cases, we simply assign the user to the correct group profile.
The Bugaboo of Private Authorities
Any private authorities that exist, should be assigned at the Group profile level. But, alas, our systems have evolved over time, and what we typically have is a hodgepodge of mixed ownership and numerous private authority inconsistencies.
One of our aims should be to remove private authorities that exist for individual users, and reassign the authority to their group. That is, if the private authority is really needed at all.
IBM has provided the command WRKOBJPVT(Work With Objects by Private Authority). The command is used to list all the private authorities that are held by a user. NOTE: If the user is the owner of the object, the object will not be included in the Private Authority report. Ownership is reported using the WRKOBJOWN command as discussed above.
Here is a command to list all the private authorities that are in place for user profile DRIEHL, and the resulting report.
Work with Objects by Private Authority User profile . . . . . . . : DRIEHL Type options, press Enter. 2=Edit authority 4=Delete 5=Display authority 7=Rename 8=Display description ASP Opt Object Library Type Attribute Device SECURITY QSYS *LIB PROD *SYSBAS DRIEHL QSYS *USRPRF *SYSBAS CILASOFT QUSRSYS *MSGQ *SYSBAS CLASSUSER QUSRSYS *MSGQ *SYSBAS DANRIEHLB QUSRSYS *MSGQ *SYSBAS DR QUSRSYS *MSGQ *SYSBAS GROUP_OPS QUSRSYS *MSGQ *SYSBAS GROUP_RPG QUSRSYS *MSGQ *SYSBAS More...
Our objective in this context should be to remove as many private authorities as possible from the user id, and if needed, assign any private authorities to group profiles only.
Caveat: Each user will have, and should retain, a private authority to their own user profile and to group profiles for which they are a member.
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.