Security never sleeps. On IBM i, we understand that we must continue to invest in delivering improved security auditing, security deployment and granularity of security controls.
To that end, this post provides a brief recap of security enhancements that have been delivered to existing IBM i releases over that last 12 months (2011 into 2012).
Command Language Enhancements
CL retrieve exit programs can run after command completion
The IBM i operating system supports two exit points for control language (CL) commands:
QIBM_QCA_CHG_COMMAND and QIBM_QCA_RTV_COMMAND. For each regular CL command, and proxy CL commands in the QSYS library, one exit program can be registered for the CHG exit point and up to ten exit programs can be registered for the RTV exit point.
Prior to this enhancement, QIBM_QCA_RTV_COMMAND exit programs were always called just before control was transferred to the command processing program (CPP) associated with the command being run. The enhancement allows you to be able to register an exit program for the QIBM_QCA_RTV_COMMAND exit point and indicate that you want the exit program to be called after control returns from the CPP.
Delivered on: V5R4 (SI45987), IBM i 6.1 (SI45986) and IBM i 7.1 (SI45985)
Extend CD (Command String) journal entries
The IBM i operating system allows customers to track the CL commands that are being run by a user. Auditing needs to be active before command-level auditing can be done. The Change Security Auditing (CHGSECAUD) command allows you to change the current settings for the system values that control what is being audited on the system. To turn on command-level auditing for a user profile, run the Change User Audit (CHGUSRAUD) command specifying the user profile name for the USRPRF parameter and *CMD for the AUDLVL parameter. This will cause CD (Command String) audit records to be generated for each CL command run by the specified user profile. The model file QASYCDJ5 describes the fields in CD audit records. One of these fields, CDCLP, has been redefined to convey more information concerning how the audited CL command was run.
The new values for the CDCLP field map to the values for the ALLOW (where allowed to run) parameter on the Create Command (CRTCMD) command as follows:
‘Y’ maps to *IPGM, *BPGM, *IMOD, *BMOD
‘R’ maps to *IREXX, *BREXX
‘E’ maps to *EXEC
‘B’ maps to *BATCH
‘N’ maps to *INTERACT
Delivered on: V5R4 (SI44854), IBM i 6.1 (SI44864) and IBM i 7.1 (SI44865)
Db2 for IBM i (database) Enhancements
Masking support in FIELDPROCs
The FIELDPROC support has been extended to allow masking to occur to that same column data (typically based on what user is accessing the data). For example, only users that have a need to see the actual credit card number will see the value while other users may just see masked data. For example, XXXX XXXX XXXX 1234.
Delivered on: IBM i 7.1 (DB2 PTF Group SF99701 Level 14)
STRDBMON pre-filtering of QUERY-400 command use
QUERY/400 commands Run Query (RUNQRY), Work With Queries (WRKQRY) and Start Query (STRQRY) already generate database monitor records. This enhancement delivers a method to easily identify Query/400 users and the queries executed via the Filter by Client Program database monitor pre-filter.
Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 14)
Simplified DDM and DRDA authentication entry management using group profiles
This enhancement allows DDM and DRDA to take advantage of a common userid and password defined in a server authentication entry under a group profile name or supplemental group profile name. The group profile name or supplemental group profile name is specified on the USRPRF parameter of the ADDSVRAUTE command.
Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 14)
Add QIBM_DB_ZDA and QIBM_DB_DDMDRDA function usage IDs
These function usage IDs block database server inbound connections and are not based on the communication protocol. The function usage IDs ship with default authority = *ALLOWED. The security officer can easily deny access to specific users or groups.
Alternative to a User Exit Program approach. No coding required, easy to change and auditable.
- QIBM_DB_ZDA (restrict ODBC and JDBC Toolbox from the server side, including Run SQL Scripts, System i Navigator and DB2 specific portions of Systems Director Navigator for i)
- QIBM_DB_DDMDRDA (ability to lock down DDM and DRDA application server access)
Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 13)
QIBM_DB_OPEN exit program object auditing control
The QIBM_DB_OPEN exit program has been enhanced to allow users to control which files will cause the exit program to be called, which can significantly reduce the overhead of using the exit. The open exit will be called for ALL files that are specified in a query or open if ANY of the files have specified object auditing.
Delivered on: V5R4 (DB2 PTF Group SF99504 Level 33), IBM i 6.1 (DB2 PTF Group SF99601 Level 23) and IBM i 7.1 (DB2 PTF Group SF99701 Level 12)
Add QDDMDRDASERVER server authentication entry special value
A special value QDDMDRDASERVER has been added to the ADDSVRAUTE command SERVER parameter for DDM & DRDA connections. This special value allows an administrator to configure a user to work with all possible DDM or DRDA connections to any system in the TCP/IP network via a common userid and password. Once configured for a specific user, no additional changes need to be made for that user as systems are added to the Relational Database Directory.
Delivered on: V5R4 (DB2 PTF Group SF99504 Level 32), IBM i 6.1 (DB2 PTF Group SF99601 Level 21) and IBM i 7.1 (DB2 PTF Group SF99701 Level 11)
Query Manager profile auditing
Changes made to a Query Manager profile can now be audited if auditing is enabled for AUDLVL(*SECURITY).
- A new journal entry type of X2 will contain the old and new Query Manager profile values.
- An outfile is not provided for this journal entry. Instead view QSYS2.SQLQMProfilesAudit can be queried.
Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 21) and IBM i 7.1 (DB2 PTF Group SF99701 Level 10)
This week’s blog was written by Scott Forstie, senior software engineer at IBM. He is the Db2 for i Business Architect, SQL development leader and IBM i developerWorks content manager. Thanks Scott!
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.