What does the Use adopted authority program attribute do?

I've told you about adopted authority, which gives users temporary access to objects or additional authorities. I've explained that adopted authority is a program attribute and that to make a program adopt, the User profile parameter needs to be set to *OWNER (rather than the default setting of *USER.) However, I've neglected to explain the Use adopted authority program attribute and its role in the adopted authority flow.

What Use Adopted Authority Does

By default, the program attribute Use adopted authority is set to *YES. That means that when PROGRAM_A calls PROGRAM_B, the adopted authority of PROGRAM_A is passed to PROGRAM_B. In fact, if 10 other programs subsequently get called, they all have the ability to "use the adopted authority" that originated with PROGRAM_A. But what if PROGRAM_K is created with its Use adopted authority attribute set to *NO? The effect is that PROGRAM_K and any programs called from PROGRAM_K are blocked from being able to "use the adopted authority" from PROGRAM_A.

Think of the Use adopted authority attribute as a flow valve. If the attribute is *YES, the valve is open and the adopted authority is allowed to flow through and be available for use by the tasks being performed in the program. If the attribute is *NO, the valve is closed and the adopted authority is not available to that program.

When to Set Use Adopted Authority to *NO

If PROGRAM_A is owned by QSECOFR and adopts, it provides significant power to any program called out of PROGRAM_A. If PROGRAM_A calls PROGRAM_C, which pops up a command line, you want to make certain that PROGRAM_C's Use adopted authority attribute is *NO so that the user cannot take advantage of QSECOFR's power from the adopted authority in PROGRAM_A.

One approach that some of you take when re-architecting the security scheme of an application is to set all programs to adopt (i.e., set the User profile attribute of all programs to *OWNER) as well as set all programs to not use adopted authority (i.e., set the Use adopted authority of all programs to *NO.) You would take this approach to defeat someone from adding a Trojan horse that can take advantage of the application's adopted authority. If a user has the ability to add a program (Trojan horse) to a library that is in the library list before the application's library and that program is configured as Use adopted authority *YES, then it will take advantage and be able to use any adopted authority that has occurred in previously called programs.

Enter the QUSEADPAUT System Value

To defeat this scenario, the QUSEADPAUT system value was added to the operating system. If you specify an authorization list name (most create an authorization list called QUSEADPAUT so it's purpose is obvious) in the system value and the user creating or changing a program or service program is not authorized to the authorization list, the program's Use adopted authority parameter will be set to *NO, regardless of what is actually specified for this attribute. This effectively controls who can create a Trojan horse that takes advantage of the adopted authority from previous programs. Before specifying an authorization list for this value and setting the *PUBLIC authority of the authorization list to *EXCLUDE, you need to consider the users who need to create programs that use adopted authority. For example, users who perform change management promotions may need to create programs with Use adopted authority. For them, simply grant *USE authority to the authorization list named in the QUSEADPAUT system value. 

How Policy Minder Helps

Policy Minder can help you with the compliance issues surrounding the QUSEADPAUT system value in at least the following ways:

•  By running regular Policy Minder compliance checks on the System value category, you can be sure that no one removes the authorization list from the QUSEADPAUT system value. By running regular compliance checks on the Authorization list category, you can monitor the users having authority to the authorization list named in the QUSEADPAUT system value.

•  If you have implemented a security scheme where all programs are configured to not use adopted authority, you can define an object template for your programs, specifying Use adopted authority *NO. When you run a compliance check on the programs, Policy Minder will identify any programs that are non-compliant (in other words, set to Use adopted authority *YES).

•  If any programs are non-compliant, you can use the FixIt function to set the programs to Use adopted authority *NO.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale