| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| First, second, both or none of it? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Tue Dec 13, 2016 6:12 am Post subject: First, second, both or none of it? |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
I noticed that some 2035's are reported to MQ admins only in qmgr AMQERR logs, some only in a SYSTEM.ADMIN.QMGR.EVENT if AUTHOREV is turned on, a majority of them in both locations, and I hope there is no case that is reported in none of them. Is it a consistency theater, a security theater, both of them or none of them?
Not to mention that for some of them CHLEV must be turned on (for example set to EXCEPTION) in order for channel to place the event message into SYSTEM.ADMIN.CHANNEL.EVENT. A little bit of uniformity wouldn't hurt here, I mean, these are all 2035's, why reporting them so differently? I had an PMR open to discuss the subject, and IBM was acting very defensive claiming that to sort this out, an RFE is needed, ie, they don't consider it defective behaviour. To be precise, the scope of discussion was why is lack of inq permission only visible in AMQERR log, ie why it doesn't generate event messages.
There are other ways to notice 2035 (apart from getting notified by application stuff). One of them, very suboptimal one, is starting AAT that reports RC. In older versions, AAT was implemented as an exit that was putting to SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE, reading input configuration from mqat.ini, and all that. Are in v9 with enhanced activity trace available through publish/subscribe these things any better? Like, memory consumption of the old AAT is awful. I can start an amqsact to constantly drain SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE but I cannot let AAT activated for a long time, because amqzlaa0 size grows significantly, even though I try to narrow the scope of tracing. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Dec 13, 2016 6:23 am Post subject: Re: First, second, both or none of it? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jcv wrote: |
I noticed that some 2035's are reported to MQ admins only in qmgr AMQERR logs, some only in a SYSTEM.ADMIN.QMGR.EVENT if AUTHOREV is turned on, a majority of them in both locations, and I hope there is no case that is reported in none of them. Is it a consistency theater, a security theater, both of them or none of them?
Not to mention that for some of them CHLEV must be turned on (for example set to EXCEPTION) in order for channel to place the event message into SYSTEM.ADMIN.CHANNEL.EVENT. A little bit of uniformity wouldn't hurt here, I mean, these are all 2035's, why reporting them so differently? I had an PMR open to discuss the subject, and IBM was acting very defensive claiming that to sort this out, an RFE is needed, ie, they don't consider it defective behaviour. To be precise, the scope of discussion was why is lack of inq permission only visible in AMQERR log, ie why it doesn't generate event messages. |
Obviously you have done the research. Can you give an example of a 2035 that is reported one way but not the other? Or that needs chl event (exception) turned on?
I would expect that the ones needing chl event turned on are due to chlauth records... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Dec 13, 2016 6:48 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| You expect it right with regard to chlev, and I already wrote that a lack of inq authorization is logged only to AMQERR, failing to generate an authority event message, while for a lack of pub/sub authorizations is the other way around, at least is that so in v7.5. What is the result of your research in this area? |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Dec 13, 2016 7:52 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Considering my experience with a PMR about inq authorization, I didn't feel like opening a new one for topic authorizations.
However, I didn't configure any QMErrorLog stanza in qm.ini to suppress or exclude any messages, and when I remove authorizations for the topic, only authority event messages are generated, and nothing is written to AMQERR01.LOG. Event messages are like MQRQ_OPEN_NOT_AUTHORIZED for Topic String etc...
Do you see the same thing in v9, or what? Is it written somewhere in KC what lack of authorization causes what kind of report? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 13, 2016 11:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jcv wrote: |
Considering my experience with a PMR about inq authorization, I didn't feel like opening a new one for topic authorizations.
However, I didn't configure any QMErrorLog stanza in qm.ini to suppress or exclude any messages, and when I remove authorizations for the topic, only authority event messages are generated, and nothing is written to AMQERR01.LOG. Event messages are like MQRQ_OPEN_NOT_AUTHORIZED for Topic String etc...
Do you see the same thing in v9, or what? Is it written somewhere in KC what lack of authorization causes what kind of report? |
Don't remember reading anything specific in the KC. Might have missed it though... As for troubleshooting I always look at the logs and turn on the authority events. Turn those right back off after trouble shooting is done...
I guess if you're in a bigger shop with emphasis on forensics, you'd have the authority events always on and log them to a DB...
Depending on your security setup and the usage of your tools (MQE) this can get tedious pretty fast because of all the events just meaning working as expected / configured... do I dare call them false positives???
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Dec 14, 2016 12:49 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Yeah, sure, I do that too, I mean, look into both places (actually three places, but it could be two because I can define aliases and have one queue containing all 2035 event messages, not just for one qmgr even), because I learned that I have to. But the question is, do you find it normal? Consistency is mother of all security, and this is no report consistency:
lack of sub authorization => only event message
lack of inq authorization => only AMQERR01.LOG record
lack of get (for example) authorization => both
May I just ask, did you check my claims with respect to sub authorization? For inq I'm positive, because IBM confirmed it, that they don't think all kind of 2035's should generate event messages. But for sub I'm not sure did I (not very likely) overlook something. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 14, 2016 6:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jcv wrote: |
Yeah, sure, I do that too, I mean, look into both places (actually three places, but it could be two because I can define aliases and have one queue containing all 2035 event messages, not just for one qmgr even), because I learned that I have to. But the question is, do you find it normal? Consistency is mother of all security, and this is no report consistency:
lack of sub authorization => only event message
lack of inq authorization => only AMQERR01.LOG record
lack of get (for example) authorization => both
May I just ask, did you check my claims with respect to sub authorization? For inq I'm positive, because IBM confirmed it, that they don't think all kind of 2035's should generate event messages. But for sub I'm not sure did I (not very likely) overlook something. |
I would expect all of pub/sub to require +inq as it is a general requirement for JMS and pub/sub was first introduced as a JMS capability...
You should probably open either a PMR or if denied an RFE.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Dec 15, 2016 12:19 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Excuse me, I didn't quite get did you try that with removing +sub authorization? I'm sorry for being persistent, but I guess that's a quality of mine, I can't help myself. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
