ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » security and clients

Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4  Next
 security and clients « View previous topic :: View next topic » 
Author Message
shogan2003
PostPosted: Sat May 15, 2004 7:39 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

I just want a failsafe security method. I can't guarantee that a Java app developer won't try to connect, so I have to cater for the worst-case scenario. Otherwise I'm back on the street...
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
mqonnet
PostPosted: Sun May 16, 2004 4:44 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Peter, I am starting a new thread off this topic and where we left this one. Since i am really intrigued by the fact that Java clients pose a security hole. Hmmm.

Just to clarify one another point, the security hole is very very isolated to ONLY one case and which is, if *NO* userid is set within the java client app. If one is set, irrespective of whatever it is, be it mqm or anything else, it *wont* work. So, the case thats left out is when *NO* userid is set, as is described below in the same manual. Ch 7 of clients manual, access control.

"For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server"


Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
markt
PostPosted: Sun May 16, 2004 5:09 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 512

As has been said here earlier, there are a number of ways in which userid information flows (or does not flow) from a client.

ALL OF THEM HAVE EQUIVALENT SECURITY STRENGTH. THERE IS NOTHING INHERENTLY "WEAKER" IN THE JAVA MODEL.

The mechanism for picking up the userid varies - get the logged on id for a C client, programmatic for a Java client, env variables on some old platforms - but all of these are simply ways to assert a value. How much trust do you have that a C client program is not running on a machine where end users can create arbitrary userids?

If you want a secure, authenticated client userid, then you MUST use SSL and/or security exits.

Simply stopping programs which assert no userid does not introduce any stronger level of trust in other connections.

The default behaviour of MQ was selected to make it easy to get going - there were too many people asking how to configure their first client channel - with the belief that people would read the manuals on how to then make connections secure later. Java programs did not necessarily have any way to get environmental information, such as a logged on id, and so the choice was made to flow nothing unless set by the program.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Sun May 16, 2004 5:18 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

markt, the following is not really true.

"Java programs did not necessarily have any way to get environmental information, such as a logged on id, and so the choice was made to flow nothing unless set by the program."

Reason is, its the responsibility of MQ java bindings that is sending or would be sending the info from a client or server system where you are running your MQ java app from. And hence it has nothing to do with the acutal MQ java app.

Now whether there are enough/appropriate functions/classes within java to get this info as you pointed out, i am not sure. But i would have thought there ought be. But in any case, i have started a different thread if you wish to off this topic to see if anyone knows why its designed this way.

http://www.mqseries.net/phpBB2/viewtopic.php?p=60920#60920

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
RogerLacroix
PostPosted: Sun May 16, 2004 1:59 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Quote:
Java programs did not necessarily have any way to get environmental information, such as a logged on id, and so the choice was made to flow nothing unless set by the program.


Kumar, this is true. You are confusing how Java and MQ interact.

(1)When the application connects in 'binding mode' then yes it is true that a JNI call is issues to the MQ libraries, hence, the 'real' / 'login' UserID can be picked up (assuming it is NOT a bogus ID).

(2)When an application connects in 'client mode' ONLY Java code is executed by MQ. Therefore, the application executes Java code and when calls are issued to MQ then MQ base code is executed ONLY in Java.

For people who don't about coding in Java, Java code can ONLY access variables with the JVM and NOT system variables. Therefore, the ONLY JVM variable that is related to UserIDs is user.name .

This is why IBM made the decision they did.

The other reason IBM made this desision is because you can override user.name when you start a Java application. Hence, an easy back-door to be any user you want.
Code:
java -Duser.name=mqm my-appl
java -Duser.name=FRED my-appl


Also, I think my previous comments were missed. Give me a Windows 95/98/ME box and I can do EXACTLY the same thing with C, COBOL, etc... programs.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
mqonnet
PostPosted: Sun May 16, 2004 5:53 pm    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Roger,

"You are confusing how Java and MQ interact"
---You may be right. But i still need to significant justifincations to convince myself that i am really confused.

What you described about the way java and mq interact seems right. When it comes to clients, and java connecting in "client mode" i am not 100% sure clear what you mean.

In either cases, i think doing whatever MQ needs to do under covers to get the logged on userid shouldnt be an issue. Be it a Java client connecting in clients/binding mode.

My whole point is this.

You have the java bindings(am not referring to the term of connection here, but MQ java libraries) which one uses to make MQ java api calls. Prior to 5.3 which was in MA88. These bindings could very well do when an MQ java app is connected in "client mode", what it does when an MQ java app connects in "bindings mode". I dont see any difference in implementation here. Unless of course, i am missing something.

"Also, I think my previous comments were missed. Give me a Windows 95/98/ME box and I can do EXACTLY the same thing with C, COBOL, etc... programs. "
---No, i did not. I know this would be the case on all the mentioned platforms which use MQ_USER_ID.

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
RogerLacroix
PostPosted: Sun May 16, 2004 6:53 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Quote:
You have the java bindings(am not referring to the term of connection here, but MQ java libraries) which one uses to make MQ java api calls. Prior to 5.3 which was in MA88. These bindings could very well do when an MQ java app is connected in "client mode", what it does when an MQ java app connects in "bindings mode". I dont see any difference in implementation here. Unless of course, i am missing something.

No, it cannot. When a MQ API call is issued in Java, if you are running in 'binding mode' the MQ class actually calls via JNI (Java Native Interface) to the C++ libraries and it is the C++ libraries that grab the UserID value from the system because the C++ libraries are not restricted to the JVM. (The JNI call is for speed.)

