Re: MVS Command Authorization
>Peter, I can only speak for the products I've developed and how we >implemented command security. Also, I might add that years ago I >found a spreadsheet someone had at SHARE that listed each OPERCMDS >entities.That could be used as a foundation to know which commands >are verified. Gary, I'm not so much interested in the "which" than in the "how". What you said about your "own" subsystem commands somehow confirms my undestanding. But I still do not see how MGCEFAST can be useful to anything than pure "MVS commands", provided my understanding as posted is still correct. If MGCEFAST is set by sysplex command routing, and if the bit says "don't broadcast on the SSI", then how could a subsystem catch its command on the remote system? And, how can it suppress command authorization checking, when the mechanism is subsystem specific? Ok, I think I'll have to include sysplex processing and see if I got this right (this is pure curiosity): A command entered into the system through SVC 34 can be: a) a native MVS command (this includes the ROUTE command) b) a command beginning with a registered command prefix c) a command beginning with a *non*-registered command prefix SVC 34 sends the command to the commiunications task which in turn tries to get the command processed by whomever as follows 1) Each command is presented to command exits, if any are installed. - If any exit indicates the command was processed, that's it, no further processing is done. 2) If the command starts with a registered prefix, then it is routed to the target system (if not already here). On the target system, the command is issued again (SVC 34) and begins its journey again at 1) above. 3) If the command passes the exit(s) without being processed, it is presented to the subsystem command routines listening on the SSI. - If the command begins with *non-registered* prefix *and* ... ... the target subsystem is active, its routine will catch the command, process it and indicate this upon return. Processing ends here, i.e. not further broadcasting occurs. ... the target subsystem is not active, the command remains unprocessed, next SSI routine will see it. - If the command begins with a *registered* prefix *and* ... ... the target subsystem is active, its routine will catch and process the command. Processing then ends here. ... the target subsystem is not active, the CPF should have been deleted (in which case we don't end up here) or has been directed to another system (in which case we again won't end up here). - If the command has not been processed by a subsystem it "falls through" SSI broadcast processing and is send to "MVS" (see 4). 4) If it is a ROUTE command, the ROUTE command processor strips off the ROUTE and sends the command to the target system(s) where it is reissued by SVC 34 and starts its journey at 1) above on each target system. 5) If it is not a ROUTE command, the MVS command processor analyzes the command and, if valid, processes it. These are the commands described in the "MVS System Commands" manual plus some additional non-MVS commands like "Z NET...", "D NET..." which VTAM managed to incorporate into the "MVS Command Processor". 6) Message IEE305I COMMAND INVALID is issued if the MVS command processor did not recognize it. Where does MGCEFAST fit into the picture? Anyone dare to say I'm wrong ;-) I *hope* you do, and tell me where I'm wrong. Better yet, tell me the truth. -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
>The only place I've seen MGCEFAST documented is at: >http://tinyurl.com/2bn87q Yeah... I've seen this, too, but I don't consider that to "be documented". -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Scott. I hope you don't lose any sleep over this and I'm somewhat sorry that I stirred up the mud on this "out-of_the_closet" bit even though it's documented enough to describe what it does. But overall, I'm glad I know about it. Owe you a beer at SHARE if I ever attend again... :-) George Fogg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Scott Fagen Sent: Tuesday, December 11, 2007 5:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MVS Command Authorization On Tue, 11 Dec 2007 12:29:46 -0800, George Fogg <[EMAIL PROTECTED]> wrote: --snip-- I also don't want vendor >products and in-house EMCS code setting this bit to bypass security checking. >I don't have a problem with its intended purpose as Scott Fagen indicated. >George Fogg --snip-- In retrospect, it was probably a _bad_ idea to make such a function available on the external. At the time (ca 1988/9), I was still pretty wet behind the ears and was just doing what the team leader asked. In retrospect, the _right_ answer probably should have been a non-externalized service/entry into command processing that the sysplex code just dropped the command into, rather than setting a wacky bit on in the parameter list and re-issuing SVC34. Probably looks weird in system trace, too. Scott Fagen Enterprise Systems Management -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
On Tue, 11 Dec 2007 12:29:46 -0800, George Fogg <[EMAIL PROTECTED]> wrote: --snip-- I also don't want vendor >products and in-house EMCS code setting this bit to bypass security checking. >I don't have a problem with its intended purpose as Scott Fagen indicated. >George Fogg --snip-- In retrospect, it was probably a _bad_ idea to make such a function available on the external. At the time (ca 1988/9), I was still pretty wet behind the ears and was just doing what the team leader asked. In retrospect, the _right_ answer probably should have been a non-externalized service/entry into command processing that the sysplex code just dropped the command into, rather than setting a wacky bit on in the parameter list and re-issuing SVC34. Probably looks weird in system trace, too. Scott Fagen Enterprise Systems Management -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Peter, I can only speak for the products I've developed and how we implemented command security. Also, I might add that years ago I found a spreadsheet someone had at SHARE that listed each OPERCMDS entities. That could be used as a foundation to know which commands are verified. If an OEM product uses the SSI (as we do with CA Tape Encryption) our subsystem is responsible for picking off the command and performing what action is required (we don't leave a WTOR for communications). Once the command has been found in the SSI, we perform a RACROUTE to see if the user (using that term in the most general sense) has access to the command. If a customer defined an OPERCMDS entity BES.DISPLAY UACC(NONE) and does not have the supporting code in place (in this case the CA Tape Encryption SAF Interface) then the entity is never verified. Again, I didn't mean to go start such a debate over my response yesterday. I just wanted to make sure the original poster reviewed their product's documentation. Regards, Gary You see me confused. Either I'm missing some recent change or, I have never understood how comand processing really works and am just about to discover this... This is my understanding (leaving out sysplex routing to drop that level of complexity): - SVC 34 (MGCR, MGCRE) is the programming interface to issue commands. It verifies the arguments and sends the command onto its journey through the system. No command authorization processing done yet. - The commands are presented to the SSI command listener routines (SSI function 10) in subsystem sequence, on after the other. - Finally the command is queued to the MVS command handler. SSI processing: - Each subsytem interested in commands sees each and every command (unless MGCEFAST has been set). - When a subsystem detects on if its commands, it marks it as "processed" (and of course, does whatever needs to be done to process the command). - When a subsystem sees a command marked "processed" it ignores the command. MVS command handler: - When the MVS command handler sees a command marked "processed" it ignores it. Otherwise it tries to interpret it as an MVS command (one of those commands described in the "MVS System Commands" manual). If this is correct, then neither SVC34 nor the MVS command handler can do authorization checking for subsystem commands. Each subsystem is responsible to do its own authorization checking (if at all). Again if this is correct, MGCEFAST can never be set for a "non-MVS" command, i.e. a command recognized by a SSI command listener, since it is "suppressing SSI" (BTW, I haven't found where MGCEFAST is documented.) Happy to learn where I'm wrong and how it really works. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
On Tue, 11 Dec 2007 12:29:46 -0800 George Fogg <[EMAIL PROTECTED]> wrote: :>> On Mon, 10 Dec 2007 15:38:58 -0800 George Fogg <[EMAIL PROTECTED]> wrote: :>> :>OK, MGCEFAST has a purpose in certain conditions but I could set this bit on :>> :>in a simple MGCRE call to issue a command without using CPF and CMDSYS :>> :>processing and it will bypass the command exits and CMDAUTH (OPERCMDS :>> :>checking)processing? :>> :>I agree this not apporiate but I'm just curious if it would work. :>> :>Just another goodie to add to my "gosh, that's interesting" list. :>> As the MGCR(E) issuer is supervisor state, it is perfectly legitimate for it :>> to indicate that security be bypassed. :>Not in our shop. :>We have 25+ site written commands processed in the command exit if if MGCEFAST :>bypasses the command exit then they won't work. I also don't want vendor :>products and in-house EMCS code setting this bit to bypass security checking. Then you should audit your supervisor state programs. I am not stating that it is a good idea to set the bit, just that allowing the MGCR(E) to bypass security is NOT an exposure as it is in supervisor state and thus can directly do what the issued command would do. :>I don't have a problem with its intended purpose as Scott Fagen indicated. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
> On Mon, 10 Dec 2007 15:38:58 -0800 George Fogg <[EMAIL PROTECTED]> wrote: > > :>OK, MGCEFAST has a purpose in certain conditions but I could set this bit on > :>in a simple MGCRE call to issue a command without using CPF and CMDSYS > :>processing and it will bypass the command exits and CMDAUTH (OPERCMDS > :>checking)processing? > :>I agree this not apporiate but I'm just curious if it would work. > :>Just another goodie to add to my "gosh, that's interesting" list. > > As the MGCR(E) issuer is supervisor state, it is perfectly legitimate for it > to indicate that security be bypassed. Not in our shop. We have 25+ site written commands processed in the command exit if if MGCEFAST bypasses the command exit then they won't work. I also don't want vendor products and in-house EMCS code setting this bit to bypass security checking. I don't have a problem with its intended purpose as Scott Fagen indicated. George Fogg > > -- > Binyamin Dissen <[EMAIL PROTECTED]> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
On Mon, 10 Dec 2007 15:38:58 -0800 George Fogg <[EMAIL PROTECTED]> wrote: :>OK, MGCEFAST has a purpose in certain conditions but I could set this bit on :>in a simple MGCRE call to issue a command without using CPF and CMDSYS :>processing and it will bypass the command exits and CMDAUTH (OPERCMDS :>checking)processing? :>I agree this not apporiate but I'm just curious if it would work. :>Just another goodie to add to my "gosh, that's interesting" list. As the MGCR(E) issuer is supervisor state, it is perfectly legitimate for it to indicate that security be bypassed. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
>Peter said: snip > Again if this is correct, MGCEFAST can never be set for a "non-MVS" > command, i.e. a command recognized by a SSI command listener, since > it is "suppressing SSI" (BTW, I haven't found where MGCEFAST is > documented.) > > Happy to learn where I'm wrong and how it really works. > The only place I've seen MGCEFAST documented is at: http://tinyurl.com/2bn87q George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
You see me confused. Either I'm missing some recent change or, I have never understood how comand processing really works and am just about to discover this... This is my understanding (leaving out sysplex routing to drop that level of complexity): - SVC 34 (MGCR, MGCRE) is the programming interface to issue commands. It verifies the arguments and sends the command onto its journey through the system. No command authorization processing done yet. - The commands are presented to the SSI command listener routines (SSI function 10) in subsystem sequence, on after the other. - Finally the command is queued to the MVS command handler. SSI processing: - Each subsytem interested in commands sees each and every command (unless MGCEFAST has been set). - When a subsystem detects on if its commands, it marks it as "processed" (and of course, does whatever needs to be done to process the command). - When a subsystem sees a command marked "processed" it ignores the command. MVS command handler: - When the MVS command handler sees a command marked "processed" it ignores it. Otherwise it tries to interpret it as an MVS command (one of those commands described in the "MVS System Commands" manual). If this is correct, then neither SVC34 nor the MVS command handler can do authorization checking for subsystem commands. Each subsystem is responsible to do its own authorization checking (if at all). Again if this is correct, MGCEFAST can never be set for a "non-MVS" command, i.e. a command recognized by a SSI command listener, since it is "suppressing SSI" (BTW, I haven't found where MGCEFAST is documented.) Happy to learn where I'm wrong and how it really works. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
George Fogg wrote: OK, MGCEFAST has a purpose in certain conditions but I could set this bit on in a simple MGCRE call to issue a command without using CPF and CMDSYS processing and it will bypass the command exits and CMDAUTH (OPERCMDS checking)processing? Yes. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
> Edward Jaffe wrote: > >>George Fogg wrote: >>> Seems like MGCEFAST is kind of like RACF truested where authority exits are >>> bypassed and 99% of authority checks are passed just for issuing commands > from >>> MGCRE. >>> >>> MGCEFAST = Bypass SSI, command exits, and CMDAUTH. >>> >> >>MGCEFAST should be used only when that processing has already been done. > > Precisely, Ed. MGCEFAST was created for things like cross system CPF and > CMDSYS processing to prevent such 'extra' processing. Checking and auditing > twice wouldn't be too useful (and might be confusing!). Even worse would be > the possibility of a command being infinitely routed about the sysplex as a > command exit continually changed and caused the command to be forwarded > elsewhere... OK, MGCEFAST has a purpose in certain conditions but I could set this bit on in a simple MGCRE call to issue a command without using CPF and CMDSYS processing and it will bypass the command exits and CMDAUTH (OPERCMDS checking)processing? I agree this not apporiate but I'm just curious if it would work. Just another goodie to add to my "gosh, that's interesting" list. George Fogg > > Since MGCRE is an authorized service, enabling users to decide whether or > not such things are done is appropriate, since an authorized task could > likely do anything it wanted in determining its own security environment > (both for SAF and default MCS checking). > > Scott Fagen > Enterprise Systems Mangement > (and one-time coder of MGCEFAST) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Pinnacle wrote: Referee Scott Fagen halts the contest at 2:30 of the 3rd round, for the winner by TKO and STILL champen, Ki Jaee! Tom, maybe it's time to cut back a bit on the caffeine. ;-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Maybe I shouldn't say anything after Scott, however I'll dare to. I don't know "guts" of subsytems and commands, but I know more or less how RACF (or ACF) protection works for them: If we're talking about MVS commands, I mean START, STOP, CANCEL, FORCE, MODIFY - all those commands *are* protected, despite of application design. If we're talking about "CMDPRFX command" , then it is up to the application whether SAF is called or not. Subsystems like SDSF, RACF, MQ, JES2, STK HSC use their own command prefix and do call SAF for authorization. It can be, but need not to be OPERCMDS class resource. Others, like DB2 (older versions) do not call SAF. Many subsystems/applications, like CICS, BMC ControlM, VTAM, RMM, HSM do not use its own command prefix - all the control is provided through MODIFY/other commands. In such case relevant OPERCMDS profile will always be called. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Referee Scott Fagen halts the contest at 2:30 of the 3rd round, for the winner by TKO and STILL champen, Ki Jaee! - Original Message - From: "Scott Fagen" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Monday, December 10, 2007 4:43 PM Subject: Re: MVS Command Authorization Edward Jaffe wrote: George Fogg wrote: Seems like MGCEFAST is kind of like RACF truested where authority exits are bypassed and 99% of authority checks are passed just for issuing commands from MGCRE. MGCEFAST = Bypass SSI, command exits, and CMDAUTH. MGCEFAST should be used only when that processing has already been done. Precisely, Ed. MGCEFAST was created for things like cross system CPF and CMDSYS processing to prevent such 'extra' processing. Checking and auditing twice wouldn't be too useful (and might be confusing!). Even worse would be the possibility of a command being infinitely routed about the sysplex as a command exit continually changed and caused the command to be forwarded elsewhere... Since MGCRE is an authorized service, enabling users to decide whether or not such things are done is appropriate, since an authorized task could likely do anything it wanted in determining its own security environment (both for SAF and default MCS checking). Scott Fagen Enterprise Systems Mangement (and one-time coder of MGCEFAST) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Edward Jaffe wrote: >George Fogg wrote: >> Seems like MGCEFAST is kind of like RACF truested where authority exits are >> bypassed and 99% of authority checks are passed just for issuing commands from >> MGCRE. >> >> MGCEFAST = Bypass SSI, command exits, and CMDAUTH. >> > >MGCEFAST should be used only when that processing has already been done. Precisely, Ed. MGCEFAST was created for things like cross system CPF and CMDSYS processing to prevent such 'extra' processing. Checking and auditing twice wouldn't be too useful (and might be confusing!). Even worse would be the possibility of a command being infinitely routed about the sysplex as a command exit continually changed and caused the command to be forwarded elsewhere... Since MGCRE is an authorized service, enabling users to decide whether or not such things are done is appropriate, since an authorized task could likely do anything it wanted in determining its own security environment (both for SAF and default MCS checking). Scott Fagen Enterprise Systems Mangement (and one-time coder of MGCEFAST) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
George Fogg wrote: Seems like MGCEFAST is kind of like RACF truested where authority exits are bypassed and 99% of authority checks are passed just for issuing commands from MGCRE. MGCEFAST = Bypass SSI, command exits, and CMDAUTH. MGCEFAST should be used only when that processing has already been done. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
> Gregory, Gary G wrote: >> That is true but if the application is NOT passing the UTOKEN or using >> the macro that requires the commands be defined in OPERCMDS then that >> won't work. > > I'm not sure I follow you here... > > Most of the time, passing UTOKEN is unnecessary. For example, MGCRE > issued from a TSO session does not need to pass UTOKEN. It's only in > more exotic situations, e.g., multiuser address spaces, where the > differentiation is required. Some products, like (E)JES, always pass a > UTOKEN because they want to differentiate between commands explicitly > entered by the user and those generated by the product to affect a > resource protected by other means. This is an above-and-beyond feature > of mature, robust products and is by no means a requirement to make > OPERCMDS work. > > OTOH, "using the macro that requires the commands be defined in > OPERCMDS" is not optional. That macro, called MGCRE, is the mechanism by > which programs enter commands into the system. And, the program doesn't > do anything special to cause its commands to be validated against > OPERCMDS resources. CMDAUTH is issued by the system automatically > unless, as I stated earlier, MGCEFAST is set by the MGCRE issuer. > Ed. Looks like MGCEFAST will bypass command authority checking in the OPERCMDS class and also bypass the CONSOLE AUTH(xx) settings in the CONSOLxx parmlib member and the AUTH() setting in the user's OPERPARM segment plus bypass command exits and SSI--whatever that means. Seems like MGCEFAST is kind of like RACF truested where authority exits are bypassed and 99% of authority checks are passed just for issuing commands from MGCRE. MGCEFAST = Bypass SSI, command exits, and CMDAUTH. George Fogg >> I was only suggesting they refer to the documentation to >> see if commands are defined in other resource classes. The CMDAUTH >> macro requires that all entities be defined in OPERCMDS. >> > > This might be the root source of confusion for this discussion. When > someone says "MVS commands", I think of commands documented in the "MVS > System Commands" book, i.e. those that can be issued from an MCS > console. Such commands are subject to checking against resources in the > OPERCMDS class. > > Obviously, other commands, not defined in "MVS System Commands", would > be subject to whatever security checking is appropriate for the command > and the product that defines it. I think this may be the point you're > trying to make. If so, I agree with that aspect of your statement. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 310-338-0400 x318 > [EMAIL PROTECTED] > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Ed, Your paragraph " Obviously, other commands, not defined in "MVS System Commands", would be subject to whatever security checking is appropriate for the command and the product that defines it." Is exactly what I was trying to point out. Not all OEM (once again I state OEM) products use CMDAUTH/OPERCMDS combination some have their entities residing within another resource class or don't even support or attempt to support command protection. I was trying to indicate that for OEM products customers should refer to the product's documentation to see (1) if command protection is supported and (2) what steps are necessary to define/invoke command protection. Gary Garland Gregory, MS CA Senior Software Engineer/Developer - CA Tape Encryption Tel: +1-214-473-1863 Fax: +1-214-473-1050 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, December 10, 2007 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MVS Command Authorization Gregory, Gary G wrote: > That is true but if the application is NOT passing the UTOKEN or using > the macro that requires the commands be defined in OPERCMDS then that > won't work. I'm not sure I follow you here... Most of the time, passing UTOKEN is unnecessary. For example, MGCRE issued from a TSO session does not need to pass UTOKEN. It's only in more exotic situations, e.g., multiuser address spaces, where the differentiation is required. Some products, like (E)JES, always pass a UTOKEN because they want to differentiate between commands explicitly entered by the user and those generated by the product to affect a resource protected by other means. This is an above-and-beyond feature of mature, robust products and is by no means a requirement to make OPERCMDS work. OTOH, "using the macro that requires the commands be defined in OPERCMDS" is not optional. That macro, called MGCRE, is the mechanism by which programs enter commands into the system. And, the program doesn't do anything special to cause its commands to be validated against OPERCMDS resources. CMDAUTH is issued by the system automatically unless, as I stated earlier, MGCEFAST is set by the MGCRE issuer. > I was only suggesting they refer to the documentation to > see if commands are defined in other resource classes. The CMDAUTH > macro requires that all entities be defined in OPERCMDS. > This might be the root source of confusion for this discussion. When someone says "MVS commands", I think of commands documented in the "MVS System Commands" book, i.e. those that can be issued from an MCS console. Such commands are subject to checking against resources in the OPERCMDS class. Obviously, other commands, not defined in "MVS System Commands", would be subject to whatever security checking is appropriate for the command and the product that defines it. I think this may be the point you're trying to make. If so, I agree with that aspect of your statement. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Gregory, Gary G wrote: That is true but if the application is NOT passing the UTOKEN or using the macro that requires the commands be defined in OPERCMDS then that won't work. I'm not sure I follow you here... Most of the time, passing UTOKEN is unnecessary. For example, MGCRE issued from a TSO session does not need to pass UTOKEN. It's only in more exotic situations, e.g., multiuser address spaces, where the differentiation is required. Some products, like (E)JES, always pass a UTOKEN because they want to differentiate between commands explicitly entered by the user and those generated by the product to affect a resource protected by other means. This is an above-and-beyond feature of mature, robust products and is by no means a requirement to make OPERCMDS work. OTOH, "using the macro that requires the commands be defined in OPERCMDS" is not optional. That macro, called MGCRE, is the mechanism by which programs enter commands into the system. And, the program doesn't do anything special to cause its commands to be validated against OPERCMDS resources. CMDAUTH is issued by the system automatically unless, as I stated earlier, MGCEFAST is set by the MGCRE issuer. I was only suggesting they refer to the documentation to see if commands are defined in other resource classes. The CMDAUTH macro requires that all entities be defined in OPERCMDS. This might be the root source of confusion for this discussion. When someone says "MVS commands", I think of commands documented in the "MVS System Commands" book, i.e. those that can be issued from an MCS console. Such commands are subject to checking against resources in the OPERCMDS class. Obviously, other commands, not defined in "MVS System Commands", would be subject to whatever security checking is appropriate for the command and the product that defines it. I think this may be the point you're trying to make. If so, I agree with that aspect of your statement. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
That is true but if the application is NOT passing the UTOKEN or using the macro that requires the commands be defined in OPERCMDS then that won't work. I was only suggesting they refer to the documentation to see if commands are defined in other resource classes. The CMDAUTH macro requires that all entities be defined in OPERCMDS. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, December 10, 2007 10:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MVS Command Authorization Gregory, Gary G wrote: > That's assuming the OEM product issues the RACROUTE call to verify the > user has access to the command. > No. The system issues the CMDAUTH call when processing the command unless MGCEFAST is set in the MGCRE parameter list. The only responsibility of any product issuing MGCRE is to pass the correct UTOKEN in the event that the implicit mechanism used by the system will choose the "wrong" one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Gregory, Gary G wrote: That's assuming the OEM product issues the RACROUTE call to verify the user has access to the command. No. The system issues the CMDAUTH call when processing the command unless MGCEFAST is set in the MGCRE parameter list. The only responsibility of any product issuing MGCRE is to pass the correct UTOKEN in the event that the implicit mechanism used by the system will choose the "wrong" one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
That's assuming the OEM product issues the RACROUTE call to verify the user has access to the command. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Sunday, December 09, 2007 9:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: MVS Command Authorization Phillips, Peter wrote: > We are looking at tightening control over MVS command authorization. We > are a JES3 shop running Flasher, Omegamon, Solve etc. with ACF2. Of > course we have batch production jobs streams, operators, MVS sysprogs > all issuing MVS commands at different times and in different situations. > > Our management would like two keys areas addressed, firstly how to best > control who can issue commands MVS commands and secondly once the > command is issued how to best track and note that the command has been > issued. > > I assume control of MVS command issuing is a fairly common requirement > so I was hoping people could pass on the benefit their wisdom and > knowledge and how they have seen this done. > Take a look at activating the OPERCMDS class in your security product. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MVS Command Authorization
Phillips, Peter wrote: We are looking at tightening control over MVS command authorization. We are a JES3 shop running Flasher, Omegamon, Solve etc. with ACF2. Of course we have batch production jobs streams, operators, MVS sysprogs all issuing MVS commands at different times and in different situations. Our management would like two keys areas addressed, firstly how to best control who can issue commands MVS commands and secondly once the command is issued how to best track and note that the command has been issued. I assume control of MVS command issuing is a fairly common requirement so I was hoping people could pass on the benefit their wisdom and knowledge and how they have seen this done. Take a look at activating the OPERCMDS class in your security product. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MVS Command Authorization
Hi, We are looking at tightening control over MVS command authorization. We are a JES3 shop running Flasher, Omegamon, Solve etc. with ACF2. Of course we have batch production jobs streams, operators, MVS sysprogs all issuing MVS commands at different times and in different situations. Our management would like two keys areas addressed, firstly how to best control who can issue commands MVS commands and secondly once the command is issued how to best track and note that the command has been issued. I assume control of MVS command issuing is a fairly common requirement so I was hoping people could pass on the benefit their wisdom and knowledge and how they have seen this done. Thanks for your help. Regards Peter Phillips ANZ Melbourne Australia "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
