Carol Woodbury's i & i5/OS Security Tip

Utilizing the QUSEADPAUT System Value
21 APR 2008
Greetings!
 
Here is your latest i5/OS Security Tip from SkyView Partners, Inc. 

In past newsletters I've talked about adopted authority - that it is a temporary way to give users access to objects or additional authorities.  I've also explained that adopted authority is an attribute of a program and that to make a program adopt, the User profile parameter needs to be set to *OWNER (rather than the default setting of *USER.)  One program attribute that merits additional explanation however is Use Adopted Authority and its role in the adopted authority flow.

Below, I show the best way to utilize the QUSEADPAUT system value.  In addition, I show how SkyView Policy Minder can help with the compliance issues surrounding the QUSEADPAUT system value.
 
Sincerely,
 

Carol Woodbury, President

SkyView Partners, Inc. 
Questions?
Before I get started, I want to say that SkyView Partners is committed to delivering security compliance products and services that provide our customers with sound advice that saves them time and reduces the costs and complexities of attaining and maintaining compliance.
 
So, if you have a question, please click here to Contact Us.
 
Now, on to this month's i & i5/OS Security Tip.
What does Use Adopted Authority do?
 

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 along to PROGRAM_B.  In fact, if ten other programs subsequently get called, they all have the ability to "use the adopted authority" that was originated with PROGRAM_A.  But say, however, that PROGRAM_K is created with its Use adopted authority attribute set to *NO.  What is the effect?  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 would you ever 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 will want to make certain that the 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 the scenario described above, 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 the person actually specified for this attribute.  This is an effective way to control 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 that do need to create programs that use adopted authority.  For example, users such as those that perform change management promotions may need the ability to create programs the use adopted authority.  For those users, simply grant them *USE authority to the authorization list named in the QUSEADPAUT system value.
  • System values
  • Authorization lists
  • Objaut templates
 
 
*  *  *
 
Carol's Tech Tip
How SkyView Policy Minder can help
 
SkyView Policy Minder is an i & i5/OS security compliance tool that provides a mechanism for comparing your systems' current settings against the requirements of your established (or desired) security policy.  Policy Minder is about "enforcing" your securitypolicy.
 
Policy Minder can help you with the compliance issues surrounding the QUSEADPAUT system value in at least the following ways:
 
  • You can be sure that no one removes the authorization list from the QUSEADPAUT system value by running regular Policy Minder compliance checks on the System value category.  You can monitor the users having authority to the authorization list named in the QUSEADPAUT system value by running regular compliance checks on the Authorization list category.
  • If you have chosen to implement or want to implement 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 out of compliance - in other words, set to Use adopted authority *YES.
  • If any programs are out of compliance, you can use the FixIt function to set the programs to Use adopted authority *NO.
 
* * *
 

 
See Carol Woodbury's
Risk Assessor for i & i5/OS

a
security diagnostic tool.
 
Video Introduction to Risk Assessor (4:08)

See Carol Woodbury's
Policy Minder for i & i5/OS 
a
security compliance tool.
 
Video Introduction to Policy Minder (4:22)

Carol Woodbury's Bio

Carol Woodbury

Carol Woodbury is President and co-founder of SkyView Partners, Inc. and is the designer and architect of the SkyView Partners' products. 

 

Carol has over 17 years in the security industry, 10 of those working as the Security Architect and Chief Engineering Manager of Security Technology for IBM's Enterprise Server Group.

Who is SkyView Partners?

SkyView Partners Inc. is a firm specializing in security policy and compliance  software and services for IBM System i (AS/400, iSeries)customers.

DEMOS
Do you want to see SkyView Partners' solutions in action?
 

Click here to register for a demo.

 

FREE Whitepaper

Compliance has become a four-letter word to many of you. There are compliance committees, compliance officers, compliance newsletters and more. What does "compliance" really mean and how does one achieve it?
 

 

© SkyView Partners, Inc., 2008. All rights reserved.