| Author |
Message
|
| kishi_25 |
 Posted: Thu May 23, 2013 7:40 am Post subject: MCAUSER ID vs SET_IDENTITY_CONTEXT |
 |
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi,
If We set mcauser id with less privilege on Serverconn channel for MQI, and if the application has set_id_identity_ context with more privilege, when the message is placed on a queue, which ID will be authorized? also..which id will be finally carried on message when it reaches the queue.?
As in my search..I'm getting 2 difference answers..
1. As MCAUSER always takes high precedence and hence it can override
whatever userid comes in the message
2. While the application makes put to a queue, it can override MCAUSER with high privilege userid like mqm through set_identity_context and it can be come a security issue. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 23, 2013 7:47 am Post subject: Re: MCAUSER ID vs SET_IDENTITY_CONTEXT |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
As in my search..I'm getting 2 difference answers..
1. As MCAUSER always takes high precedence and hence it can override
whatever userid comes in the message
2. While the application makes put to a queue, it can override MCAUSER with high privilege userid like mqm through set_identity_context and it can be come a security issue. |
Where in your search did you get point 2? That a message with the identity deliberately set (as opposed to simply passed) will override MCAUser?
Why would a normal application (as opposed to an administrative tool) be given setid? Cite use cases.
Note that WMQv7.5 has changes in this area.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Thu May 23, 2013 7:58 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
We are using a third party product, which makes set_identity_context call.
We couldn't trace back on why the application needs set_identity_context as currently it's not supported and people can't provide source code or reason behind using this parameter from application.
so, I was under the impression that, if I set an MCAUSER id, it can take care of resetting this value, in case if there is a risk of security...
But, my PMR with IBM L2 says as below. As I'm planning to check with L3 on this..:So thought of checking here, before I go for L3.
"Although you set the mcauser id, if the application has setid privilege it can change the User ID in the message header when it does the put to the queue.
"[/u] |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 23, 2013 8:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
We are using a third party product, which makes set_identity_context call.
We couldn't trace back on why the application needs set_identity_context as currently it's not supported and people can't provide source code or reason behind using this parameter from application. |
I love it when they say that.
| kishi_25 wrote: |
But, my PMR with IBM L2 says as below. As I'm planning to check with L3 on this..:So thought of checking here, before I go for L3.
"Although you set the mcauser id, if the application has setid privilege it can change the User ID in the message header when it does the put to the queue.
" |
Which does indeed read like an explicitly set id is unaffected by MCAUser. I'd be interested in the PMR number and what the response is from L3 (who will be much more authoratative than anything you get here).
You could also try a simple test with a client app that sets id.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 23, 2013 3:41 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
MQ will be using the svrconn channel's effective MCAUSER for authorization checks when the queue is opened. It does not do any checks when putting each message.
There are no checks on the identity context fields. If the app has authority to set these, it can set them to whatever it wants. (Hence the security concerns about authorizing apps to set them)
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 24, 2013 4:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
MQ will be using the svrconn channel's effective MCAUSER for authorization checks when the queue is opened. It does not do any checks when putting each message.
There are no checks on the identity context fields. If the app has authority to set these, it can set them to whatever it wants. (Hence the security concerns about authorizing apps to set them) |
Well it's a good day when I learn something new. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri May 24, 2013 11:01 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi Glen,
There are no checks on the identity context fields. If the app has authority to set these, it can set them to whatever it wants. (Hence the security concerns about authorizing apps to set them)..
Can you explain little detail on this with some example if posisble?
I'm still waiting for L3 update.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 24, 2013 11:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kishi_25 wrote: |
hi Glen,
There are no checks on the identity context fields. If the app has authority to set these, it can set them to whatever it wants. (Hence the security concerns about authorizing apps to set them)..
Can you explain little detail on this with some example if posisble?
I'm still waiting for L3 update.. |
It's like your house. Once I'm in your house, nothing stops me from opening your refrigerator. Unless you have another lock on your refrigerator.
MQ doesn't put locks on this refrigerator. Once an app is able to OPEN a queue, and it is able to SET IDENTITY CONTEXT, MQ is not going to do anything to check the identity that IS set.
Don't let anyone SET IDENTITY. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri May 24, 2013 11:58 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| kishi_25 wrote: |
| We are using a third party product, which makes set_identity_context call. |
There is no such call. What call is the application actually making? MQOPEN?
| Quote: |
| We couldn't trace back on why the application needs set_identity_context as currently it's not supported and people can't provide source code or reason behind using this parameter from application. |
Isn't this the most important thing in this whole story? If you are responsible for security, you need to know what the application is doing, and why. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri May 24, 2013 12:12 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
hi mqjeff,
you mean, the application will be getting full control on all mq objects, is it be cause of +SET_ID on QMGR?..
Reason I'm asking ...though I give SET_ID on QMGR, +SETID with setmquath is giving to only related application queue only and not any other queues..so, wondering how can it control all mq objects?..is it because of SET_ID access on QMGR? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 27, 2013 9:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
An application with setid can write a message to the command server input queue and mark that message as coming from the mqm or mqadmin user.
This assumes that the application also has permission to open the command server input queue with PUT permission. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Tue May 28, 2013 6:40 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
| ok understood..thanks for the inputs |
|
| Back to top |
|
|
|
|
