Using Adopted Authority Wisely

In my previous tip I explained adopted authority and admonished developers to use it wisely. This tip identifies some rules of thumb you should bear in mind when contemplating the use of adopted authority.

User profile to adopt: If you’re not used to using adopted authority in your applications, one of the first questions that comes to mind might be “which user profile should I adopt?” The most straightforward way to use adopted authority is to adopt the authority of the owner of the objects used by the application.

Rule: Create a user profile with ENABLED *NO, PWD *NONE, Initial Program *NONE, and initial menu *SIGNOFF. Change all program and non-program objects of the application to be owned by this user profile. Using this rule makes it easy to change any program in an application to ensure that it will not encounter an authority failure. The program will adopt the authority of the owner of all of the application objects. Since all the application objects are owned by the same profile and the owning user profile of any object has *ALL authority to that object by default, the program is guaranteed to be authorized to any resource it accesses.

Authority of programs that adopt authority: The primary reason to adopt authority is to ensure that the program will not fail due to an authority failure. Therefore, allowing everyone on the system to run programs that adopt authority is a security issue.

Rule: PUBLIC authority of programs that adopt authority should be *EXCLUDE. Users should get the authority to run these programs through group membership.

Adopted authority inheritance: One of the most useful aspects of adopted authority is that adopted profiles are inherited by subsequent programs in the call stack. But this is a double-edged sword. If your program (or one that is subsequently called by your program) either directly or indirectly displays a command line prompt, you almost certainly don’t want commands run from that command line to execute with the adopted authority.

Rule: Set the USEADPAUT attribute of programs that display a command line to *NO.

Even better rule: Create a service program to display a command line. Rather than putting the code to display a command line in each program that needs to, put that code in a service program and call it like a procedure. Set the USEADPAUT value of the service program to *NO. That way, only the displayed command line runs without adopted authority, not all of the function in each program that displays a command line.

Adopted authority inheritance, part 2 Adopted authority is managed through the call stack. When a program causes another program or command to run in a different job (e.g. SBMJOB, TRFGRPJOB, trigger programs, etc.), the authority adopted by programs running in the original (or source) job is not available to the programs that run in the other (or target) job. If this wasn’t a limitation of adopted authority, then developers would only have to change the initial program of an application to adopt authority and leave the rest as is.

Rule: For existing applications, search your code for all SBMJOB and TRFGRPJOB commands. Ensure the target program or command processing program adopts authority.

Trigger programs: are another example of programs that don’t run within the current job’s call stack. Using adopted authority on trigger programs is usually required in order to maintain PUBLIC *EXCLUDE authority on your database files.

Rule: Change trigger programs to adopt authority

These rules of thumb are by no means exhaustive, and they all have exceptions. However, remembering these rules can help you quickly identify and solve authority failures issues and help you avoid introducing new security issues in your programs and applications.

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.

RELATED STORY

Developers Can Improve Security and Reduce the Administrative Cost of Security