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: Fri May 14, 2004 9:39 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Here's what I did on the server - side :

I created group mqm4 and user mqm5, making mqm5 a member of mqm4

assigned put rights to a queue for mqm4, which I could see was inherited by mqm5

I then set up paths for mqm5, logged out then back in again for mqm5
I also created a password

I tried to put to that queue.using amqsput ... receive error message 2035
-------------------------------------------------------------------------------------
Then to check out the client I followed your advice and changed the MCAUSER to 'mqm5'

On the client - side I specified MQEnvironment.userID="mqm5" and MQEnvironment.password="mqm5" in my Java code (not JMS). Again, 2035.
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Fri May 14, 2004 10:08 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

You need more than just put rights for a client to put.

You gotta connect to the QM for one thing, so that id needs +connect on the QM.

Your probably better off just giving that ID +Allmqi to the queue manager and queues. Once you have that working, start removing things you don't want them to do (like -set).
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri May 14, 2004 10:31 am    Post subject: Reply with quote

Grand Master

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

Peter, as much as i want to agree to this, i really cannot.

"Bottom line: A SVRCONN with no MCAUSER (and no exit) has ZERO security"

---For the above to be infact "really" true, a user(client) who is trying to connect to an MQ server, should likely know all the userids that are hosted on the server system and their authorities so as to use the most appropriate one for his/her purpose from the client system. Why. Because, a blank within a svrconn channel doesnt mean that one would be granted "all" permissions by default, as is the perception.

The key to this whole point is altuser. If this is not set, then nobody can really do anything.

As for this,

"You are going to go thru all the trouble of running setmqaut commands against all those IDs, and then some clown comes along, defines a user called mqm on their machine, and connects to your QM"
---The only possible flaw would be if the user sets alternateuserid to be "mqm". Since one cannot create a user called mqm and logon as mqm on any mq installed machine.

But other than that, the security with a blank mcauser would work in the same way as if you had a specific user defined.

But yes, i do agree to your suggestion in totallity. And as you know, any design and features used in mq increases by width as you want more off it. :)

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
shogan2003
PostPosted: Fri May 14, 2004 10:41 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Thanks. I set +connect and the following scenario works :

Client
-------
Created user mqm5, member of group mqm4 but NOT of mqm
Set up paths etc.
Logged in as mqm5

Server
--------
server connection channel, attribute MCAUSER set to mqm5

Client
-------
amqsputc - OK

Now I need to figure out what authorisation params to use with setmqaut to run so that I can avoid 2035 when I invoke amqsput on the server itself, logged in as mqm5.
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Fri May 14, 2004 10:44 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

Quote:

---For the above to be infact "really" true, a user(client) who is trying to connect to an MQ server, should likely know all the userids that are hosted on the server system and their authorities so as to use the most appropriate one for his/her purpose from the client system. Why. Because, a blank within a svrconn channel doesnt mean that one would be granted "all" permissions by default, as is the perception.


If the client application is JAVA, and they don't bother to set the UserID property of the MQEnvironment class, AND the MCAUSER is blank, AND there is no exit to set a MCAUSER, you will run as the ID that started the channel, which was the Listener, which was started by mqm.

All other languages, the actual logged on UserID is always used. I have never tried it, but I don't see why you could not create a user called mqm, reboot, install MQClient, log in as mqm, and connect, flowing over mqm. Maybe this won't work, but it seems viable to me.

Regardless, the JAVA vulnerability is 100% true. A SVRCONN with no exit and a blank MCAUSER will allow a JAVA user to very easily connect as mqm if they so choose. Maybe its not NO security, but that is a pretty big hole, and since a chain is only as strong as its weakest link.....
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri May 14, 2004 11:17 am    Post subject: Reply with quote

Grand Master

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

"If the client application is JAVA, and they don't bother to set the UserID property of the MQEnvironment class, AND the MCAUSER is blank, AND there is no exit to set a MCAUSER, you will run as the ID that started the channel, which was the Listener, which was started by mqm."
---NO. I dont think thats right. You could very well check it out. Irrespective of the language, i would have thought the userid that is used for authentication is always the one that you are logged in as on the system you run the app from. So, be it a java app or a c app, if you are running it as a client and connecting to an MQ Server, your logged on userid is used for authorization purposes. At least thats whats my understanding.
In the above example, if you dont have a userid created on MQ Server system, mqconn will FAIL. Be it a java or c app.

