Pavel (and others) Here's what the issue is. There are some queues which contain configuration data for our product. We'd normally expect the MQ admin to manage these. However a particular customer has said that they don't want the MQ admins to be able to have any more rights on these queues than a normal user (browse access only). Instead they only want a designated user to be able to change the data on these queues.
>From my experiments and what people are saying, it would appear that mqm can do anything regardless of what has been done with setmqaut (this is probably different on MVS, as the MQ admins there won't typically have RACF authority except possibly group special). This leads me to think that this customer is SOL. PS Yes, I know we COULD do something using an API crossing exit with a hard coded check for the queue name(s) and the user opening them, but of course mqm user could readily remove any such exit ... Dave -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: 09 July 2003 18:39 To: [EMAIL PROTECTED] Subject: Re: Using setmqaut Thanks David, Rebecca: Basically, I agree with all Rebecca said about limiting access in general: that's why we try not to work under root account on Unix, even if we have it; in the particular case, however, I implicitly assumed David was seeking to actually prohibit users in mqm group from accessing a queue; I should have probably asked first. I also made my check (on AIX system) and found that setmqaut cannot deprive mqm group of its ability to access queues (checked with dspmqaut: -all does not change mqm's unlimited rights). I was wrong in my previous mail : mqm *is* on the list from the beginning; and it cannot be removed (at least I could not). I also agree that, from security administration point of view, the argument of accountability is used (and misused) pretty often especially when they cannot offer some technically sound solution for a difficult problem, like providing keystore passphrases for unattended servers (MQ's CMS keystore is not an exception -- another reason why you may want to keep most users out of mqm group). Once I had to scramble (of course, not to encrypt -- with what password?) such a phrase for these guys who earnestly beleived that using 'od' on encrypted password file or 'vi' or 'view' on a script in which did the scrambling would look much more fishy in their logs than using 'view' or 'vi' on an unencrypted file (and whom they want to hide the password from? -- from the very user who was supposed to enter it at the first place!). Back to David's problem, I do not see any greater chances for the user allowed in mqm group to be caught for running setmqaut (why else he would be allowed there?) than for running the application capable to access a queue (why would s/he do it if s/he is supposed to administer?). Also, on Unix, playing around with MQ installation (you would have to change the binary permissions that are r-sr-s--- for setmqaut after installation) might make the work IBM technical support, should you need it, more difficult. I always try to avoid that. Actually, I had to play with this unnatural (MQ+security on distributed systems) combination quite a bit, so, if David tells us in more details what he wants to achieve, there is a chance I have some more or less proven recipe (for Unix or Windows platform only). Thanks for reading this far :-), Pavel "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: > Subject: Re: Using setmqaut Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 07/09/2003 11:56 AM Please respond to MQSeries List Pavel, while it may seem somewhat counterintuitive, it's not terribly uncommon for a user who can change security access to something to not have access to that thing. Yes, they can change the access, but the hope is that this would be caught through some sort of reporting/logging. The other advantage of doing this is that it prevents accidental modification of some critical queue data; if you needed to do those modifications, you would at that time do the setmqaut and then turn it back off when you're done. This may not be irrelevant here anyway. Since setmqaut sets access at the group level and, I presume, you could set the permissions on setmqaut so that group could not run it while the owner could, it would be possible to stop a user in the mqm group, but is not mqm himself, from running setmqaut to reset permissions. Just my take on this issue, based on doing other security stuff that's not MQ... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -----Original Message----- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: Re: Using setmqaut David, First, I seems to me I tried all those tricks while ago and found mqm is a God. Second, logically mqm is not in the ACLs from the very beginning (check with dspmqaut), so deleting him from there should not change anything (just an educated guess) Third, even assuming mqm could be deleted from .. whatever, why whould s/he be able to add him/herself back .. there.. using that very setmqaut? (another educated guess). All those considerations are valid for Unix and (if I am not mistaken) Windows. I am not sure about other platforms. Hope this will help, Pavel "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Re: Using setmqaut Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 07/09/2003 10:17 AM Please respond to MQSeries List Rick, Hmmm... that sounds like it *is* possible, but use at your own risk - can anyone confirm? Thanks David Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ************************************************************************** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
