Q: I used the technique described in Security Patrol, MC, December 1994 to prevent the use of the Query/400 OUTFILE parameter to modify production files. The interactive queries now run with the group profile GRP_QRY.
This works fine, but my users submit queries to batch and I do not want them to update production files. Is there a way that I can cause the submitted queries to run using the group profile GRP_QRY? I cannot leave individual user profiles with the group profile GRP_QRY because the users must have the production profile for their interactive jobs and jobs submitted from application menus.
A: You can add a validity checking program (VCP) to the RUNQRY command that will change the group profile (see "Modifying OS/400 Commands," MC, October 1994, for details about VCPs).
Using the dump program from that article, I discovered that the Run Query (RUNQRY) command passes 14 parameters to the VCP. 1 shows the VCP that I wrote. VCP_RUNQRY changes the group profile to GRP_QRY using the Set Group Profile (SETGRPPRF) command from "Dynamic Change of Group Profile," MC, May 1994.
Using the dump program from that article, I discovered that the Run Query (RUNQRY) command passes 14 parameters to the VCP. Figure 1 shows the VCP that I wrote. VCP_RUNQRY changes the group profile to GRP_QRY using the Set Group Profile (SETGRPPRF) command from "Dynamic Change of Group Profile," MC, May 1994.
The final step is to change the RUNQRY command to use the new VCP. Make a copy of RUNQRY into a system library that's above QSYS and change it with the following command:
CHGCMD CMD(xxx/RUNQRY) + VLDCKR(VCP_RUNQRY)
There are some additional considerations. VCP_RUNQRY assumes that all users will have their profile changed. You may need to add logic to bypass the change for some users. Should the RUNQRY command be issued by an interactive user, you will need to have the menu option that executes the RUNQRY command set the group profile back to the default. You can accomplish this by using the *RESET option in the enhanced version of SETGRPPRF, published in Security Patrol, MC, December 1994.
The technique illustrated for the RUNQRY command could be extended to almost any other command.
Figure 1: VCP_RUNQRY Program /*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/VCP_RUNQRY) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ PGM PARM(&P1 &P2 &P3 &P4 &P5 &P6 &P7 &P8 &P9 &P10 &P11 &P12 + &P13 &P14) DCL VAR(&P1) TYPE(*CHAR) LEN(1) DCL VAR(&P2) TYPE(*CHAR) LEN(1) DCL VAR(&P3) TYPE(*CHAR) LEN(1) DCL VAR(&P4) TYPE(*CHAR) LEN(1) DCL VAR(&P5) TYPE(*CHAR) LEN(1) DCL VAR(&P6) TYPE(*CHAR) LEN(1) DCL VAR(&P7) TYPE(*CHAR) LEN(1) DCL VAR(&P8) TYPE(*CHAR) LEN(1) DCL VAR(&P9) TYPE(*CHAR) LEN(1) DCL VAR(&P10) TYPE(*CHAR) LEN(1) DCL VAR(&P11) TYPE(*CHAR) LEN(1) DCL VAR(&P12) TYPE(*CHAR) LEN(1) DCL VAR(&P13) TYPE(*CHAR) LEN(1) DCL VAR(&P14) TYPE(*CHAR) LEN(1) /* Set group profile to GRP_QRY */ SETGRPPRF GRPPRF(GRP_QRY) ENDPGM
Q: I turned on auditing to determine what programs would encounter domain failures as a prelude to changing from security level 30 to 40. When I dumped the audit journal and wrote a query to view the output, I came up with 329,359 domain failures by 156 programs in one day. That is a lot more than I expected.
I checked the object authority on several of the programs that had a lot of entries and found all of the programs have at least *PUBLIC authority of *USE. At this point I am not sure why the programs are creating AF entries in the audit journal. I would appreciate any help you can give me in understanding what the problem is.
A:When auditing is active and you set the system value QAUDLVL to *PGMFAIL, authority failure (AF) entries are written to the audit journal for several reasons. The logged events can be for conditions other than a user not being authorized to an object. The events are distinguished by a one-character, violation-type field in the audit record as shown in 2.
A:When auditing is active and you set the system value QAUDLVL to *PGMFAIL, authority failure (AF) entries are written to the audit journal for several reasons. The logged events can be for conditions other than a user not being authorized to an object. The events are distinguished by a one-character, violation-type field in the audit record as shown in Figure 2.
You can view the audit journal data using the command:
DSPJRN JRN(QAUDJRN)
The violation type is the first character in the display of the entry-specific data. 3 is sample output from the DSPJRN command. The D in position 1 (violation type) designates the entry as a domain violation.
The violation type is the first character in the display of the entry-specific data. Figure 3 is sample output from the DSPJRN command. The D in position 1 (violation type) designates the entry as a domain violation.
An alternative to using DSPJRN to view the audit information is the QUSRTOOL command Display Audit Log (DSPAUDLOG). The DSPAUDLOG command retrieves data from the audit journal and merges it with message text to produce a more readable presentation of the audit journal data. 4 shows the output from DSPAUDLOG.
An alternative to using DSPJRN to view the audit information is the QUSRTOOL command Display Audit Log (DSPAUDLOG). The DSPAUDLOG command retrieves data from the audit journal and merges it with message text to produce a more readable presentation of the audit journal data. Figure 4 shows the output from DSPAUDLOG.
One potential source of domain failure is programs that attempt to access system objects directly. These types of domain failures are frequently found in third party application packages that have machine interface (MI) programs, which is a language for use by IBM developers. Most installations do not write programs in MI and therefore do not directly access system objects.
There is one practice that should be avoided. Installation-written command definitions should not attempt to invoke the IBM-supplied command processing programs (CPP). The IBM CPPs are in the system domain and attempts to reference them in a user-defined command cause domain failures.
Security Patrol: Security Questions & Answers
Figure 1 VCP_RUNQRY Program
/*===============================================================*/ /* To compile: */ /* */ /* CRTCLPGM PGM(XXX/VCP_RUNQRY) SRCFILE(XXX/QCLSRC) */ /* */ /*===============================================================*/ PGM PARM(&P1 &P2 &P3 &P4 &P5 &P6 &P7 &P8 &P9 &P10 &P11 &P12 + &P13 &P14) DCL VAR(&P1) TYPE(*CHAR) LEN(1) DCL VAR(&P2) TYPE(*CHAR) LEN(1) DCL VAR(&P3) TYPE(*CHAR) LEN(1) DCL VAR(&P4) TYPE(*CHAR) LEN(1) DCL VAR(&P5) TYPE(*CHAR) LEN(1) DCL VAR(&P6) TYPE(*CHAR) LEN(1) DCL VAR(&P7) TYPE(*CHAR) LEN(1) DCL VAR(&P8) TYPE(*CHAR) LEN(1) DCL VAR(&P9) TYPE(*CHAR) LEN(1) DCL VAR(&P10) TYPE(*CHAR) LEN(1) DCL VAR(&P11) TYPE(*CHAR) LEN(1) DCL VAR(&P12) TYPE(*CHAR) LEN(1) DCL VAR(&P13) TYPE(*CHAR) LEN(1) DCL VAR(&P14) TYPE(*CHAR) LEN(1) /* Set group profile to GRP_QRY */ SETGRPPRF GRPPRF(GRP_QRY) ENDPGM
Security Patrol: Security Questions & Answers
Figure 2 Violation Types
Violation Type Description B Restriction (blocked) instruction violation C Object validation failure D Unsupported interface (domain) violation J Job-description and user-profile authorization failure R Attempt to access protected area of disk S Default sign-on attempt
Security Patrol: Security Questions & Answers
Figure 3 Display from DSPJRN QAUDJRN
UNABLE TO REPRODUCE GRAPHICS
Security Patrol: Security Questions & Answers
Figure 4 DSPAUDLOG Output
12/05/94 9:54:30 MCPGMR Display Audit Log Output Page 1 OPTION - *CURRENT OUTTYP - *SECLVL Start date - *FIRST End date - *LAST ENTTYP - *ALL Date Time Type Msg ID Message text 11/19/94 6:09 AF CPI2247 Domain violation by program QCACALL for object QCACALL. Cause . . . . . : Program QCACALL in library QSYS at instruction 0000295 fa iled to access object QCACALL type *PGM in library QSYS because of an object domain violation. User WOE was running program QCACALL in library QSYS. The following information applies to the domain violation: -- Name of job: 030836/WOE/RMTDSP03 -- Time and date: 06:09:42 on 11/19/94 -- Program name: If program name is one of the following, the failure was caused by a CALL or user defined command. - QCACALL -- direct call to system program - QCLCLCPR -- compiled call to system program in CL Program - QCATRS -- user command to system provided command processing program -- Journal entry code: T -- Journal entry type: AF
LATEST COMMENTS
MC Press Online