"All other languages, the actual logged on UserID is always used"
---No again. Java or no java. MQ is not language dependent and MQ doesnt do anything funny under the covers if you use java.

"I have never tried it, but I don't see why you could not create a user called mqm, reboot, install MQClient, log in as mqm, and connect, flowing over mqm. Maybe this won't work, but it seems viable to me.
"
---You *cannot* create an "mqm" userid on any system that has MQ installed. Reason. Mq creates a group called "mqm". And o/s wouldnt allow you to recreate a user/group with the same name as the one that is already existing. Yes, case sensitivity may be a different case.

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: Fri May 14, 2004 11:41 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

Quote:

Java or no java. MQ is not language dependent and MQ doesnt do anything funny under the covers if you use java.


It is when it comes to this subject.

Please check out Chapter 7 of the MQClients manual, sub section Access Control. If an MQClient does not flow a User ID, and a JAVA MQClient app that does not set that Environment variable is the only MQ client that can pull this trick, then you will run as mqm (or MUSR_MQADMIN) if the MCAUSER is blank and there is no exit to override this.

And forget about the above for a sec. Whats to prevent the JAVA app from doing this:
MQEnvironment.UserID = "MUSR_MQADMIN" //connect to a Windows QM
or
MQEnvironment.UserID = "mqm" //connect to a UNIX QM



As far as logging on with mqm, I looked at a server with just MQClient installed. There is a GROUP called mqm, and a user called MUSR_MQADMIN. There is no user called mqm. But it fails if I try and create a USER called mqm. So maybe this is not a threat. I dunno. I wonder if the MQ Client install would work if you had an mqm or MUSR_MQADMIN user already defined???
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri May 14, 2004 11:53 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

By the way, what is really the problem is that the JAVA app does not send an ID up to the server, so you get this behaviour. Old versions of MQClients (5.0 and earlier I think) had this problem for ALL languages, not just JAVA.

Back then an MQServer install had the SYSTEM.DEF.SVRCONN channel automatically created with a bogus MCAUSER. So many people were complaing that MQClient were not working (they never bothered to read about the MCAUSER), that IBM at some point started creating the MCAUSER on the SYSTEM.DEF.SVRCONN as blank, fortunatly at about the same time that all but the JAVA clients were forced to always flow an ID.

At least that is the story I have heard whispered on the winds of the listserve.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri May 14, 2004 12:23 pm    Post subject: Reply with quote

Grand Master

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

Ok Peter, i would say i learnt something new today about java apps being able to connect without any restrictions. Hmm... :) I would then say that the bug/issue is with ONLY java apps being able to connect rather than SVRCONN channel blank. I know that under this and ONLY this circumstance it is a big security hole. But other than that, there is none. Looks like the way java bindings were built was to use a default identifier which incidently is mqm. Wonder why IBM chose to use it that way. I am pretty sure that there is some catch here. But i dont know what it is. :). IBM wont allow this security hole to be around. Just IMHO.

"As far as logging on with mqm, I looked at a server with just MQClient installed. There is a GROUP called mqm, and a user called MUSR_MQADMIN. There is no user called mqm. But it fails if I try and create a USER called mqm. So maybe this is not a threat. I dunno. I wonder if the MQ Client install would work if you had an mqm or MUSR_MQADMIN user already defined???"
---This is what i got in the manuals.
" If the local mqm group does not already exist on the local computer, it is created automatically when WebSphere MQ is installed"

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: Fri May 14, 2004 1:46 pm    Post subject: Reply with quote

Jedi Knight

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

Hi,

IBM took the position that since a Java / MQ running as an applet will not / may not have a UserID associated with it, then they would leave it up to the developer to code a correct one. An interesting concept but sense most develoeprs don't know about this, they don't code of it.

Also, if the developer does not code
Code:
MQEnvironment.userID="ABC";
or something, then the UserID field is BLANK. Hence, a blank UserID field causes the MCA to use its own UserID value if the MCA UserID field of the channel definition is also blank.

This is not something new OR special to Java. In previous versions of the MQ Client code, a blank UserID could also be genereted. Earlier releases of MQ on OS/2 had this problem.

To this day, on Windows 95/98/ME, if you start windows, don't log in and then don't set USERNAME environment when you run your MQ client program it will have a blank UserID field.

Years ago, even before joining Candle, I used to love to scarce MQAdmins who would proudly claim to have a secure MQ environment and in 5 minutes I could get / put messages to a queue. Those are great bets when you need your bar tab paid for.

Regard,
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: Fri May 14, 2004 3:41 pm    Post subject: Reply with quote

