Top 5 IBM i Security Questions

By Carol Woodbury

It seems as though wherever I go, some common questions are asked. So I thought I’d take a few moments and answer them for everyone. Here we go (in reverse order.)

Question #5: What is primary group authority?

Primary group authority was created to accommodate the concept of group authority in UNIX. It was added to OS/400 when IBM added support for the Integrated File System (IFS). All of these functions were added to facilitate porting UNIX applications to run on OS/400. Primary group authority can only be given to a group profile. In addition, only one group profile can be the “primary group” of an object.

Primary group authority is very similar to a private authority granted to a group profile. The biggest difference is that the primary group and its authority are stored in the header of the object (vs with the user profile as private authorities are). And primary group authority is checked before any private authorities the group may have; therefore, there is a slight (and I do mean slight) performance gain when using primary group authority. The gain is so small it’s not worth the time it would take to change your security configuration.

Question #4: What authority is required to run (name your favorite command)?

Appendix D in the IBM i Security Reference lists all of the Control Language commands, along with the authority needed to run each command. The commands are listed by the type of object they act on, for example, user profiles, jobs and so forth. At the end of each command group are notes listing additional requirements, for example, the fact that users running the user profile commands must have *SECADM special authority.

Question #3: Isn’t adopted authority dangerous and shouldn’t it be avoided?

Adopted authority allows you to temporarily grant users the ability to perform a task without having to assign them the authority permanently. If you blindly compile programs that are owned by QSECOFR or some other profile without examining them to determine their function, then yes, adopted authority can be very dangerous and can be used to subvert the security on your system.

However, not just anyone can create a program that adopts the authority of a powerful profile. For example, to change the owner of a program that is configured to adopt authority (that is, the User profile parameter is set to *OWNER), you not only have to have *ADD authority to the new owner’s profile, you must also have *ALLOBJ and *SECADM special authorities. Also, if a program is already owned by a powerful profile, to change it to adopt (i.e., set the User profile to be *OWNER), you must be the owner or have *ALLOBJ and *SECADM special authorities.

Used carefully, adopted authority can eliminate the number of users required to have special authorities. For example, our clients often write utilities – CL programs that adopt a profile having *ALLOBJ and *SECADM special authorities – to perform password resets. This way, the help desk can adopt the authority needed to reset passwords when users forget them, but they do not need to have permenent special authorities to perform the task.

Question #2: Which is checked first, group authority or user authority?

The authority checking algorithm checks the user, then the groups and then *PUBLIC authority. Specifically, it looks first to see if the user has *ALLOBJ, then for a private authority and then for the user’s authority to the authorization list securing the object (assuming there is one.) If no authority is found at the user level, the user’s groups are checked – first for *ALLOBJ, then primary group authority, private authority and private authority to an authorization list. Finally, if no authority is found for the user or the groups then *PUBLIC authority is checked.

Question #1: Which is better – group profiles or authorization lists?

It’s not a matter of one being better than the other. It’s a matter of using the one that makes the most sense for the problem you’re trying to solve. If you have several profiles that all need the same authorities, you’ll want to put them in a group and authorize the group. In addition, group profiles are the way to implement role-based access for IBM i. Create a group to represent a role, authorize the group according to the tasks required by the tasks this role must perform. Then add the users that perform this role as a member of the group.

Authorization lists allow you to authorize numerous objects in the same way. For example, if users need the same authority to a number of files, you can secure the files with an authorization list, then grant the users authority (for example *USE) to the list. The user now has *USE authority to any file secured by the authorization list. I often use a combination of authorization lists and groups. For example, an Accounts Receivable application has a set of files that the accounting manager role is allowed to download. So I secure those files with an authorization list, then grant the group profile representing the Accounting Manager role *USE authority to the authorization list. When another person is hired in that role, you can simply add them to the Accounting Manager group and they automatically have authority to the files they need.

Summary

I hope that by answering these popular questions, I’ve answers some of the questions you’ve had about security for IBM i.

About the Author

Carol Woodbury is President and co-founder of SkyView Partners, Inc, a firm specializing in security policy and compliance management software as well as security consulting and remediation services.

Carol can be reached at carol.woodbury@skyviewpartners.com