MQ remote command execution 9.2.1.0

[JakeReise]

Using MQ version 9.2.1.0 we have removed the use of local user IDs and now are using TLS mapping inside MQ to map connections to non-existent users that we run auth commands against. This is working as expected. The issue/concern comes from running an oc exec command to do the runmqsc command i.e. display a queue manager. In this case MQ is seeing that execution as someone coming in as the same user that is on the channel, but in the oc exec it should be executing locally as the random user id. In fact when running oc exec whoami I get the random user id. So I need to understand how someone could use the oc exec command to circumvent the SSLPEERMAP to a user id that doesnt exit. I can provide logs or answer any questions you have regarding this.

[parrobe]

Hi @JakeReise,

SSLPEERMAPs relate to client applications connecting directly to IBM MQ. From what you've said here it sounds like you've set up your MQ channels to block any clients that don't connect with known TLS Certificates and those that do connect are mapped to a specific userid(s). Any runmqsc clients connected remotely via runmqsc -c will connect via a channel and so have permissions to execute commands based off the user authorities you have defined for whichever user it gets mapped to.

oc exec does not relate to IBM MQ and is more closely associated with the container that IBM MQ is running in. Think of it similar to running a SSH command to login to a remote machine and run commands against the Operating system.
So when you run oc exec runmqsc it will open a terminal to the container and run the local runmqsc which binds to MQ locally as the user that the container (and MQ) is running as. Because it is the user that is running the queue manager (and effectively in the mqm group) it will have administrative authorities. This is the user you see when you run oc exec whoami.

Because clients connecting via channels do not have capability to run system commands (such as whoami) and because oc exec is the same as SSH(ing) into a machine to run a command i don't believe there is a remote command execution bug here. If you want to prevent users from being able to run commands via oc exec then you have to configure OpenShift so that only the users that should be able to be able to access the container have the RoleBinding that allows them to run oc exec
If you want to prevent that random user from accessing your MQ, then locally you cannot because it is needed by IBM MQ to access the underlying filesystem. To prevent it remotely you would need to look at blocking all administrators from connecting remotely except for ones that you know about. A Channel Authentication rule of BLOCKUSER('*') USERLIST('*MQADMIN') will block any client from connecting that try to connect as an administrative user. You can then override this rule as you see fit for how you want your administrators to connect (if at all).

I hope this helps and that i've not misunderstood something.

[JakeReise]

So I think I figured out how it is mapping me to a non-existent user, but I don't know why. The command I ran is below

oc exec mi9210-0 echo "dis chl(*)"|runmqsc MI9210

Where mi9210-0 is the pod name and MI9210 is the queue manager name. It goes out to the pod and runs the command as app1 id via tls mapping. Not sure why it is using the mq channel to run this command. I realized that I have environment variables pointing to that pod and queue manager for a client. So I have MQCHLLIB, MQCHLTAB, MQSSLKEYR. So I run the above command on my desktop and I get unauthorized for app1 to display those channels. That is fine, I haven't done auth records for app1 to do that, what I dont understand is why the presence of those environment variables affects the oc exec command. Once I remove those, the command tries to just execute locally and fails because there is no queue manager locally. I also go onto the pod and run the below command and it works as expected as the random user id has the authority.

echo "dis chl(*)"|runmqsc MI9210

I know the below command will work locally and remotely running as the random user and not utilizing the MQ environment variables. I just was clarification as to why the original command forcefully uses the environment variables if they are present.

echo "dis chl(*)" | oc exec -it mi9210-0 -- runmqsc

I am probably just confused on the pipe ordering in the command, I am just trying to understand how those variables are being utilized when I am not explicitly calling them.