Manage Learn to apply best practices and optimize your operations.

Preventing adopted special privileges on i5/OS

This iSeries administrator's tip on i5/OS security has been adapted from a user question about preventing users from gaining special privileges when a command line has been displayed from a program that adopts owner authority.

Carol Woodbury

One of the last hurdles most people face when trying to understand i5/OS security is trying to prevent users from gaining special privileges when a command line has been displayed from a program that adopts owner authority.

Since the IBM programs that display a command line (QCMD, QUSCMDLN) aren't observable, the program can't be duplicated and the option to adopt authority can't be removed.

There are different approaches to solving this. One is to create your own programs of the same name that do not adopt authority, but call the IBM programs and place your programs at the top of the library list, thus breaking the chain of adopted authority.

This approach may work, but there's no guarantee that your version of the IBM programs – even though it's ahead of QSYS in the library list – will get called. They may be "hard-coded" to go to the one in QSYS.

Nothing is perfect, but in addition to the approach you've described, here are some things you can do to further reduce the risk in your situation:

  • If you have control over the application's use of QCMD or QUSCMDLN, "wrap" the call to these programs in a program that is compiled with Use adopted authority set to *NO and call that program rather than relying solely on getting your version of the program called (out of a library higher than QSYS).
  • If any menu options run a WRKxxx command, an i5/OS command line is usually displayed. In this case, "wrap" the call to the command in a CL program that is compiled with Use adopted authority set to *NO.
  • Use the QUSEADPAUT authorization list to limit who can create a program that uses the adopted authority from higher in the call stack. (For details on using this authorization list, see the iSeries Security Reference manual.)
  • Ensure every possible user is set to limited capability *YES. For all other users, audit their actions by running the CHGUSRAUD command and specify (at least) to audit their commands (*CMD).
  • Ensure that the program owner has just the special authorities required to run the application and no more. In many cases, application owners tend to have more special authorities than required. For example, I often see applications owned by a profile that has *JOBCTL and *SAVSYS. While *JOBCTL is often required, it is rare that *SAVSYS is.
ABOUT THE AUTHOR: Carol Woodbury is president and co-founder of SkyView Partners Inc., and the former AS/400 security architect and chief engineering manager of security technology for IBM in Rochester, MN.

Editors note: This iSeries administrator's tip on i5/OS security has been adapted from a user question submitted to our Ask The Expert section.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close