*ALLOBJ Authority with a Catch
In last month’s column, I discussed granting programmers *ALLOBJ authority, which can pose a problem in many AS/400 installations. This month, rather than recommend blindly granting programmers *ALLOBJ authority, I provide you with a solution that I have implemented for several customers: the Log Commands (LOGCMD) command. LOGCMD allows programmers to adopt special access such as *ALLOBJ authority but records all commands entered in the audit journal. In this column, I describe the user interface for this function and give you the technical details for its implementation.
As you implement LOGCMD, try to set aside time to learn from this example; it includes several simple techniques you can employ in some of your future programs:
• The authorization list controls which users can access the LOGCMD function.
• Parameters allow customization of the application without changing the program source.
• The command definition uses CONSTANT values to hide these parameters from users.
• APIs swap user profiles rather than change the user profile for a job to activate auditing in the process.
• Display file LOGCMDDSP1 illustrates how a window displays information.
User Interface
As shown in Figure 1, when you first run LOGCMD, you must enter a reason code that describes your intention to use *ALLOBJ support and press Enter for access. A screen like the one shown in Figure 2 then appears, in which you can enter, prompt, and retrieve commands, as on the IBM OS/400 Command Entry screen, and the commands you enter are logged to the audit journal. To minimize the volume of data logged, press F3 to exit after you complete the task at hand. For every 10 commands you enter, a reminder message appears, warning you to exit the program as soon as you complete the job that needs *ALLOBJ authority.
Technical Description
Figure 3 illustrates the flow of the different segments of the LOGCMD program objects. The command definition source (which you can retrieve at www.midrangecomputing. com/mc/) has four parameters that set the scope for *ALLOBJ support. You can change the parameters to constants customized for your installation:
• &HANDLE passes user profile swap handles from program LOGCMD1 to program LOGCMD2. This 12-character field uses Transfer Control (TFRCTL) command, so all parameters passed must be external to LOGCMD1. You should not modify HANDLE.
• &JRNCDE logs reason codes and user requests in the audit journal. If you want
to modify this two-character field for other commands, you first need to change the LOGCMD_RPT selection criteria to match.
• &PGM issues commands. You can change this parameter to specify different programs, but the libraries in which the programs reside must be on the library list.
• &REMIND specifies the number of commands you can enter before the reminder screen appears.
Creating the Application
Here is a step-by-step solution to implement LOGCMD:
1. Create an authorization list that allows you to control which users can access LOGCMD:
CRTAUTL LOGCMD AUT(*EXCLUDE)
You create the authorization list first so you can immediately secure commands and programs as soon as you create them.
2. Customize display file LOG-CMDDSP by adding your com-pany name and information to the source.
3. Create display files LOGCMDDSP and LOGCMDDSP1 in a library that is on the library list during execution and compilation of the CL programs:
CRTDSPF DSPF(your-library/LOGCMDDSP) + AUT(*CHANGE)
CRTDSPF DSPF(your-library/LOGCMDDSP1) +
AUT(*CHANGE)
4. Create program LOGCMD1 to adopt the authority of the program owner:
CRTCLPGM PGM(your-library/LOGCMD1) +
USRPRF(*OWNER) LOG(*NO) +
ALWRTVSRC(*NO)
5. Change the owner of LOGCMD1 to a user profile with *ALLOBJ and *SECADM authority:
CHGOBJOWN OBJ(your-library/LOGCMD1) +
OBJTYPE(*PGM) NEWOWN(QSECOFR)
The owner of LOGCMD1 must have *ALLOBJ and *SECADM authority specified in the user profile so the API can get a profile handle without a password.
6. Create program LOGCMD2 to adopt the authority of the program owner:
CRTCLPGM PGM(your-library/LOGCMD2) +
USRPRF(*OWNER) LOG(*NO) +
ALWRTVSRC(*NO) AUT(LOGCMD)
7. Change the owner of LOGCMD2 to a user profile that you want users of LOGCMD to adopt:
CHGOBJOWN OBJ(your-library/LOGCMD2) +
OBJTYPE(*PGM) NEWOWN(user-profile-to-adopt)
The owner of LOGCMD2 should have the special authority needed for the programmer to access the objects.
8. Create program LOGCMD3 to adopt the authority of a user with *ALLOBJ and *SECADM authority:
CRTCLPGM PGM(your-library/LOGCMD3) LOG(*NO)
ALWRTVSRC(*NO) AUT(*USE)
9. Create the LOGCMD command:
CRTCMD CMD(your-library/LOGCMD) PGM(LOGCMD1)
AUT(LOGCMD)
Figure 4 shows examples of commands logged by this utility.
LOGCMD is a powerful addition to your collection of security tools but must be tailored to your shop’s needs. Pay special attention when setting up your authorization list and don’t forget tocustomize the display files and programs for your operation and test the utility thoroughly before releasing it to production programmers.
Figure 1: Enter a reason for having *ALLOBJ authority on this screen.
LATEST COMMENTS
MC Press Online