Hi,

>  All the other channels are either locked down
> (MCAUSER set to a user that doesn't exist) or locked down to specific
> IPs using the BlockIP2 exit.

So basically you are trusting that an application is asserting an allowable 
UserId if it comes from a particular IP address?

Note: I'm NOT trying to be mean or anything but here's what I would do if your 
company hired me to do a security review of your MQ Environment:

- Since you are an MQ Admin, I would use your UserId.  email is '[EMAIL 
PROTECTED]', hence, most likely your UserId is 'dboger'

- Next I would go get SMAC or another Windows IP address spoofer program and 
set my IP address to a valid 'BlockIP' IP address 

- Next I would gain access to the QMgr on a client channel that is set up with 
BlockIP.

This would take me 5 maybe 10 minutes.  

My point is that you are replying on an untrusted client application to assert 
2 pieces of information (which can be faked) that will make it trusted.  As 
Spock would say: It's illegal.

 
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz


On Mon, 13 Nov 2006 09:58:43 -0500, "Boger, Dan" <[EMAIL PROTECTED]> wrote:
> The solution we have come up with is set the MCAUSER property on the
> SYSTEM.ADMIN.SVRCONN channel to a special user which is *not* a member
> of mqm.  Then, we grant that user the specific permissions we want to
> allow access to - viewing queues, messages (out of the production
> environment), etc.  All the other channels are either locked down
> (MCAUSER set to a user that doesn't exist) or locked down to specific
> IPs using the BlockIP2 exit.
>  
> Dan
> 
> ________________________________
> 
> From: MQSeries List [mailto:[EMAIL PROTECTED] On
> Behalf Of Joan A. Hughes
> Sent: Monday, November 13, 2006 9:05 AM
> To: [email protected]
> Subject: Re: Authorities and m071
> 
> 
> 
> Paul, 
>         I believe Roger was just pointing out how a developer would get
> around what I am trying to put in place.  By deleting the .aut file they
> would have all the additional functions that I have removed from the
> M071. 
> 
> My first goal was to provide the developers a way to view queues, queue
> depths, channel statuses, and messages.  Without allowing them logon
> rights to the Intel servers.     M071 seemed to be the perfect fit I
> have been using it for a couple of years and found it to be a great
> help.   
> 
> During testing I found that our developers were not able to connect to
> the servers with m071.  That's how this whole discussion started.  I
> found that If I added them to the MQM group the tool could connect but
> they still did not have logon to the servers.    As pointed out to me I
> would have been making things less secure by doing this, actually giving
> the developers more rights than needed.  ( these guys don't need a
> bigger noose to hang themselves with.....so that's out the door.) 
> 
> 
> If we go back to the main question......................How can I get
> developer's connected to these Intel Queue Managers with m071 without
> adding them to the MQM group.  It's only our Intel servers that are
> giving me this grief.  The iSeries QM's all connect fine. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Joan Hughes
> IT Technical Specialist
> IBM Certified System Administrator - WebSphere MQ, v5.3
> 608-827-3523 
> 
> 
> 
> Paul Clarke <[EMAIL PROTECTED]> 
> Sent by: MQSeries List <[email protected]> 
> 
> 11/13/2006 03:14 AM 
> Please respond to
> MQSeries List <[email protected]>
> 
> 
> To
> [email protected] 
> cc
> Subject
> Re: [MQSERIES] Authorities and m071
> 
>       
> 
> 
> 
> 
> Roger,
> 
> Can you explain why you would suggest deleting the MQMON.aut file ?
> 
> The aut file, as it explains in the manual, neither add additional
> security
> nor provides a bypass around any MQ security. However, what it does do
> is
> allow the administrator to tailor MO71 appearance for users. You can say
> "show the queue browse" dialog but not the "channel" dialogs etc. This
> can
> be useful to prevent users from seeing 'too complicated' an application
> or
> being tempted to press something they shouldn't. It can also reduce the
> risk of accidentally pressing the wrong button. Besides if you've set
> the
> MQ securities so that the user is not allowed to delete channels, define
> queues etc etc then what's the point of presenting the user an
> application
> which 'looks' like you can ?
> 
> Paul G Clarke
> WebSphere Messaging Clients
> IBM Hursley
> email : [EMAIL PROTECTED]
> Tel     : External   +44 (1962) 818201
> 
> 
> 
> 
>  
> 
>             Roger Lacroix
> 
>             <[EMAIL PROTECTED]
> 
>             PITALWARE.BIZ>
> To 
>             Sent by: MQSeries         [email protected]
> 
>             List
> cc 
>             <[EMAIL PROTECTED]
> 
>             V.MEDUNIWIEN.AC.A
> Subject 
>             T>                        Re: Authorities and m071
> 
>  
> 
>  
> 
>             12/11/2006 21:12
> 
>  
> 
>  
> 
>             Please respond to
> 
>               MQSeries List
> 
>             <[EMAIL PROTECTED]
> 
>             V.MEDUNIWIEN.AC.A
> 
>                    T>
> 
>  
> 
>  
> 
> 
> 
> 
> 
> Hi Joan,
> 
> As others have noted, your plan will not provide security for your queue
> managers.
> 
> Reason:
> 
> - The first thing I would do is delete your MQMON.aut file.
> - Second if my UserId is in the mqm group then I can do whatever I want,
> whenever I want.
> - Third, if my UserId is not in the mqm group then I would simply use
> MO71
> with the dummy client exit list here:
>  http://www.mqseries.net/phpBB2/viewtopic.php?t=21782
>  (This gives me 'mqm' UserId access.)
> 
> There are 3 solutions in the market place that will properly protect
> your
> MQ Environment:
> - Capitalware's MQ Authenticate User Security Exit
>  http://www.capitalware.biz/mqausx_overview.html
> - IBM's WebSphere MQ Extended Security Edition
> - IBM Tivoli's TAMBI
> 
> 
> Regards,
> Roger Lacroix
> Capitalware Inc.
> 
> 
> At 03:05 PM 11/9/2006, you wrote:
> 
>      Connecting M071 via a client.
> 
> 
> 
>      We are trying to roll out M071 to our developers, limiting their
>      authorities via a MQMON.aut file.    Our problem is not with
> limiting
>      their authorities within the M071,  that works great.  Our problem
> is
>      getting them connected to the queue manager.  The only way I have
>      been successful is by adding their individual id's to the mqm
> group.
>      A nested group did not work.
> 
>      I have to find another way as this would be a maintenance nightmare
>      having to manage these mqm groups on multiple servers with 80+
>      developers.
> 
>      I have included a copy of my mqmon.aut file.   Did I miss something
>      in there?   Anyone have any thoughts.
> 
>      Thanks in advance.
> 
> 
> 
> 
> 
>      Joan Hughes
>      IT Technical Specialist
>      IBM Certified System Administrator - WebSphere MQ, v5.3
>      608-827-3523
> 
> 
>          List Archive - Manage Your List Settings - Unsubscribe
> 
> 
> Instructions for managing your mailing list subscription are provided in
>    the Listserv General Users Guide available at http://www.lsoft.com
> 
> To unsubscribe, write to [EMAIL PROTECTED] and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
> 
> 
> 
> ________________________________
> 
> List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html>  -
> Manage Your List Settings
> <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>  -
> Unsubscribe
> <mailto:[EMAIL PROTECTED]&BODY=sign
> off%20mqseries>  
> 
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> <http://www.lsoft.com/resources/manuals.asp>  
> 
> 
> "MFS Relay Service" made the following
>  annotations on 11/13/06 09:58:42
> ------------------------------------------------------------------------------
> This email communication and any attachments may contain proprietary,
> confidential, or privileged information.  If you are not the intended
> recipient, you are hereby notified that you have received this email in
> error and that any review, disclosure, dissemination, distribution or
> copying of it or its contents is prohibited.  The sender does not waive
> confidentiality or any privilege by mistransmission.  If you have received
> this email in error, please notify the sender immediately, delete this
> email, and destroy all copies and any attachments.
> ==============================================================================
> 
> To unsubscribe, write to [EMAIL PROTECTED] and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
> 
> 

To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Reply via email to