RE: USEADPAUT *NO

There's one set of menu programs. It controls access to all
environments (prod/test/dev) based on a parameter on the initial CALL.
Among other things, the menu builds the library list. Running the
application outside of the menu system is pretty hairy because the menu
builds "Job ID" copies of the LDA for every program call, stores tons of
information in these data areas, and uses the information to build work
files, limits files (yes, limits files), keys for job and application
control records, etc. We've got prod, test, dev all on one system (no
LPAR). So we lock developers out of production based on their
user/group information. Production users are in a group that has full
access to the production libraries for data and object
read/write/update/delete. Developers have read access to production
data and execute access to programs. Developers also have full access
to their own set of application data libraries. They've been able to
call the menu to access production date in read only mode (in theory)
for debugging production issues, but there's an exposure. Guaranteeing
that developers don't have menu access to programs that perform updates
is extremely complicated.

The menu system circumvents the security strategy. The menu owner is
also the entire product's owner, with full rights to all application
data. The menu is created as USRPRF(*OWNER). Application programs Use
Adopted Authority. So developers can call the menu and carry its
authority into production data. I'm planning to break the adoption
chain by changing the application programs to not Use Adopted Authority,
and change the system value so that production programs won't be created
with Use Adopted Authority set to *YES. Changing the menu programs to
USRPRF(*USER) is much more scary for reasons I've already mentioned.

It's not an audit issue, yet. It's a security issue nonetheless...

I can accomplish what I want to accomplish by setting up the QUSEADPAUT
system value with a restrictive authorization list, so I don't need a
DCR. It just seems a bit convoluted. Since the default effectively
sets USEADPAUT to *YES for all compiles I was wondering what I might be
missing, and if anyone else has had to deal with this program attribute.

Much thanks...

-Jim

_____________________________________________

Jim,

What's not clear is what you're trying to do by removing the adopted
authority in the first place.? You say it's not an audit or compliance
finding, so I'm a tad confused (and it's late on a Monday!).

Best regards,

Steven W. Martinson, CISA, CISM, CISSP
Security Consultant
Cypress, Texas

_____________________________________________
From: Jim Damato
Sent: Monday, March 24, 2008 11:08 AM
To: midrange-l@xxxxxxxxxxxx
Subject: USEADPAUT *NO

I've been researching the Use adopted authority program attribute, and
I'm finding it to be a bit convoluted. I know that USEADPAUT(*YES)
allows a program to retain adopted authority from a previous program
in a job's call stack -- if the previous calling program is created
with the User profile attribute as USRPRF(*OWNER).

What's strange to me is that the program create/compile commands have
USRPRF as an explicit parameter, but that USEADPAUT is controlled in a
more roundabout way. A program can be changed via CHGPGM to USEADPAUT
*YES or *NO, but it's not on compile commands. For programs to be
created with USEADPAUT set to *NO the system value QUSEADPAUT has to
be set a certain way:

A diagnostic message is signaled to indicate that the program is
created with USEADPAUT(*NO) if all of the following are true:

* An authorization list is specified for the QUSEADPAUT system
value.
* The user does not have authority to the authorization list
mentioned above.
* There are no other errors when the program or service program is
created.

If the user has authority to the authorization list, the program or
service program is created with USEADPAUT(*YES).

QUSEADPAUT is shipped with a value of *NONE, so all programs compile
with USEADPAUT set to *YES by default. This is a problem for us
because our third party software's menu system adopts authority for
the menu and product owner. The menu system controls licensing of the
package, so we don't have access to the code, and we're afraid to
change it (and we're not under support). I'm preparing to change the
QUSEADPAUT value to *NONE to a authorization list that forces
production programs to compile as USEADPAUT *NO. We'll also end up
performing a mass change to *NO on all the non-menu production
programs.

Because it seems kind of difficult to force this value for the
default, and because our DEV, TEST, and PROD code are all on the same
server partition I'm a bit worried. Has anyone else had to mess with
this system value or change it on the bulk of their programs? We've
made it through tons of audits and SOX stuff, but this parameter never
comes up with the auditors. No one's thought to put it on their
checklist, I guess.

-Jim

James P. Damato
Sr. Manager - System Administration
Dollar General Corporation