Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see DASD MANAGER PLUS for DB2 13.1.

Security exits


The DASD MANAGER PLUS user exits allow the following security:

  • The front end security exit limits access to actions.
  • The Execution Security Exit provides security checking during installation and enforces options.

Important

We recommend using the OSAUTHCHK option in the installation options module to control access to DASD MANAGER PLUS objects instead of using a security exit. For more information about the OSAUTHCHK option, see Controlling-access-to-Object-Sets.

Front end security exit

The front end security exit, ASUFUSX1, provides a way to inspect and control the actions to which a TSO logon ID can refer.

When an ID refers to an action and ASUFUSX1 is active, control passes to ASUFUSX1 with the data that is necessary to determine whether the ID can use the action.

Make your changes to the source for this exit, which is distributed in member ASUFUSX1 of the CNTL library. Then, assemble and link ASUFUSX1 to enable the security exit. The product loads the ASUFUSX1 module during initialization.

Important

In migrating from using work IDs to actions, DASD MANAGER PLUS has increased the length of a work ID from eight characters to 20. DASD MANAGER PLUS automatically uses the first eight characters from the work ID name. However, if you use action names that are greater than eight characters and also use the ASUFUSX1 exit, you must update the exit to check the new 20-character length field.

ASUFUSX1 communicates through Registers 0, 1, and 15. When the product calls ASUFUSX1, Register 0 contains a function code and Register 1 contains the address of a user exit control block that is described by the FXBLOCK DSECT that the sample program contains. ASUFUSX1 returns a value in Register 15 that informs the front end how to proceed.

FXBLOCK defines the front end exit parameters and work areas that are available to the exit. A field is available for an address of a user area to be retained across invocations. This area is locally acquired storage. FXBLOCK also provides a message text area. The user exit can insert message text in this message area for display on return.

R0 function codes and return codes

DASD MANAGER PLUS provides the following R0 function codes and appropriate return codes:

  • X'01' is the initialization call. This call occurs during front end initialization, before any action retrieval. The R15 return codes are as follows:

    Return code

    Explanation

    0

    Setup is complete.

    4

    Do not use the exit. Anything else terminates DASD MANAGER PLUS.

  • X'02' is the call to process an ID. The product makes this call when it is using an action. The R15 return codes are as follows:

    Return code

    Explanation

    0

    Allow the use of this action.

    4

    Do not allow the use of the action. Anything else terminates DASD MANAGER PLUS.

    Important

    For an action list, the product invokes the exit for each action in the list.

  • X'03' is the termination or cleanup call. The product makes this call just before termination of the front end and allows you to perform any necessary cleanup functions. The product ignores R15 return codes.

Important

At installation, the front end has a dummy exit routine. This dummy exit should remain available if you do not intend to use the exit. If you remove the dummy exit and you do not supply a replacement, the front end will not execute.

Authorization switching

The Execution component performs an authorization switching function to ensure that Db2 structures are created with the proper owner and creator.

To secure this function, you can perform one of the following activities:

  • Restrict the EXECUTE authority on the Execution Monitor Entry plan. This restriction will prevent unauthorized users from being able to run Execution. For the highest level of security, restrict access to the Execution Monitor Entry plan.
  • Create an Execution security exit to add site-specific restrictions to authorization switching.

Execution calls the security exit at various points to allow installation security checking and option enforcement.

Typical uses of this exit include:

  • Enforcing hash checking so that users are not allowed to modify worklists
  • Switching the authorization ID of the execution run user at initialization
  • Preventing or restricting user authorization ID switching
  • Preventing user modification of SQL GRANT commands
  • Inspecting and modifying SQL commands before they are executed

The assembler source for the security exit is distributed in the DBSAMP library (member ALUEUSX1). To enable the security exit, modify ALUEUSX1, then assemble and link the member. This module is loaded during initialization.

ALUEUSX1 communicates via Registers 0, 1, and 15. When ALUEUSX1 is called, Register 0 contains a function code. Register 1 contains the address of a user exit control block that AEXUSERX DSECT (in the sample program) describes. ALUEUSX1 returns a value in Register 15 that informs Execution how to proceed.

For more information about switching authorization, seeALTER and CHANGE MANAGER for DB2.

Execution security exit function codes

The following table lists and describes the Register 0 function codes.

The sample exit includes detailed documentation about register usage, DSECT mapping, and call conventions. For a list of return codes, seeMessages Library.

Execution security exit function codes

Code

Call

Occurs

Notes

X'01'

Initialization

During Execution initialization

At this point, you can inspect the user ID that is running the job, change it if necessary, or halt processing. You can also enable hash checking to prevent a user from making any modifications to a worklist (other than deleting entire commands) throughout the execution run.

