Manage Learn to apply best practices and optimize your operations.

Removing *ALLOBJ access and raising system security levels

ISeries security expert Carol Woodbury explains how to smoothly transition to a higher system security level.

All of our users currently have *ALLOBJ authority (I know, I cringe whenever I think about it) and we are currently running at a security level 20 (again I cringe).

We would like to get up to at least a level-30 security and get rid of the *ALLOBJ. What are some considerations we should keep in mind to make sure we don't shoot ourselves in the foot?

As you are well aware, this security level is wide open. That's because, by default, at security level 20, i5/OS creates all profiles with *ALLOBJ special authority. To move from security level 20, some planning is required.

When moving to a higher security level, i5/OS will strip *ALLOBJ from all profiles except those in the *SECOFR user class. Therefore, you're going to have to decide how users are going to get enough authority to access and, where appropriate, modify the application data since it will no longer come from users having *ALLOBJ. Although several options exist, my preferred method is to have sufficient authority come from adopted authority. This allows you to set the appropriate authority on the database files – either *PUBLIC authority of *USE or *EXCLUDE. Yet, because the application adopts authority, users will still be able to perform their job functions when they come through the application menu. Accommodations will have to be made for any interface that accesses the data through something other than the application menus. To accommodate these database accesses, I usually secure the database files with an authorization list and grant authority to these "outside" processes so they can access the application files.

The interesting thing about security level 20 is that you can test changing the application's security scheme even before you change security levels. This is helpful because changing the security level requires an IPL before it takes effect. While it may appear that there is no security checking at security level 20, in reality, the same algorithm is run regardless of the security level. It just looks like there is no security checking because every profile has *ALLOBJ, so no profile is ever denied access. But you can remove a user's *ALLOBJ, even at security level 20. So you can test your new security scheme by creating a profile, removing its *ALLOBJ special authority and verifying that the application still works properly by running as this newly-configured profile.

I encourage you not to stop at security level 30, however. You really want your system running at security level 40 or 50. The steps to move to security level 40 are clearly explained in Chapter 2 of the iSeries Security Reference manual, available from the IBM Information Center.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.