Security considerations for the channel initiator on z/OS

If we are using resource security in a distributed queuing environment, the Channel initiator address space needs appropriate access to various IBM MQ resources. We can use the Integrated Cryptographic Support Facility (ICSF) to seed the password protection algorithm.


Use resource security

If we are using resource security, consider the following points if we are using distributed queuing:

    System queues
    The channel initiator address space needs RACF UPDATE access to the system queues listed at System queue security, and to all the user destination queues and the dead-letter queue (but see Dead-letter queue security ).

    Transmission queues
    The channel initiator address space needs ALTER access to all the user transmission queues.

    Context security
    The channel user ID (and the MCA user ID if one has been specified) need RACF CONTROL access to the hlq.CONTEXT.queuename profiles in the MQADMIN class. Depending on the RESLEVEL profile, the channel user ID might also need CONTROL access to these profiles.

    All channels need CONTROL access to the MQADMIN hlq.CONTEXT. dead-letter-queue profile. All channels (whether initiating or responding) can generate reports, and consequently they need CONTROL access to the hlq.CONTEXT.reply-q profile.

    SENDER, CLUSSDR, and SERVER channels need CONTROL access to the hlq.CONTEXT.xmit-queue-name profiles since messages can be put onto the transmission queue to wake up the channel to end gracefully.

    Note: If the channel user ID, or a RACF group to which the channel user ID is connected, has CONTROL or ALTER access to the hlq.RESLEVEL, then there are no resource checks for the channel initiator or any of its channels.

    See Profiles for context security RESLEVEL and the channel initiator connection and User IDs for security checking on z/OS for more information.

    CSQINPX
    If we are using the CSQINPX input data set, the channel initiator also needs READ access to CSQINPX, and UPDATE access to data set CSQOUTX and dynamic queues SYSTEM.CSQXCMD.*.

    Connection security
    The channel initiator address space connection requests use a connection type of CHIN, for which appropriate access security must be set, see Connection security profiles for the channel initiator.

    Data sets
    The channel initiator address space needs appropriate access to queue manager data sets, see Authorizing access to data sets.

    Commands
    The distributed queuing commands (for example, DEFINE CHANNEL, START CHINIT, START LISTENER, and other channel commands) must have appropriate command security set, see Table 1.

    If we are using a queue sharing group, the channel initiator might issue various commands internally, so the user ID it uses must be authorized to issue such commands. These commands are START and STOP CHANNEL for every channel used with CHLDISP(SHARED).

    If the PSMODE of the queue manager is not DISABLED, the channel initiator must have READ access to the DISPLAY PUBSUB command.

    Channel security
    Channels, particularly receivers and server-connections, need appropriate security to be set up; see User IDs for security checking on z/OS for more information.

    We can also use the Transport Layer Security (TLS) protocol to provide security on channels. See TLS security protocols in IBM MQ for more information about using TLS with IBM MQ.

    See also Access control for clients for information about server-connection security.

    User IDs
    The user IDs described in User IDs used by the channel initiator and User IDs used by the intra-group queuing agent need the following access:

    • RACF UPDATE access to the appropriate destination queues and the dead-letter queue
    • RACF CONTROL access to the hlq.CONTEXT.queuename profile if context checking is performed at the receiver
    • Appropriate access to the hlq.ALTERNATE.USER.userid profiles they might need to use.
    • For clients, the appropriate RACF access to the resources to be used.

    APPC security
    Set appropriate APPC security if we are using the LU 6.2 transmission protocol. (Use the APPCLU RACF class for example.) For information about setting up security for APPC, see the following manuals:

    • z/OS V1R2.0 MVS Planning: APPC Management
    • Multiplatform APPC Configuration Guide, an IBM Redbooks publication

    Outbound transmissions use the SECURITY(SAME) APPC option. As a result, the user ID of the channel initiator address space and its default profile ( RACF GROUP) are flowed across the network to the receiver with an indicator that the user ID has already been verified (ALREADYV).

    If the receiving side is also z/OS, the user ID and profile are verified by APPC and the user ID is presented to the receiver channel and used as the channel user ID.

    In an environment where the queue manager is using APPC to communicate with another queue manager on the same or another z/OS system, we need to ensure that either:

    • The VTAM definition for the communicating LU specifies SETACPT(ALREADYV)
    • There is a RACF APPCLU profile for the connection between LUs that specifies CONVSEC(ALREADYV)

    Change security settings
    If the RACF access level that either the channel user ID or MCA user ID has to a destination queue is changed, this change takes effect only for new object handles (that is, new MQOPEN s) for the destination queue. The times when MCAs open and close queues is variable; if a channel is already running when such an access change is made, the MCA can continue to put messages on the destination queue using the existing security access of the user IDs rather than the updated security access. Stopping and restarting the channels to enforce the updated access level avoids this scenario.

    Automatic restart
    If we are using the z/OS Automatic Restart Manager (ARM) to restart the channel initiator, the user ID associated with the XCFAS address space must be authorized to issue the IBM MQ START CHINIT command.


Use the Integrated Cryptographic Service Facility (ICSF)

The channel initiator can use ICSF to generate a random number when seeding the password protection algorithm to obfuscate passwords flowing over client channels if TLS is not being used. The process of generating a random number is called entropy.

If we have the z/OS feature installed but have not started ICSF, you see message CSQX213E and the channel initiator uses STCK for entropy.

Message CSQX213E warns you that the password protection algorithm is not as secure as it could be. However, we can continue your process; there is no other impact on runtime.

If we do not have the z/OS feature installed, the channel initiator automatically uses STCK.

Notes:
  1. Use ICSF for entropy generates more random sequences than using STCK.
  2. If you start ICSF we must restart the channel initiator.
  3. ICSF is required for certain CipherSpecs. If you attempt to use one of these CipherSpecs and you do not have ICSF installed, you receive message CSQX629E.

Parent topic: Set up security on z/OS