If you need storage for local routines, you should perform a GETMAIN at this time. Store the address in the user exit control block AEXUSERX, as described in the code sample.

X'02'

-AUTH command switch

Immediately before an authorization ID switch

The authorization ID might be inspected or changed, or processing might be halted. If the AEXEFAUH bit of flag ASXEFLAG in the user exit DSECT is set, hash checking has failed on the current -AUTH command.

If the return code from this exit is an odd number (that is, the low order 1 bit is set), the command that executed under the switch is verified to ensure that the hash code is correct. This verification prevents you from changing commands that are executed under a switch. If this bit is off (return code 0 or 4), hash checking is done as specified for the main run. If this bit is on (return code 1 or 5), then hash checking is forced for the duration of the switch. In this case, Execution halts when it encounters a modified or new statement in the worklist.

If the return code low order 2 bit is on, the command that is executed under the switch is allowed to fail hash checking provided that the next command is not an SQL GRANT. This restriction means that you can modify the worklist as needed but cannot modify any GRANT statements.

The low order 2 bit in the return code indicates whether to enforce hash failures when an SQL GRANT command is processed. Hash checking is enforced for the duration of the switch. In this case, Execution halts when it encounters a modified or new SQL GRANT statement in the worklist.

X'03'

termination/cleanup

Immediately before termination

The call enables you to perform any necessary cleanup functions. For example, if you used another security product to perform security validations, you might want to sign off. Remember to perform a FREEMAIN to free any storage that you allocated. Return codes are ignored.

X'04'

SQL inspection

Immediately before invoking dynamic SQL

The call enables you to inspect the SQL command that is about to be executed. You can use the command as it is, replace it with another command, or stop processing.

If the AEXEFAUH bit of flag ASXEFLAG in the user exit DSECT is set, hash checking has failed on the -SQL command.

The SQL call passes the address of the SQL statement in field ASXSQL. This address points to a field of the format hhx...x, where hh is a halfword length field, and x...x is the SQL statement about to be executed. This field is passed to DB2 for execution. An SQL failure halts Execution.

X'05'

-SETS command inspection

Immediately before executing a -SETS (SET CURRENT SQLID) worklist command

You can inspect, change, or deny the SQLID that is about to be switched.

If the AEXEFAUH bit of flag ASXEFLAG in the user exit DSECT is set, hash checking has failed on the -AUTH command.

This call does not affect hash checking because the SET CURRENT SQLID mechanism is inherently secured by the Db2 system itself. The primary purpose of this call is to allow the use of special SQLIDs that are not the creator or owner of Db2 objects that are being created in the worklist.

X'06'

-GLID command inspection

Immediately before executing a -GLID (set global authorization ID) worklist command

You can inspect, change, or deny the global authorization ID (GLID) that is about to be switched. In addition, you can activate hash checking and other options on this exit call.

If the AEXEFAUH bit of flag ASXEFLAG in the user exit DSECT is set, hash checking has failed on the -AUTH command.

Execution security exit testing

Before you enable your security exit, you should test the exit.

Following are some suggestions to help you develop and test your security exit:

  • Test the exit initially with simple logic and test cases to verify that you are correctly processing the function codes and return codes.
  • Add the DEBUG keyword to the AEXIN parameter input.

    Message BMC16990I is issued to AEXPRINT and includes the following information:

    • Function code with which the exit is called
    • WORKID or SQLID that is about to be switched
    • USERID that is associated with the job itself
    • Return code (Register 15) that is returned from the exit
    • WORKID or SQLID that is returned from the exit

Contact BMC Customer Support if you have questions about the Execution security exit.

Switching authorization with 8-byte IDs

The -AUTH command that is generated in the worklist cannot switch to 8-byte authorization IDs.

Because the -AUTH command simulates the user ID environment that is inherent to MVS, and MVS itself is limited to seven characters for user IDs, the authorization ID must be seven characters or less.

If your Db2 environment has committed to the use of SET CURRENT SQLID, the best way to ensure that 8-byte IDs are correctly used is to change the installation option for AUTHSW from Y to N. This change generates -SETS commands in the worklist instead of -AUTH commands. Using -SETS commands exploits Db2’s built-in switching mechanism and is not limited to 7-byte IDs.

If using -SETS commands is not suitable for your environment, you can switch -AUTH commands to 8-byte IDs through the Execution security exit. This exit has many possible uses, including the ability to examine and optionally change the authorization ID that the -AUTH command uses. Through this exit you can cause an 8-byte ID to switch to a corresponding 7-byte (or shorter) ID, which causes a switch in the DB2 DSN3@TH exit that is already installed. In the CNTL data set, member ALUEUSX1 provides an example of the Execution security exit.

Related topic

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*