| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ intercommunication fails |
« View previous topic :: View next topic » |
| Author |
Message
|
| zhanghz |
 Posted: Wed Jan 28, 2009 6:38 pm Post subject: |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Peter, the first link is under section "User IDs for resource security (MQOPEN and MQPUT1)" which is for opening queues and putting messages into queues. The second link, PUTAUT controls which ID(s) to use for security check for putting messages to queues. I was trying to test whether MCAUSER is used when I start a channel, so the info is irrelevent to my test, right?
| PeterPotkay wrote: |
...a started/running channel versus a started/running channel attempting to move messages are not one and the same.
... |
Did I misunderstand your previous post on "Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry."? I thought you were saying MCAUSER is checked when a channel is being started. That's why I did my "set dummy MCAUSER and start channel" test.
I know that when a message is being put to a queue when a bogus MCAUSER id is used in the RCVR channel, a RACF violation message will be generated saying the user is not RACF defined.
| bruce2359 wrote: |
Check for the existence of the ssid.CHIN profile.
Check for the existence of ssid.RESLEVEL. With the appropriate RESLEVEL, zero, one or more ids can be checked.
|
ssid.CHIN is defined and access is given to the group of my TSO id, the group of started task id and chinit id. ssid.RESLEVEL is set and no access is given to any id. My understanding of these 2 settings is that if MCAUSER id is used to check for starting a channel, the channel will not be able to start with the non-existing MCAUSER id I put in the RCVR channel.
Do correct me if I am wrong. Thanks. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jan 28, 2009 7:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Do correct me if I am wrong. |
You are not wrong; rather, your assessment and understanding of the RACF environment is incomplete.
This is why you need RACF help from RACF administrators. You cannot guess your way through this. There are lots of parts that must all be in place for security to work as you intend.
Your RACF admins need to grant (or deny) the appropriate access to the appropriate resources and MQ commands.
I am not surprised that the channel ends connect, since the CHIN (and MSTR) address space uses its MQADMIN authority to start the channel. SSL can fix this for you.
Recall that MQ security is wide open until RACF rules say otherwise.
_________________
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: Wed Jan 28, 2009 8:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Additionally, a channel that is running but can't send messages is sort of like a car that starts up but has no wheels.
In both cases, yeah, it started, but so what?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zhanghz |
| Posted: Wed Jan 28, 2009 10:35 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
I don't want to fix anything, i simply wanted to test whether MCAUSER is checked for authority to start a channel. What I understand from Peter's post is that MCAUSER is checked whether the MCAUSER has access to start the channel; if the MCAUSER is a bogus id, the channel will not start. That is my understanding of Peter's post, so, I wanted to test that, as I didn't encounter any case that MCAUSER id prevents a channel from starting, on z/OS at least.
I understand that a started channel that can't send/receive messages is no good than a stopped or retrying channel or no channel at all. But that's not my concern in my test here.
My test result implies MCAUSER is not checked for starting channels.
Is my result correct?
Bruce, do you have the list of RACF profiles that MQ will check when starting a channel? So that I can check them using RACF listing. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Jan 28, 2009 11:24 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Code: |
| Is my result correct? |
sounds to me that you have not read the proper section in the security manual i posted and some of the other posts here from the other guys....
the answer to this has already been given.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 29, 2009 7:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
I did a quick search on Mr. Google and found this: Using RACF and the OAM for end-to-end MQ security http://www.sjg-enterpriseintegration.com/oamsecurity.asp
MS13: WebSphere MQ for z/OS - Sample to verify RACF Users http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24000090&loc=en_US&cs=utf-8&lang=en
And especially this: WMQ z/OS Concepts and Planning, the Security unit.
From the Security unit: If you do nothing about security, the most likely effect is that all users can access and change every resource. This includes not only local users, but also those on remote systems using distributed queuing or clients, where the logon security controls might be less strict than is normally the case for z/OS.
The If you do nothing sentence should have been written: If you do nothing or you don't do enough...
Merely setting MCAUser to non-blank is not enough. Just as if you lock your front door, but leave it wide open. Or you lock it, but leave the other doors unlocked
_________________
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 |
|
|
| masteringmq |
| Posted: Thu Jan 29, 2009 9:11 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Quote: |
| You've just accepted the fact that anybody from the western region or eastern region can send PCF commands to your SYSTEM.ADMIN.COMMAND.QUEUE and have their way with your QM. |
But using PUTAUT(DEF) also allows anybody to connect to the queue manager and send PCF commands to your SYSTEM.ADMIN.COMMAND.QUEUE. As long as the userid is valid messages can be sent to the destination queue. The difference between the mqm userid and a non mqm userid is that a mqm userid is treated as a super userid. This means the mqm users can perform administrative task. What does the OAM do?. It checks to see if the userid is authorized to put messages in the queue. Since the mqm userid is a super userid therefore it has full access to put messages on all queues. If you can send a PCF command to the SYSTEM.ADMIN.COMMAND.QUEUE then you can perform administrative task. I believe not everyone can use the mqm userid accept the administrator who has access to this id.
Last edited by masteringmq on Fri Jan 30, 2009 12:10 am; edited 16 times in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 29, 2009 10:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Unless the person belongs to the mqm group then yes they can send a PCF commands to the SYSTEM.ADMIN.COMMAND.QUEUE. |
Are you saying that only the MQM group can put PCF messages to this queue?
_________________
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 |
|
|
| masteringmq |
| Posted: Fri Jan 30, 2009 12:09 am Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| My post is edited. Im sorry for the wrong post. Please feel free to comment. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 30, 2009 4:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| masteringmq wrote: |
| I believe not everyone can use the mqm userid accept the administrator who has access to this id. |
Its trivial for someone to create an mqm id on their PC, download the trial version of MQ, log in as mqm, create a QM, and connect to any unprotected channels on QMs in the environment to send messages to their command queues.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| masteringmq |
| Posted: Fri Jan 30, 2009 4:40 am Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
I cant do much at my company, but this was an explanation given to me by an mq expert. The mechanism is to understand and simulate with the mind  . Also one more thing, I can have a box. If I attempt to connect to another box first my IP address must be configured to the firewall at that box. Otherwise I cant make a connection to the QM in that box. Therefore what ever userid I have, it wont be useful. Yes I agree that most attacks can come from within the organization, but there are code of ethics and policy in every company.
Last edited by masteringmq on Fri Jan 30, 2009 4:47 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 30, 2009 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| masteringmq wrote: |
| this was an explanation given to me by an mq expert. |
You might want to ask for a refund! 
Alternatively, you might want to run an audit on your system; there could be a rather dubious reason this "expert" would allow a security hole on your system..... 
Of course, such people do not use mqseries.net, which is populated by people of the highest moral character, scruples and professionalism. I use it too. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