Grand Master

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

Roger, you are right. But what got me worried and is new to me is, Java doesnt seem to send the logged on userid accross. Rather it doesnt seem to send anything other than what is set either through the environment or within the app. And neither does MQ check what userid is coming in from a java app. Guess its always MUSR_MQADMIN or mqm. Because with a java app coded i can get in and connect/open queues. But an exactly similar C app, i cannot. Since a C app sends in logged in userid.

Looks to me as a very big hole in secuirty with the way java Bindings are developed around MQ.


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: Fri May 14, 2004 7:27 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7723

Quote:

I know that under this and ONLY this circumstance it is a big security hole. But other than that, there is none.


A chain is only as strong as its weakest link! You simply cannot leave the MCAUSER blank with no exit on a SVRCONN.

This is exactly why Jorgen included a very useful feature in BLOCKIP2, and that is if the exit sees that no ID was sent by the client, it sets it to "nobody", which of course then fails, instead of letting it default to mqm or MUSR_MQADMIN.

I really hope IBM fixes this. It doesn't need to be fixed on the Java Client side. It needs to be fixed on the channel side. Why oh why does IBM choose to default to mqm or MUSR_MQADMIN when there is no ID sent?Wouldn't it be just as easy to default it to "nobody", or "XYZ" if no ID is sent, and then WE can choose whether to give "nobody" or "XYZ" authority?


Quote:

---This is what i got in the manuals.
" If the local mqm group does not already exist on the local computer, it is created automatically when WebSphere MQ is installed"


What I wonder is if I create the MUSR_MQADMIN ID first, and thus set the password to something I know, and then install MQClient on the Windows box, maybe I will be able to log off my real ID, log on with MUSR_MQADMIN, start any language MQCLIENT app, and try and connect. I wonder if the QM will then see me as MUSR_MQADMIN, and let me in, even for a C app? I'll give it a shot Monday, unless someone knows that this possibly cannot work.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
shogan2003
PostPosted: Sat May 15, 2004 3:40 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

Has anyone coded Perl client code ? Is the userID checked ?
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
shogan2003
PostPosted: Sat May 15, 2004 4:20 am    Post subject: Reply with quote

Centurion

Joined: 03 Jul 2003
Posts: 133
Location: London

As the adapters on the Solaris clients are written in Java,
I think I'll have to use a security exit but only install it on the server.
If the message arrives without a userId or with userId=mqm, then reject.
The userId and password in the MQEnvironment would be checked against a table of authorised users.

I don't have the code for this, although I know that is the approach taken to remedy holes in MQSeries Explorer security.
_________________
MQSI2 certified specialist
MQSeries certified specialist
Back to top
View user's profile Send private message Send e-mail
mqonnet
PostPosted: Sat May 15, 2004 5:48 am    Post subject: Reply with quote

Grand Master

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

"A chain is only as strong as its weakest link! You simply cannot leave the MCAUSER blank with no exit on a SVRCONN.
"

---I still am stuck with all my statements and can PROVE you that this is not the fact. And that this is a security hole ONLY in the case of java client apps connecting to mq server.

There is NO difference in the way you use SVRCONN. Be it blank or specifying a userid. Eventually it will go ahead and verify the authorizations on an object using this userid.

And I repeat again, blank SVRCONN seems to be a bad choice with a big security hole ONLY while using java clients. Since java doesnt seem to send the logged on userid, which is what any other app written in any other language does.

"I really hope IBM fixes this"
---As i mentioned earlier, there must be some strong reasoning behind why java clients behave this way. Its only matter of time we find out. I doubt IBM wouldnt know what we are talking about, already.

"It doesn't need to be fixed on the Java Client side. It needs to be fixed on the channel side."
---As i mentioned earlier, i can PROVE that this is ONLY to do with Java clients and none other. We can talk off the thread if you wish. :)

"Why oh why does IBM choose to default to mqm or MUSR_MQADMIN when there is no ID sent"
---As i said in one of my earlier posts, i knew that this is how it was working, but whats new to me is that Java App does NOT send the logged on userid. Because thats what one would expect to be going through.

"I wonder if the QM will then see me as MUSR_MQADMIN, and let me in, even for a C app? I'll give it a shot Monday, unless someone knows that this possibly cannot work."
---I am not sure of this either. But i would think if MUSER_MQADMIN is used, you should be able to connect. But again, i am not sure how would the install go, and other associated caveats that you pointed out.

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
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4  Next Page 2 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.