Dead-letter queue security

Special considerations apply to the dead-letter queue, because many users must be able to put messages on it, but access to retrieve messages must be tightly restricted. We can achieve this by applying different RACF® authorities to the dead-letter queue and an alias queue.

Undelivered messages can be put on a special queue called the dead-letter queue. If we have sensitive data that could possibly end up on this queue, you must consider the security implications of this because we do not want unauthorized users to retrieve this data.

Each of the following must be allowed to put messages onto the dead-letter queue:

  • Application programs.
  • The channel initiator address space and any MCA user IDs. (If the RESLEVEL profile is not present, or is defined so that channel user IDs are checked, the channel user ID also needs authority to put messages on the dead-letter queue.)
  • CKTI, the IBM MQ -supplied CICS® task initiator.
  • CSQQTRMN, the IBM MQ-supplied IMS trigger monitor.
The only application that can retrieve messages from the dead-letter queue should be a 'special' application that processes these messages. However, a problem arises if you give applications RACF UPDATE authority to the dead-letter queue for MQPUT s because they can then automatically retrieve messages from the queue using MQGET calls. We cannot disable the dead-letter queue for get operations because, if we do, not even the 'special' applications could retrieve the messages.

One solution to this problem is set up a two-level access to the dead-letter queue. CKTI, message channel agent transactions or the channel initiator address space, and 'special' applications have direct access; other applications can only access the dead-letter queue through an alias queue. This alias is defined to allow applications to put messages on the dead-letter queue, but not to get messages from it.

This is how it might work:
  1. Define the real dead-letter queue with attributes PUT(ENABLED) and GET(ENABLED), as shown in the sample thlqual.SCSQPROC(CSQ4INYG).
  2. Give RACF UPDATE authority for the dead-letter queue to the following user IDs:

    • User IDs that the CKTI and the MCAs or channel initiator address space run under.
    • The user IDs associated with the 'special' dead-letter queue processing application.
  3. Define an alias queue that resolves to the real dead-letter queue, but give the alias queue these attributes: PUT(ENABLED) and GET(DISABLED). Give the alias queue a name with the same stem as the dead-letter queue name but append the characters ".PUT" to this stem. For example, if the dead-letter queue name is hlq.DEAD.QUEUE, the alias queue name would be hlq.DEAD.QUEUE.PUT.
  4. To put a message on the dead-letter queue, an application uses the alias queue. This is what our application must do:

    • Retrieve the name of the real dead-letter queue. To do this, it opens the queue manager object using MQOPEN and then issues an MQINQ to get the dead-letter queue name.
    • Build the name of the alias queue by appending the characters '.PUT' to this name, in this case, hlq.DEAD.QUEUE.PUT.
    • Open the alias queue, hlq.DEAD.QUEUE.PUT.
    • Put the message on the real dead-letter queue by issuing an MQPUT against the alias queue.
  5. Give the user ID associated with the application RACF UPDATE authority to the alias, but no access (authority NONE) to the real dead-letter queue. This means that:

    • The application can put messages onto the dead-letter queue using the alias queue.
    • The application cannot get messages from the dead-letter queue using the alias queue because the alias queue is disabled for get operations.

    The application cannot get any messages from the real dead-letter queue either because it does have the correct RACF authority.

Table 1 summarizes the RACF authority required for the various participants in this solution.
Table 1. RACF authority to the dead-letter queue and its alias
Associated user IDs Real dead-letter queue (hlq.DEAD.QUEUE) Alias dead-letter queue (hlq.DEAD.QUEUE.PUT)
MCA or channel initiator address space and CKTI UPDATE NONE
'Special' application (for dead-letter queue processing) UPDATE NONE
User-written application user IDs NONE UPDATE

If we use this method, the application cannot determine the maximum message length (MAXMSGL) of the dead-letter queue. This is because the MAXMSGL attribute cannot be retrieved from an alias queue. Therefore, our application should assume that the maximum message length is 100 MB, the maximum size IBM MQ for z/OS® supports. The real dead-letter queue should also be defined with a MAXMSGL attribute of 100 MB.

Note: User-written application programs do not normally use alternate user authority to put messages on the dead-letter queue. This reduces the number of user IDs that have access to the dead-letter queue.