| Author |
Message
|
| PeterPotkay |
 Posted: Fri May 23, 2008 7:12 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| jefflowrey wrote: |
| fjb_saper wrote: |
Try +allmqi and remove what you don't think you need. When it stops working you have removed too much...
 |
You have tihs backwards... use -allmqi, and add what you think you need. Once it starts working, stop! |
This is a good idea, I just updated my own doc, but why stop with -allmqi. Use -all to be sure.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri May 23, 2008 9:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
The point I was trying to make with +allmqi is that this is a configuration that is known to work in most cases...
So if you subtract from that what you don't want or know or think you don't want ... or just try to subtract everything one at a time you should end up with a minimum working set...
If you start with nothing you might end up adding more than what you need unless you try all possible combinations...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Mar 18, 2009 10:56 am Post subject: Re: Authorization Question |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| T.Rob wrote: |
The prescribed method here is to create an ID and group. The group has only the one service ID in it. The service ID is a non-login ID and it's primary and only group is the one we just created. So in UNIX terms you have ID:group = cms:cms. So far, so good.
The next thing is to set the permissions for the MCAUSER to connect:
setmqaut -m QM2 -g cms -t qmgr -all +connect +inq +set +setall
In this case whether you use JMS has nothing to do with it because it is the MCA that is doing the inquire. That is how it finds out the name of the DLQ. Again, so far, so good.
Next you need permissions to put the message on the queue:
setmqaut -m QM2 -g cms -n 'CMS.IN' -t queue -all +put +setall
The +setall allows the MCA to set the fields in the MQMD such as the User ID and the time stamp to match the values from QM1. This is what I believe that you are missing.
To address another concern from the thread, as long as the MCAUSER is the *only* thing using the cms service account, we like +setall. It is the only way that the MCA can create the message header to match the values of the message on the originating QMgr. And we know that the MCA will never do anything but connect, inquire and put.
Does that help?
By the way, in my article I gave +allmqi permissions for an MCAUSER and I now regret that. It is almost impossible to get a developerWorks article updated though. In any new articles or presentations I am telling people not to use the generic authorizations at all. Instead, use +connect +inq for the QMgr. |
Is this applicable for QMgrs in cluster when the putting application id is not part of mqm and without providing permissions to SYSTEM.CLUSTER.TRANSMIT.QUEUE?.
Thanks. |
|
| Back to top |
|
|
| T.Rob |
| Posted: Wed Mar 18, 2009 7:45 pm Post subject: Security on S.C.T.Q |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
The security check is on the first local object that the name resolves to. If you specify a fully-qualified name to a remote queue, the first object resolved is the transmit queue. This is often the case when the putting application is a service provider. Service consumers can get away with not needing access to the cluster command queue but service providers usually have too many requestors to require alias or remote queues for all the possible responses.
Does this mean that you should not do this? Absolutely not! There are many applications for which requests can originate from lots of client apps and you can't expect to put up remote queues to all of them. What this does mean however is that you must place an elevated level of trust in that application. Perhaps it gets a higher level of peer review, code review or approval before deployment. Perhaps it gets it's own service account and group so you can create a different security control model from the client apps.
The key is to be aware of the trade-offs. If you give up control in the security model, you must decide if you need some compensating control elsewhere such as in the change control process.
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Mar 19, 2009 5:56 am Post subject: Re: Security on S.C.T.Q |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| T.Rob wrote: |
The security check is on the first local object that the name resolves to. If you specify a fully-qualified name to a remote queue, the first object resolved is the transmit queue. This is often the case when the putting application is a service provider. Service consumers can get away with not needing access to the cluster command queue but service providers usually have too many requestors to require alias or remote queues for all the possible responses.
Does this mean that you should not do this? Absolutely not! There are many applications for which requests can originate from lots of client apps and you can't expect to put up remote queues to all of them. What this does mean however is that you must place an elevated level of trust in that application. Perhaps it gets a higher level of peer review, code review or approval before deployment. Perhaps it gets it's own service account and group so you can create a different security control model from the client apps.
The key is to be aware of the trade-offs. If you give up control in the security model, you must decide if you need some compensating control elsewhere such as in the change control process. |
Hi Rob,
Better to confirm with you whether I am understanding what you are saying here:
You are saying the application ids should be part of mqm group or should be given permissions to SYSTEM.CLUSTER.TRANSMIT.QUEUE when the app wants to write the message to a specific cluster queue on a specific QMgr and we should trust the applications that they are not going to put the message to a different application's destination queue.
Please confirm.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 19, 2009 6:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...we should trust the applications that they are not going to put the message to a different application's destination queue. |
Applications pick which queue to open by naming the QL or QR definition that sysadmins provide.
App developer oversight, testing and QA before the app goes into PROD, should demonstrate that the app code meets specs AND policy.
If you don't trust your developers, get rid of them.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 19, 2009 7:32 am Post subject: Re: Security on S.C.T.Q |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| we should trust the applications that they are not going to put the message to a different application's destination queue. |
Paranoid much? 
Of all the things a badly written / malicious application could do, I'd say using the wrong queue is among the least of your issues. I doubt WMQ is the best place to insert protection against such things.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 19, 2009 7:37 am Post subject: Re: Security on S.C.T.Q |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| Sam Uppu wrote: |
| we should trust the applications that they are not going to put the message to a different application's destination queue. |
Paranoid much?
Of all the things a badly written / malicious application could do, I'd say using the wrong queue is among the least of your issues. I doubt WMQ is the best place to insert protection against such things. |
It is equally bad for MaliciousApplication to send a message to PayrollManagementApplication's Input as it is for MaliciousApplication to send a message to SYSTEM.ADMIN.COMMAND.QUEUE. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 19, 2009 7:42 am Post subject: Re: Security on S.C.T.Q |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| It is equally bad for MaliciousApplication to send a message to PayrollManagementApplication's Input as it is for MaliciousApplication to send a message to SYSTEM.ADMIN.COMMAND.QUEUE. |
And my point is that a malicious application is more likely to attempt to disguise itself by sending the "right" message to the "right" queue; a badly written application will do more damage to a system by hogging resources than filing an inappropriate queue (where it will quickly be spotted).
And in all these cases WMQ is not the best place to defend against such issues.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 19, 2009 7:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
Paranoid much?
I was attempting to explain (to a management person) how messages become invisible to other apps while inside a UofW.
He became quite anxious that MQ allows programmers to create invisible, and thus undetectable, messages.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| T.Rob |
| Posted: Mon Mar 23, 2009 3:42 pm Post subject: Apps in mqm group |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
Just to follow up from Sam's question, no I am not suggesting that any app should be in the mqm group. I don't want to ever be mistaken for having advocated that approach. All I am saying is that some apps require access to transmit queues because they do not know in advance to where their replies will go. If your policy is to not allow access to XMit queues (as it is at Sam's shop) then consider some other check and balance such as an elevated level of review prior to implementation.
As for whether to trust apps not to put messages into another apps queue there are many instances where "if you don't trust your developers get rid of them" works. However for many of my clients there are regulatory requirements that specifically require enforcement of application isolation. In these instances there is no luxury of simply trusting the developers or applications. The question of whether Sam is being overly paranoid would seem to depend on whether his shop was in such a regulated environment.
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Mar 23, 2009 4:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| All I am saying is that some apps require access to transmit queues because they do not know in advance to where their replies will go. |
Whoa!
So, someone has written a request-reply model app where the replying app doesn't necessarily rely on the resolved reply-to-qmgr name in the request message MQMD?
The app then picks from a list of xmit queue names for the reply-message instead of opening a QR definitions that resolve to xmit queue name?
This doesn't qualify for best-practice, does it?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 23, 2009 4:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| bruce2359 wrote: |
| Quote: |
| All I am saying is that some apps require access to transmit queues because they do not know in advance to where their replies will go. |
Whoa!
So, someone has written a request-reply model app where the replying app doesn't necessarily rely on the resolved reply-to-qmgr name in the request message MQMD?
|
The app does reply to the ReplyToQ / ReplyToQM in the MQMD of the request message, and so doesn't know ahead of time all the possible queues and QMs it may be replying to, so its not feasible to predefine remote q defs for the reply messages, thus the need for access to the XMITQs.
If this is your scenario, you can lessen the security exposure by tagging the MCAUSER of the RCVR channel with an ID with limited access, like -put for the SYSTEM.ADMIN.COMMAND.QUEUE.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 24, 2009 5:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The app does reply to the ReplyToQ / ReplyToQM in the MQMD of the request message, and so doesn't know ahead of time all the possible queues and QMs it may be replying to... |
By default, the WMQ request-reply model implements uni-directional authorization; namely: reply-to-queue and reply-to-qmgr are authorized on the requesting (sending) qmgr.
Assuming that there is a fininte and known number of qmgrs replying app needs to reply to...
I was contemplating having the resulting reply-to-qmgr (xmitq) definition on the requesting qmgr resolve to a QR name that is not the actual name of the xmitq on the replying qmgr. Thus, when the replying app MQOPENs or MQPUT1's the reply message, it will drive name resolution and authorization to a name that is a QR, not explicitly an xmitq.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Mar 24, 2009 10:53 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| PeterPotkay wrote: |
| bruce2359 wrote: |
| Quote: |
| All I am saying is that some apps require access to transmit queues because they do not know in advance to where their replies will go. |
Whoa!
So, someone has written a request-reply model app where the replying app doesn't necessarily rely on the resolved reply-to-qmgr name in the request message MQMD?
|
The app does reply to the ReplyToQ / ReplyToQM in the MQMD of the request message, and so doesn't know ahead of time all the possible queues and QMs it may be replying to, so its not feasible to predefine remote q defs for the reply messages, thus the need for access to the XMITQs.
If this is your scenario, you can lessen the security exposure by tagging the MCAUSER of the RCVR channel with an ID with limited access, like -put for the SYSTEM.ADMIN.COMMAND.QUEUE. |
Here are you saying use the low privileged id in the MCAUSER of CLUSRCVR channel and also providing just -all +put permissions to SYSTEM.ADMIN.COMMAND.QUEUE?.
Let me know.
Thanks. |
|
| Back to top |
|
|
|
|
