| Author |
Message
|
| smeunier |
 Posted: Mon Feb 18, 2013 8:26 am Post subject: Java Security Exit |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Operation system: AIX 5.3.0.0
MQ Version:
Version: 7.0.1.5
CMVC level: p701-105-110419
I have been trying to implement a Java Security exit on a Cluster receiver channel. On start up of the channel I see the following error reported back from the cluster sender channel.
AMQ6174: The dynamically loadable shared library
/var/mqm/exits64//com.ibm.dblii.MQChannelValidator was not found. The
system returned error number '2' and error message 'A file or directory in the
path name does not exist.'. The queue manager will continue without this
module.
I have Googled this error and have done what I think is the correct due diligence in trying to identify the error, but cannot resolve.
- mqm has full access through the directory structure (/var/mqm/exits64)
- I have placed both the .class file as well as .jar file containing the class MQChannelValidator in the directory structure with full permission.
- qm.ini has the correct stanza
ExitPath:
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
What is a bit puzzling, is the path in the error message: /var/mqm/exits64// with the double "//" I'm not sure where that would be coming from or if it is even valid!
I'm looking for some constructive direction, that has not been intuitively obvious in the manuals or web sites.
One thing I have wondered, is if Java exits are supported in V7.0? I suspect they are as V7.0 manuals discuss them!
Thanks in advance. |
|
| Back to top |
|
 |
| McueMart |
| Posted: Mon Feb 18, 2013 8:29 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Long shot without having much knowledge about this topic in general, but have you tried:
| Code: |
- qm.ini has the correct stanza
ExitPath:
ExitsDefaultPath=/var/mqm/exits
ExitsDefaultPath64=/var/mqm/exits64
|
instead of
| Code: |
- qm.ini has the correct stanza
ExitPath:
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
|
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 18, 2013 8:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Java security exits are only supported for use within Java applications.
The queue manager is *NOT* a Java application.
There is *no* JVM associated with the queue manager.
What *exact* and *specific* need are you trying to fill by using a security exit on a cluster channel? You very likely are trying to do something the hard way. |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Feb 18, 2013 10:25 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| Quote: |
| Java security exits are only supported for use within Java applications. |
Isn't a Java Security exit no different really than a triggered Process? That may be an over simplification, but that is where my head was at..........
The problem that was trying to be solutioned, was to prevent unauthorized QMGRS from joining a cluster without using SSL.
Using the methods defined in the Help Center, I thought I could do this in Java.
| Quote: |
To prevent a queue manager receiving messages, you can write:
A channel exit program on each cluster-sender channel, which uses the connection name to determine the suitability of the destination queue manager to be sent the messages.
A cluster workload exit program, which uses the destination records to determine the suitability of the destination queue and queue manager to be sent the messages
A channel auto-definition exit program, which uses the connection name to determine the suitability of defining channels to the destination queue manager
|
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 18, 2013 11:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smeunier wrote: |
| Quote: |
| Java security exits are only supported for use within Java applications. |
Isn't a Java Security exit no different really than a triggered Process? That may be an over simplification, but that is where my head was at.......... |
It's not an oversimplification.
It's just not remotely correct.
All channel exits, including security exits, run inside channels.
| smeunier wrote: |
| The problem that was trying to be solutioned, was to prevent unauthorized QMGRS from joining a cluster without using SSL. |
*This* is an oversimplification. You're trying to secure your bank account by putting your bank card into a strong box, rather than by locking the door of the bank.
It's also a lot easier to do this in v7.5, using chlauth mechanisms and ip filters.
If you're not at v7.5, you should start by ensuring that only known and trusted hosts can actually connect to the mq listener port on cluster queue managers.
Then you can write out the costs to build AND MAINTAIN a c-language security exit that will accomplish what you want, and compare the cost of that to implementing SSL on your cluster channels, and come to the obvious conclusion that SSL is practically free.
| smeunier wrote: |
Using the methods defined in the Help Center, I thought I could do this in Java.
| Quote: |
To prevent a queue manager receiving messages, you can write:
A channel exit program on each cluster-sender channel, which uses the connection name to determine the suitability of the destination queue manager to be sent the messages.
A cluster workload exit program, which uses the destination records to determine the suitability of the destination queue and queue manager to be sent the messages
A channel auto-definition exit program, which uses the connection name to determine the suitability of defining channels to the destination queue manager
|
|
Yes, you can do those things.
But not in Java.
Because Java only runs where there is a JVM. And cluster channels don't run inside a JVM and neither does the queue manager.
And none of the use of the word 'program' in that quote above means 'a standalone executeable'. It means 'a piece of user-written and developed and tested and maintained code that runs inside the queue manager processes". That's what "exit" means. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 18, 2013 11:59 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Writing exits in general is not trivial.
Writing exits that run in an MQ cluster is even more difficult. Multiply that by 10 if your MQ cluster includes QMs running different operating systems including z/OS.
Writing security exits that are truly secure and functional is nothing to be taking lightly.
You may find SSL ends up being the prefered choice. But well written exits can also accomplish this and you should explore a commercial product that already does this. The real cost will likely be cheaper to buy a complex solution like this versus trying to successfully and securely write your own.
The MQAUSX exit from Capitalware is worth researching.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Feb 18, 2013 12:12 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Thanks taking the time for the detailed explanation and viable options you presented.
One final question(honest):
Installing V7.5 is a long road for us. But upgrading to it on just the Cluster Full Repositories may be doable. Would this be sufficient in IP blocking/filtering, or does it need to be on Sender as well as Receiver servers? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 18, 2013 12:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The only way a new QM can properly introduce itself into the cluster is via one of the Full Repositry QMs.
That doesn't mean a new QM couldn't be connected via a regular SNDR/RCVR channel pair to an unsecure Patrial Repositry Queue Manager and do some damage there, but the new QM wouldn't be part of your cluster.
There wouldn't be anything preventing the new QM being a Full Repository for its own unauthorized cluster, and pulling in your unsecure partial repositories into the new cluster, at which point the partial repositories would be in both clusters. Oh the confusion that could ensue!!!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 19, 2013 5:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's still locking the windows whilst leaving the door open.
The notion of protecting against unauthorized queue managers joining the cluster means that there's a notion of unauthorized queue managers in the first place, which means that there's a notion of unmanaged systems in your production environment, which means you don't have a properly managed production environment.
Your production servers should be entirely behind firewalls from the rest of the company. Every access to every system in production should be logged and documented.
No change should be made to any system running in the production network without proper change control processes governing and controlling it. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 19, 2013 5:48 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| smeunier wrote: |
| Installing V7.5 is a long road for us. |
CHLAUTH was added in V7.1 if that helps...  although if you do make any plans to upgrade, go to V7.5 directly... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
