Developers Can Improve Security and Reduce the Administrative Cost of Security

One simple tool allows developers to improve the security of their applications and associated resources and reduce the administrative cost of managing security for the whole system. That tool is adopted authority. Adopted authority is an important tool for developers to have in their toolkit because it allows them to build applications that ensure users never encounter an authority failure even when administrators use PUBLIC(*EXCLUDE) authority on all sensitive resources. The combination of adopted authority and PUBLIC(*EXCLUDE) significantly increases the level of security and decreases the cost of managing security.

It’s true that system administrators can change programs to adopt authority. However, it’s better to leave the decision of whether a program should or should not adopt authority up to the developers that designed and implemented the program. They have a much better understanding of the internals of an application.

A program may “adopt” the authority of the owner of the program. But what does that mean? Adopted authority adds the authority of the owner of the program to the authority of the user executing the program. When a program adopts its owner’s user profile, the system uses the following user profiles to determine whether access to a resource should be allowed:

• Job’s current user profile (and groups)
• Current program’s owning user profile
• Any other user profiles adopted by programs called prior to the current program and still in the call stack (i.e., have not already completed)

The system manages adopted authority in the call stack entries for each job. At the time a program is loaded for execution, the system checks if the program adopts authority. If so, the system adds the owning user profile to the call stack entry for that program. As long as a program remains in the call stack, its adopted authority remains available for itself and for all subsequent programs in the call stack. If a subsequently called program in the job also adopts authority, its owning user profile is available to that program along with adopted user profiles associated with any other programs in the call stack. When a program completes and its call stack entry removed, its adopted user profile is no longer available to any programs in the call stack.

So how do you configure an application to adopt authority? It’s simple.

All *PGM programs have a “User profile” attribute. The value of the attribute can be either *USER or *OWNER. Setting this value to *OWNER causes the program to adopt the authority of the user profile that owns the program.

You can set this attribute at create time using any of the CRTXXXPGM, CRTBNDXXX and CRTSRVPGM commands. For example:

CRTRPGPGM PGM(lib/pgm-name) . . . USRPRF(*OWNER)

You can change the value of this attribute using the OWNER parameter on the CHGPGM command:

CHGPGM PGM(lib/pgm-name) USRPRF(*OWNER)

The default value of the USRPRF parameter is *USER.

All program objects (type *PGM) have another attribute related to adopted authority: “Use adopted authority”.

This causes folks a fair amount of confusion. One might naturally assume that this is the parameter that indicates the program should adopt authority, but it isn’t. This parameter allows developers to control whether authority adopted by programs earlier in the call stack should be used when this program executes. If set to *YES, it will use previously adopted authority. If set to *NO, it won’t. This value does not control whether this program adopts authority from its owner’s user profile. When a program or service program is created, this value defaults to *YES. You can change the value using the CHGPGM or CHGSRVPGM command. For example:

CHGPGM PGM(lib/pgm-name) USEADPAUT(*NO)
CHGSVRPGM PGM(lib/pgm-name) USEADPAUT(*NO)

You can learn more about authority checking and adopted authority here.

Like any tool, adopted authority can make a lot of things much easier and more secure. However, like any tool, adopted authority can also be misused. Blindly adopting authority of every program can create security problems.

In my next tip, I’ll share some guidelines to help you use adopted authority wisely.

Patrick Botz, an internationally known information security expert, is the President and CTO of Botz & Associates, a firm specializing in information security services for IBM i, AIX, Unix and Linux environments. With decades of experience in key system security positions, Patrick’s expertise includes security strategy; security policy enforcement; password management and single sign-on; industry and government compliance; and biometrics. As Lead Security Architect at IBM and founder of the IBM Lab Services security consulting practice, Patrick worked with IBM customers worldwide and achieved intimate knowledge of system security capabilities and pitfalls on a broad spectrum of platforms, with special emphasis on IBM i (formerly AS/400), AIX, Linux and Unix operating systems. He architected the SSO solution for OS/400 and i5/OS, and he holds several security-oriented patents. Patrick is the author of numerous trade press articles and a co-author of the book Expert’s Guide to OS/400 and i5/OS Security. In addition, he is a worldwide speaker on various platform-specific and general security topics. Send your questions or comments for Patrick to Ted Holt via the IT Jungle Contact page.