| Author |
Message
|
| odium74 |
 Posted: Fri Jul 11, 2014 2:57 am Post subject: WMQ Explorer 7.x - disable "add remote queue manager&qu |
 |
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
Hi there,
I need to deploy WMQ Explorer to non admin desktops ...
i've managed to deploy custom configs with WMQ_handles.xml and WMQ_sets.xml files
in C:\Users\%username%\IBM\WebSphereMQ\workspace\.metadata\.plugins\com.ibm.mq.explorer.ui
Now the big issue is that i want to deny the possibility to add remote queue managers for those users ...
why ? because "smart users" will be able to create queue managers using
known SVRCONN channels which grants unwanted perms !!
is there a way to disable the "add remote queue manager" button ?
maybe at windows registry through policies ? maybe at the eclipse plugin level ? etc ...
thanks for any help !
regards. |
|
| Back to top |
|
 |
| McueMart |
| Posted: Fri Jul 11, 2014 3:20 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
But if these 'smart users' wanted to be nefarious, they could write a trivial java program using these 'known SVRCONN' channels.
I get the feeling you might be trying to implement security practices in the wrong manner. Have you looked at how you should be properly securing these 'remote QMGRS' which you only want selected access to? |
|
| Back to top |
|
|
| odium74 |
| Posted: Fri Jul 11, 2014 3:32 am Post subject: |
|
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
firstly thanks for your answer !
the problem is that those remote queue managers are for multihomed applications. Therefore we have plenty of SVRCONN channels with different MCAUSER which of course grants different permissions.
When i said "smart users" i didn't mean "programmers" 
but some of them know the name of existing SVRCONN channels,
so we want to avoid this happening !
thanks again ... |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 11, 2014 3:35 am Post subject: Re: WMQ Explorer 7.x - disable "add remote queue manage |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| odium74 wrote: |
| why ? because "smart users" will be able to create queue managers using known SVRCONN channels which grants unwanted perms !! |
I'm assuming you mean queues as opposed to queue managers as you have to have Explorer on the box on which you wish to create a queue manager, so why would the "smart admin" not lock down those channels - and remote queue managers - such that "smart users" can't create things they're not supposed to? And CHLAUTH records are designed to do exactly what you need...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| odium74 |
| Posted: Fri Jul 11, 2014 3:45 am Post subject: Re: WMQ Explorer 7.x - disable "add remote queue manage |
|
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
| exerk wrote: |
| odium74 wrote: |
| why ? because "smart users" will be able to create queue managers using known SVRCONN channels which grants unwanted perms !! |
I'm assuming you mean queues as opposed to queue managers as you have to have Explorer on the box on which you wish to create a queue manager, so why would the "smart admin" not lock down those channels - and remote queue managers - such that "smart users" can't create things they're not supposed to? And CHLAUTH records are designed to do exactly what you need... |
no, i really meant "queue managers"
i don't want to allow users to use the "add remote queue manager" function.
i want them to only work with those i defined in the WMQ_handles.xml file.
thanks for trying to help
. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 11, 2014 4:14 am Post subject: Re: WMQ Explorer 7.x - disable "add remote queue manage |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| odium74 wrote: |
| ...no, i really meant "queue managers"... |
Then I stand by my previous statement - the "smart admin" will have locked down the channels such that a "no-matter-how-smart user", even knowing the name of those channels, can connect and add remote queue managers to their MQ Explorer.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| markt |
| Posted: Fri Jul 11, 2014 4:17 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
You really are thinking about this from the wrong end.
What you need to do is block people from connecting to the queue managers, or using specific channels into those qmgrs, that you don't want them to use
As others have said, even if you had some way to block Explorer from defining new connections, what's to stop them using other tools that could get access to those systems.
That's what CHLAUTH, SSL, AUTHINFO etc help to control. |
|
| Back to top |
|
|
| odium74 |
| Posted: Fri Jul 11, 2014 4:29 am Post subject: |
|
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
| markt wrote: |
You really are thinking about this from the wrong end.
What you need to do is block people from connecting to the queue managers, or using specific channels into those qmgrs, that you don't want them to use
As others have said, even if you had some way to block Explorer from defining new connections, what's to stop them using other tools that could get access to those systems.
That's what CHLAUTH, SSL, AUTHINFO etc help to control. |
ok, let's turn around the problem then ..
how can i deny a certain user from using an existing SVRCONN channel (which has a particular "MCAUSER" defined) knowing that this particular user should keep his access to this QMGR imperatively (of course using the right SVRCONN channel reserved for his application) ??
thank again to everyone
. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 11, 2014 4:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| markt wrote: |
You really are thinking about this from the wrong end.
...
As others have said, even if you had some way to block Explorer from defining new connections, what's to stop them using other tools that could get access to those systems.
That's what CHLAUTH, SSL, AUTHINFO etc help to control. |
Even if you find a way to modify the instance of MQ Explorer you deploy, what's to keep your smart users from downloading and deploying the Explorer from SupportPacs or elsewhere?
 CHLAUTH, SSL, AUTHINFO etc. are the way to secure your qmgrs.
