| Author |
Message
|
| mqdogsbody |
 Posted: Fri Feb 18, 2011 6:14 am Post subject: |
 |
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| Vitor wrote: |
| mqdogsbody wrote: |
| So the silly thing is not making the value settable via the MQEnvironment class (or some other). |
Which would open the door to application A spoofing itself as application B. |
Well, yes: it would be "advisory" only, but since I can call my binary whatever I want that's already true. (I had "foo.bar" connected the other day.) And if all apps are "Websphere MQ Client for Java" you can't tell a good one from a bad one anyway! At least the spoofer would have to know an acceptable name if the name were settable.
In any case, given how the Java clases handle the user ID, I don't see that as an issue of any significance. (It's like worrying about an open window when the front door is wide open...)
| Vitor wrote: |
| Though with proper user security that shouldn't be an issue. |
In our dreams...
_________________
-- mqDB -- |
|
| Back to top |
|
 |
| mqdogsbody |
| Posted: Fri Feb 18, 2011 6:17 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| But in no way should MQ be responsible for what name a process using MQ code is reported as being. |
- Firstly, I have been suggesting it be settable (because I think it's not knowable)
- Secondly, that's what happens with C or C++ MQ client apps. The correct name appears without the app doing anything.
| mqjeff wrote: |
| And if you can honestly tell anything meaningful... |
Well, there's meaningful and meaningful...
It seems to me that know what the name of a process connected to one's QM might often be useful (even if it is "advisory" only). I presume someone at IBM does (or did) too, since they took the trouble to- provide the APPLTAG property and
- get it populated for C/C++ clients
| mqjeff wrote: |
| very strenuous controls over who gets to run which processes on which machines and who can compile any software or rename any files |
Well, actually we do. (Whether it's strenuous enough I will leave to the Audit Committee!)
But I am not looking at this as a security measure, more for its informational/diagnostic value.
| mqjeff wrote: |
| As has been said, despite your own unwillingness to believe it, best practices is to give every MQ client application it's own SVRCONN, |
I am not unwilling to believe it.
But I see a useful facility provided for C/C++ client and wonder why the same can't be provided for Java clients.
I think that's the key point. Why is a meaningful APPLTAG sensible for C/C++ but not sensible for Java?
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 18, 2011 6:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Again, given that I believe that there is a property on Runnable that can set this to something...
And i know that I've seen different values than "WebSphere MQ Client for Java" for java based applications - perhaps however only when using bindings connections...
The reality then is that either the JVM does not allow for an application to retrieve the name of the process name and it's only when using a bindings connection and therefore calling out to native code anyway that you see the java exectuable name, or that in certain cases java applications are clearing the value before MQ gets invoked, and such MQ has to use a default value because it's handed an empty one. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Feb 18, 2011 7:46 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| And i know that I've seen different values than "WebSphere MQ Client for Java" for java based applications - perhaps however only when using bindings connections... |
Interesting...
| mqjeff wrote: |
| The reality then is that either the JVM does not allow for an application to retrieve the name of the process name |
I suspect that's true. That's why I suggesting simply making it a writeable property of MQEnvironment, like userID.
| mqjeff wrote: |
| in certain cases java applications are clearing the value before MQ gets invoked, and such MQ has to use a default value because it's handed an empty one |
How can they do this? AFAIC the value is not accessible. (If it were accessible I wouldn't have an issue.)
I just want to be able to go
| Code: |
MQEnvironment.userID = "foo";
MQEnvironment.applicationTag = "bar"; |
(My researches suggest that the user ID and app tags are sent in the same packet so if one is available at the right time the other is.)
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 18, 2011 7:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqdogsbody wrote: |
I just want to be able to go
| Code: |
MQEnvironment.userID = "foo";
MQEnvironment.applicationTag = "bar"; |
(My researches suggest that the user ID and app tags are sent in the same packet so if one is available at the right time the other is.) |
Given that I can take "myevilprogram.exe" and rename it "amqsget0.exe", I don't see any realistic value in making business or technical decisions based on the application name at all.
But, again, if you think you can actually ensure that the names presented are meaningful and valid, then I agree that you would derive some value from this.
I wouldn't trust it, myself. But just my own opinion here. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Feb 18, 2011 8:17 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| Given that I can take "myevilprogram.exe" and rename it "amqsget0.exe"... |
True. (I pointed out this myself. See my response to Vitor.)
But the facility is there for C/C++, so I am not sure of the relevance of arguments saying it's a bad thing.
It's presumably not meant to be anything of a security mechanism but an informational/diagnostic aid.
And having had to answer questions about what's connected to a QM or what's got a queue open, I can imagine it might be useful. Obvously if myevilprogram.exe (or rather class my.evil.Program) is masquerading as something else I have got problems, but I am not sure those problems are made worse it being able to change its appltag from "WebSphere MQ Client for Java" to something else.
Now where's that MQ Requirement form?
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 18, 2011 8:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqdogsbody wrote: |
| Now where's that MQ Requirement form? |
here |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Feb 18, 2011 9:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqdogsbody wrote: |
| And indeed when I run (my own version) of amqsput I see (starting at byte FC) |
amqsput does not normally use the MQ Client Library. But amqsputc does. What happens with amqsputc? |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Feb 18, 2011 9:30 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| rekarm01 wrote: |
| mqdogsbody wrote: |
| And indeed when I run (my own version) of amqsput I see (starting at byte FC) |
amqsput does not normally use the MQ Client Library. But amqsputc does. What happens with amqsputc? |
Sorry this was misleading. This was a version of amqsputc, as shown by the the program name: amqsput0+mqA6c. (It's a long story but the "A" the "6" and the "c" are all significant. You can add "64" too!) It was because it was a "c" that I could spy on the packets!
The "s" version works as expected too:
| Code: |
CONN(4D5E91B620001001)
EXTCONN(414D5143504152444F454A3120202020)
TYPE(CONN)
APPLTAG(amqsput0+mqA6s) |
_________________
-- mqDB -- |
|
| Back to top |
|
|
|
|
