MQ

Morag Hughson IBM Champion posted Tue February 18, 2025 09:39 PM

Hi Michael,

What you describe does make it sound like the PUTAUT(CTX) setting has not been picked up by the channel. I am curious about the part of your script that does:-

STOP CHANNEL(SENDER3.TO.RECEIVER2)
START CHANNEL(SENDER3.TO.RECEIVER2)

I assume that perhaps you have a script that you have been gradually developing and that is why you have this - to stop the previously running channel and then restart it to allow it to get the new definition. I wonder if this might mean that the PUTAUT(CTX) setting has not been picked up because perhaps, because these two commands are so close together, that the channel might not have actually been stopped. 

If you issue a start channel too rapidly after a stop channel, if the channel has not yet stopped, it will just cancel the stop. This of course, is not what you want in your case.

Can I get you to try to manually stop the channel, and use channel status to make sure it has really stopped - i.e. no longer running at either end, and then start it up again and see if it still shows the same behaviour.

Cheers,
Morag

bruce2359 posted Wed February 19, 2025 10:45 AM

At the sender side qmgr, access to the transmission queue is through the QRemote definition.

Are you running your test (with the WebUI) as administrator?  If so, your admin userid has all admin authority to all local objects on the sender side qmgr - specifically the QREMOTE(SENDER.QUEUE) definition.  Try running a test with a non-admin userid.  Post your results here.

 “…message "lands" on `RECEIVER1.QUEUE` (Q2) with User ID set to unknown …”.  Please be precise. What do you mean by ‘unknown’?  Use amqsbcg or some other utility to post here the MQMD of the message. 

YVES MOYROUD posted Thu February 20, 2025 03:13 AM

Hi Michal,
if you are on Linux or AIX, have SecurityPolicy=group, and if users qm1 and qm3 belong to the same primary group, then they share their authorities.
You might check with amqoamd or similar :
```
# authorities on RECEIVER1.QUEUE for all entities
amqoamd -m Q2 -n RECEIVER1.QUEUE -t queue
```

Neil Casey posted Thu February 20, 2025 04:52 PM

Hi Michal,

If you are trying to establish an effective solution to limiting access across a receiver channel, PUTAUT(CTX) is not secure in the general case. Anyone with sufficient access to the sender queue manager is able to override the UserIdentifier on the message as it's just part of context. They can then use that ability to attack your queue manager (for example by asserting mqm as their UserIdentifier on a Linux system).

A more secure technique is to secure the channel using PUTAUT(DEF) and ensure that the channel is dedicated to the sending queue manager and is authenticated securely (for example with mutual TLS). Access to queue on the receiver end is then granted to the MCAUSER on the channel (which has to be set to a user with low privileges, not 'mqm' or blank.

You've done all of these things from the channel perspective, but because you set PUTAUT(CTX) instead of PUTAUT(DEF) the security check for opening the queue for output on the receiver queue manager is NOT 'qm3'. It's whatever user was active (or asserted by the program if authorized) on the sending queue manager, as received by the receiving queue manager in the UserIdentifier field in the message context.

Although it is based on MQ 7.5 and so is now sadly out of date, the Redbook Secure Messaging Scenarios with WebSphere MQ (https://www.redbooks.ibm.com/abstracts/sg248069.html) describes the security exposure associated with PUTAUT(CTX) which still exists.

Regards,

Neil Casey

bruce2359 posted Thu February 20, 2025 07:50 PM

I'm a bit confused, Michal.  You say that the WebUI successfully created a message, that the message was forwarded from the originating qmgr across the SDR-RCVR channel, and that the message arrived in the named destination queue.  What results were you expecting?  Did you expect the WebUI would get a failed completion code or a not-authorized reason code?  Were you expecting something else?  Is your only complaint here that the message User ID set to unknown?