September 12, 2012 - Vol 2, Issue 16
Live Online Training from The 400 School
Monitor File Integrity - Powertech





Is Your JD EDWARDS Database Secure? See how SKYVIEW PARTNERS can help!






Watch out for NEW Adopting Objects

By Dan Riehl

Adoption of authority is a technology we commonly use within IBM i to allow users to perform operations for which they do not have sufficient authority. For example, resetting a user's password requires a very high level of authority. We do not want to hand out this high authority level to every user that may need to reset a password. So, instead of making the users more powerful, we make a program that is more powerful by allowing the program to adopt, or "temporarily borrow", the authority of a powerful user.

When a program is created, the USRPRF parameter is used to specify that the created program will adopt authority. In the command CRTCLPGM(Create Control Language Program) you specify adopted authority by specifying the parameter USRPRF(*OWNER). Then, when the program is run, the program adopts the authority of the owner of the program, thus enabling the CL program to perform operations that the owner of the program is authorized to do, but the user running the program does not necessarily have the ability to do; like resetting a password, or restoring a library.

Since running a program that adopts authority can increase a user's capability, it is important to make sure that you know which programs adopt authority, and that you especially keep an eye on newly created programs that adopt.

In many cases, programs will adopt the authority of QSECOFR, or of some other very powerful profile. This is seen most often in vendor supplied software, but typically there will be several home-grown programs on your system that will adopt the authority of QSECOFR. You need to know what these home grown programs do, and why they adopt such a high level of authority. These adopting programs can be used as a "back-door" to to circumvent the security controls and file permissions that you have instituted to protect your system.

In order for you to keep track of adopting programs, IBM has supplied the command PRTADPOBJ(Print Adopting Objects). Adoption can occur within a program, a service program, or an SQL package.

When using the command PRTADPOBJ you print a list of adopting programs, and can select to only print the programs that adopt a specified user profile, like QSECOFR. You can also specify to print a list of programs that adopt the authority of any user profile.

The command also has a 'What's Changed?" feature, in which you can print only changes since the last run of the command.

PRTADPOBJ USRPRF(QSECOFR) CHGRPTONLY(*NO or *YES)

When you run the command the first time, the system prints a report of all objects that adopt the authority of the specified user, and also stores the history of the run in the file QSECADPOLD in library QUSRSYS. For the command used above, the system will add the member QSECOFR to the file, and place a record in the member for each program that adopts the QSECOFR user profile.

If you select to run the report to list objects that adopt any user profile(i.e. USRPRF(*ALL)), a member is added to the file for every user, and for those users that own adopting objects, the system will add a record for each adopting object.

The QSECADPOLD file contains the snapshot of adopting objects the last time the command was run for that user. Each member contains the last run date, so the last run date for QSECOFR, may be different than the last run date for QUSER. If you specify USRPRF(*ALL), the dates will be consistent within the various file members.

The PRTADPOBJ report shows any special authorities held by the adopted user profile. In addition, it contains a list of all adopting objects, with the authority information for the object and for the library in which the object resides. The report also tells you if any private authorities exist for the adopting object, here is a snippet from the report.


               Adopting Objects by User Profile (Full Report)                  Page   1  
5761SS1 V6R1M0  080215                                 MYSYSTEM  02/11/10  21:29:47 CST 
User profile . . . . . . . . . :   QSECOFR                                     
Special authorities  . . . . . :   *ALLOBJ     *AUDIT      *IOSYSCFG   *JOBCTL     
                                   *SAVSYS     *SECADM     *SERVICE    *SPLCTL    
-------------Object---------------     --------------Library--------------   
                          Public                    ASP           Public        Private  
Name         Type        Authority     Name         Device       Authority    Authorities  
QINSTAPP     *PGM        *EXCLUDE      I0410YSF     *SYSBAS      *USE              N    
QANZUSRP     *PGM        *USE          QIWS         *SYSBAS      *USE              N    
QHIX12I1     *PGM        *EXCLUDE      QIWS         *SYSBAS      *USE              N    
QHWSPLST     *PGM        *USE          QIWS         *SYSBAS      *USE              N    
QHWVFYNM     *PGM        *USE          QIWS         *SYSBAS      *USE              N

I recommend you run the command once for *ALL users, and save the report as your baseline. Then each week, run the "What's Changed?" report only. In order to use the command, you must have *ALLOBJ or *AUDIT special authority.

For those of you that might want to write your own queries or programs to process the QSECADPOLD history file, IBM provides the field definitions in the model file QADPGMAD in library QSYS. The record format name used is QSYPGMAD.



About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group, LLC.

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn





 
Training from The 400 School