In 'Client mode', the C++ libraries are NOT called from java, hence, the JVM only has the user.name environment variable that COULD be the real value OR blank OR spoofed!!! Hence, IBM's choice to not use it.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
mqonnet
PostPosted: Mon May 17, 2004 2:55 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

"In 'Client mode', the C++ libraries are NOT called from java, hence, the JVM only has the user.name environment variable that COULD be the real value OR blank OR spoofed!!! Hence, IBM's choice to not use it.
"
---Thats my whole point. So, you say there is *NO* way one could make may be JNI calls within the MQ java libraries when connecting in client mode??? But then my question has been, whats the difference in client and bindings mode as far as the MQ java libraries are concerned. I mean, if JNI wrappers could be written that works for Java client connecting in bindings mode, then why cant they be used/written for the situation when java client connects in client mode.

Looking at the responses in this and the other thread i am getting a feel that IBM left this loophole because there was no real easy was to *fix* this. Is that the case.

Thanks Roger for your insights, though.

PS: All this is just a discussion, i dont have any problem on my system etc which i am trying to resolve. :)

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
PeterPotkay
PostPosted: Mon May 17, 2004 3:12 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

Quote:

Looking at the responses in this and the other thread i am getting a feel that IBM left this loophole because there was no real easy was to *fix* this. Is that the case.


The easy fix, IMHO, is for the SVRCONN channel to not start up us mqm or MUSR_MQADMIN if no ID is presented, and to not accept these IDs if there are presented by the client. (If the admin hardcodes it in the MCAUSER field, then allow it there I suppose.)

IBM says use an exit if you want this behaviour. I ask what is the benifit of defaulting to the most powerful ID possible when you don't have an ID? Doesn't make sense to me. But maybe there is something in the inner workings of MQ that makes this behaviour necessary.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
markt
PostPosted: Mon May 17, 2004 5:56 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 512

1. The default behaviour was chosen because of all the complaints that were received in the early days of MQ when a "no authorisation" setting was used as the default.

People getting going with MQ for the first time did not understand why connections were failing, and hadn't got as far as reading about setmqaut in order to connect non-mqm userids.

There is no intermediate level choice - you could either have "mqm" or "none" as the selection, so "mqm" it had to be.

2. The idea of the Java client is that it is pure Java - no JNI is allowed. That way it can run in environments such as applets. Hence no accessibility to local OS services beyond what's provided directly by the JVM.
Back to top
View user's profile Send private message
Michael Dag
PostPosted: Mon May 17, 2004 6:22 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

markt wrote:
People getting going with MQ for the first time did not understand why connections were failing, and hadn't got as far as reading about setmqaut in order to connect non-mqm userids.

There is no intermediate level choice - you could either have "mqm" or "none" as the selection, so "mqm" it had to be.

I don't know about locks, so why does everyone lock their door when they leave their home? I can't get in... that should change...
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
mqonnet
PostPosted: Mon May 17, 2004 6:31 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

"The idea of the Java client is that it is pure Java - no JNI is allowed. That way it can run in environments such as applets. Hence no accessibility to local OS services beyond what's provided directly by the JVM."
---Detailed answer near to this question is in the other thread in my latest post.

http://www.mqseries.net/phpBB2/viewtopic.php?t=15400&highlight=

I am not sure how java apps are different from java applets internally. But one things for sure, both of them make MQ api calls. Meaning, they call the methods within the MQ libraries.

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mqonnet
PostPosted: Mon May 17, 2004 7:49 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

I think i would say, i am still hesitant but am ok to close this thread. Since it looks like we are diverting too much from MQ and Security to the details of Java. :)

Thanks Jason, Roger, Peter & everyone for their insights though.

shogan2003, i would think you must have gotten a great deal out of this. And am sorry that your question was lost in the exchanges that we guys were having.

I would say you should go with what peter suggested in the other thread of using group/userids within the svrconn channel and NOT leave it blank. Also security exit would be the other alternative, though. :)

Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator
Back to top
View user's profile Send private message Send e-mail Visit poster's website
LearnMQSI
PostPosted: Mon Dec 27, 2004 1:18 am    Post subject: MQ_USER_ID and MQ_PASSWORD environment variables Reply with quote

Centurion

Joined: 20 Aug 2002
Posts: 137

Hi MQ Experts,

Is it possible to send MQ_USER_ID and MQ_PASSWORD environment variables in OS/2 Warp and UNIX platforms? or in Win98/WinNT/WinXP?


Thanks in advance for your light!!!
Back to top
View user's profile Send private message
EddieA
PostPosted: Mon Dec 27, 2004 9:51 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

Did you try reading the Client Manual.

Quote:
For WebSphere MQ clients on DOS, OS/2 Warp, Windows 3.1, Windows 95, and Windows 98, if a security exit is not defined, the values of two environment variables MQ_USER_ID and MQ_PASSWORD are transmitted to the server. The values are passed in the channel definition (MQCD) to the server security exit when the exit is invoked. The values can then be used by the exit to establish the identity of the WebSphere MQ client.

On these platforms, set the variables in the environment in which the WebSphere MQ client is going to run. Note that MYUSERID and MYPASSWORD must be in uppercase if the client is going to communicate with an WebSphere MQ server on OS/400. For example:

SET MQ_USER_ID=MYUSERID
SET MQ_PASSWORD=MYPASSWORD


Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4  Next Page 3 of 4

MQSeries.net Forum Index » General Discussion » security and clients
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.