|
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.
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 i5/OS & OS/400 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.
SkyView Partners Solutions
- Customers say … “Risk Assessor automatically provides an independent,
comprehensive security overview and has reduced our overall audit
time and expense.”
-
Customers say … “With Policy Minder we have automated our
security compliance procedure, saving us time and making
sure that our desired security configuration stays in place.”
About the author
Carol Woodbury spent 16 years with IBM in Rochester, MN. She served
for more than 10 years as the AS/400 Security Architect and Chief
Engineering Manager of Security Technology for IBM's Enterprise Server
Group. During this time Carol provided security architecture and design
consultations with IBM Business Partners and large AS/400 customers.
She is known worldwide as an author and speaker on security technology,
specializing in OS/400 and i5/OS security issues. Carol co-authored
the popular book, Experts'
Guide to OS/400 and i5/OS Security from 29th Street Press, has
written numerous articles on security and is a technical editor for
the IBM Systems Magazine. Carol is also a subject matter expert on
security for COMMON, security author for Experts Journal, contributing
author on security for System iNEWS and MC Press Online and the security
expert for search400.
|
