问题
Linux Server Box running WebSphere MQ Server v7.1:
I have created a user 'mq-user' that belongs to 'mq-users' group in Linux. Then I created a queue manager QM_TEST, and used MQSC to issue the following commands to create a queue and set up the security:
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('mq-user') AUTHADD(ALL)
SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,GET)
SET SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(INQ,DSP,PUT)
DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('mq-user')
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')
DEFINE QLOCAL (TEST_QUEUE)
SET AUTHREC PROFILE(TEST_QUEUE) OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(ALL)
DEFINE LISTENER (TEST_LISTENER) TRPTYPE (TCP) CONTROL (QMGR) PORT (1414)
START LISTENER (TEST_LISTENER)
Linux Client Box running WebSphere MQ Client v7.1 and WebSphere MQ Explorer:
I am logged in as my username (arrehman) which is not part of mq-users group. However I am able to access the queue I created above both via a Java Application and via MQ Explorer client without passing any user credentials. Why is it this way if security is in effect?
Any further details needed, please let me know. Thanks.
回答1:
This line:
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')
Says the following:
- For connections requesting
TEST_CHANNEL... - Originating from any IP address...
- Set the MCAUSER to
mq-user
In other words, enable the channel such that any connections inherit the privileges of mq-user regardless of where they originate and what identity they present. So the behavior you are seeing is the expected behavior based on the CHLAUTH rule above.
There are a few other problems with the rules as listed:
- The use of
PRINCIPALrather thanGROUP. On non-windows servers if you specifyPRINCIPALwhat happens is that the QMgr looks up that ID, queries its primary group and then sets authorizations based on that. So ifmq-usershas a primary group ofstafforusersthat that is what gets authorized instead ofmq-usersand is probably not what you intended. Always usegroupso that you get the result you intend withsetmqautorAUTHREC. - Granting
ALLon the QMgr makes the ID/group administrative. One of the privileges at the QMgr level isSETand any user in a group withSETrights can set, among other things, authorization control lists. So even though you only grantedAUTHADD(INQ,DSP,PUT)themq-usersID can submit PCF commands to grant all access to all objects. Only grantCONNECTandINQUIREon the QMgr if that's all you need. - There's an assumption stated (in bold, actually) that you would have expected to be required to pass user credentials. Please be aware that WMQ does not validate a user ID and password if you do provide them. It accepts the ID that you assert. The password field is available to exits which can be used to validate the ID and password against, for example, LDAP or the local OS. Such an exit can be purchased from a 3rd party or written but base WMQ doesn't do anything with the password. Had you specified
USERSRC(CHANNEL)on the mapping, then your ID would have been used and most likely rejected. But the rejection would have been either because it is in themqmgroup (which is blocked by a defaultCHLAUTHrule) or because there are noAUTHRECrecords for the group it is in.
For more about hardening WMQ, there are a number of resources collected here. The Hardening WebSphere MQ presentation is from v7.0. Although v7.1 has new controls, the principals remain the same:
- Authenticate the connection using IP filtering (for apps or QMgrs where the connection originates in a locked datacenter), SSL/TLS and/or an exit
- Map the authenticated identity to an
MCAUSERvalue by hard-coding it in the channel or by using an exit orCHLAUTHrule to dynamically set it - Administrative connections and high-value applications should be authenticated using TLS
来源：https://stackoverflow.com/questions/9416522/websphere-mq-v7-1-security-user-credentials