Ask Brandon to move the discussion over to the FAQ section, if it's not there already! :-)
-- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, May 17, 2004 3:03 PM To: [EMAIL PROTECTED] Subject: Re: Java Clients and Security Hole??? - Leftovers.. Hi Rob and Pavel, Thank you for your responses. But it looks like thats how it is designed. And there is nothing much that could be done other than using the alternatives, ie. SSL, mcauser with userid specified, for more secure environment. Have had a long discussion on mqseries.net. Cheers Kumar "Wyatt, T. Rob" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 05/17/2004 09:45 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Java Clients and Security Hole??? - Leftovers.. Kumar, You always have to assume that an MQ client connection is insecure. Even if you only use MQ inside your company's firewall, anybody could put the client on a laptop, plug into your network, and impersonate mqm or whatever UserID is required to access your system. If you use the client-passed UserID to authenticate, everybody is on "the honor system" and is trusted to supply the correct credential although it is not enforced. This is by design. IBM provides the tools to enforce strong authentication using SSL and certificates. Lighter-weight solutions include setting the MCAUSER attribute to enforce a low-privileged UserID on the channel (at the expense of any kind of authentication), or using an exit such as BlockIP which can filter connections by IP address or enforce some UserID policies such as refusal of connections from IDs with administrative authority (mqm for example). Please also bear in mind that your SYSTEM.*.SVRCONN channels are wide open if left with their default settings. If you do not enforce some kind of authentication, anybody can attach to these channels with full administrative privileges. You can find the BlockIP security exit here: http://www.mrmq.dk/index.htm?BlockIP.htm -- T.Rob -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of mqonnet Sent: Sunday, May 16, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: Java Clients and Security Hole??? - Leftovers.. Hello again, Forgot to mention that I Also defined the SVRCONN channel with MCAUSER attribute BLANK(set to nothing). This looks to me like a *BUG* within the product that can be fixed. All comments welcome. Cheers Kumar -------Original Message------- From: mqonnet Date: Sunday, May 16, 2004 09:06:21 AM To: [EMAIL PROTECTED] Subject: Java Clients and Security Hole??? Hello Mq'ers, The scenario is like this: System A has MQ Server installed. System B has MQ Client installed. Both are on w2k with MQ 5.3, with or without csd's dont think it matters. I logon to system B with userid FRED who is in the mqm group on System B. I defined a userid/principal on System A named FRED. Did *NOT* assign this userid *any* groups. Just setmqaut'd this userid to accept connection on the queue manager. setmqaut -m QM1 -t qmgr -p FRED +connect. I defined a local queue, TEST on the qmgr on System A. Did *NOT* assign *ANY* authorities to userid FRED to access this queue on System A. Which would mean, userid FRED should be able to connect to qmgr QM1 but should NOT be able to open TEST queue. On System B, i have 2 test scenarios. 1) I run amqsputc TEST QM1. Connects fine, but mqopen fails with 2035 as expected. 2) I run a java MQ client app. Connects, opens, puts, closes and disconnects the queue just fine. This is what i believe is the security hole. And i believe it comes off the statement made in the Clients manual, Part 3, Chapter 7, under Access Control. Which says. "For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server". The above statement is what really bugs me. I see this as a major security hole. And i would believe IBM must have some strong theory for keeping it likewise, which obviously MUST already be know to IBM. Anyone on this forum or anyone from IBM throw some light on this??? To add to all this, i ran a trace on the server system A. Guess what. Amqsputc sends in userid "FRED" for authentication purposes as expected. But the java client sends in userid EntityName Administrato. I believe the implementation of the above comes from another statement made in the same manual as described above. "However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used." Just a guess. Any thoughts, anybody. Cheers Kumar Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