_________________
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 |
|
|
| odium74 |
| Posted: Fri Jul 11, 2014 4:51 am Post subject: |
|
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
| markt wrote: |
CHLAUTH, SSL, AUTHINFO etc. are the way to secure your qmgrs. |
maybe is time to let you know that i'm using WMQ 7.0.1,
therefore i can't use CHLAUTH ... 
thanks again. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 11, 2014 5:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| odium74 wrote: |
...maybe is time to let you know that i'm using WMQ 7.0.1,
therefore i can't use CHLAUTH ... |
LOOK HERE!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| odium74 |
| Posted: Fri Jul 11, 2014 5:43 am Post subject: |
|
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
| exerk wrote: |
| odium74 wrote: |
...maybe is time to let you know that i'm using WMQ 7.0.1,
therefore i can't use CHLAUTH ... |
LOOK HERE! |
thanks, i've already checked that solution before but it doesn't permit to
achieve what i need.
If we take a look at action nº 4 as described on this tutorial :
| Quote: |
Steps to carry out on the WebSphere MQ Explorer machine
1.Right-click on ‘Queue Managers’ and choose ‘Show Queue Manager’
2.Click on the ‘Add’ button
3.Enter the queue manager name and click ‘Next’
4.Fill in the hostname of the machine hosting the queue manager, the TCP port number for the channel listener you started, and the name of the server-connection channel you created
5.Click Finish
|
if the user using WMQ Explorer enters an existing SVRCONN channel (different from the one we admins assigned to him) where MCAUSER="mqm" , then security is compromised !!
Therefore this method won't help in my case.
thanks ! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 11, 2014 5:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| odium74 wrote: |
if the user using WMQ Explorer enters an existing SVRCONN channel (different from the one we admins assigned to him) where MCAUSER="mqm" , then security is compromised !!
Therefore this method won't help in my case.
thanks ! |
Yes it will.
Again, you're thinking about this from the wrong side. You are trying to prevent the users from entering in the wrong channel information, rather than prevent the users from CONNECTING TO THE WRONG CHANNEL.
Before MQ v7.1, SSLPEER is the way you control who can or cannot connect to a given channel.
Before MQv8, CHLAUTH is the way you control who can or cannot connect to a given channel + SSLPEER |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 11, 2014 5:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Any channel that has an MCAUSER value equal to the super-user of an MQ installation already has compromised security! No, repeat no, channel should have the super-user specified.
There are a number of solutions to restricting access and authority level on non-CHLAUTH-capable queue managers, both free-ware (e.g. BlockIP2) and commercial (e.g. Capitalware offerings), that can be used.
I most strongly recommend that you revisit your security model...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 11, 2014 5:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| Any channel that has an MCAUSER value equal to the super-user of an MQ installation already has compromised security! No, repeat no, channel should have the super-user specified. |
At least some channels can reasonably have a user that is a member of the mqm group - provided that it is secured such that only the right people can use it.
| exerk wrote: |
| There are a number of solutions to restricting access and authority level on non-CHLAUTH-capable queue managers, both free-ware (e.g. BlockIP2) and commercial (e.g. Capitalware offerings), that can be used. |
And, of course, the inbuilt SSL functions that ship with the product. |
|
| Back to top |
|
|
|
|
