Eileen, Actually the comment that "Netview itself does not invoke security checking" is correct. Netview issues the MGCRE macro, which passes a command to the console interface. The interface console determines what command is being issued, and performs security checks to insure that the userid that is either defaulted, or requested by the caller of the MGCRE macro via the UTOKEN parameter is authorized to issue the command. My guess is that NETVIEW passes the UTOKEN of the user signed to the NETVIEW session if AUTHCHK=SOURCEID, and passes the UTOKEN of the NETVIEW address space if AUTHCHK=TARGETID . In either case, NETVIEW isn't making the security requests, they are made by the console service, in the same way that console services validates instructions issued from SDSF, the TSO OPER command, or any other application that issues MGCRE. =============================================== Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com ===============================================
From: "Barkow, Eileen" <[email protected]> To: [email protected] Date: 08/05/2011 02:52 PM Subject: Re: Netview security problem Sent by: IBM Mainframe Discussion List <[email protected]> Thanks for your comments Chris, but I think that you missed the point of the excerpt I included, which was just in response to someone saying that Netview itself does not invoke security checking - it does invoke security checking and how it does it depends upon the AUTHCHK option. AUTHCHK used to default to TARGETID, which used the userid of the task running (the Netview operator) as opposed to SOURCEID (the 5.4 default), which uses the id of the invoker. My problem was not with the inclusion or exclusion of the word 'MVS' in front of the command. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chris Mason Sent: Friday, August 05, 2011 3:44 PM To: [email protected] Subject: Re: Netview security problem Eileen > In NetView V5R4 there was a change to allow the D (DISPLAY), F (MODIFY), and V (VARY) commands to be issued from a NetView operator task without the MVS prefix. How massively amusing! I think I'll say that one more time: how really massively amusing! Today there is NetView. 15 years or so ago, Tivoli got into the act and started putting "Tivoli" in front of NetView in the product name although they had absolutely nothing whatsoever in this world to do with MVS NetView[1]. Before NetView and long before "Tivoli" was added to the name, there was NCCF (Network Communications Control Facility) which was bundled together with a number of products which used NCCF as an enabling environment as a sort of network management CICS but with a few basic functions. Before NCCF, those basic functions were supported by a product NOSP (Network Operation Support Program). Dates: NOSP (1978 or so), NCCF (1980 or so), NetView (1986 or so). Now, all readers are invited to propose what functions NOSP supported. Wait, while the cogs turn ... Why it's " D (DISPLAY), F (MODIFY), and V (VARY) commands to be issued from a" NOSP "operator task without" any thought of any sort of "prefix." Naturally, they were only the VTAM flavours of these commands. - Ok, I've had my joke! > In NetView V5R4 there was a change to allow the D (DISPLAY), F (MODIFY), and V (VARY) commands to be issued from a NetView operator task without the MVS prefix. These commands are now sent to the VTAM command processor where they are checked to determine if they are VTAM commands If they are not VTAM commands, they are forwarded to the MVS command processor (CNMCMVS) where they are processed the same as if they had been entered using the MVS command including security checking. I'm going to rephrase this entirely correct but thoroughly misleading paragraph so that it has the appropriate nuances. <rephrase> > In NetView V5R4 there was a change to allow even the non-VTAM D (DISPLAY), F (MODIFY), and V (VARY) commands to be issued from a NetView operator task without the MVS prefix. The VTAM command processor obviously takes these commands and then checks them in order to determine whether or not they are VTAM commands. If they are VTAM commands, they are processed as usual. If they are not VTAM commands, they are forwarded to the MVS command processor (CNMCMVS) where they are processed the same as if they had been entered using the MVS command. This processing includes security checking. </rephrase> Because NetView development so much insists on holding the poor put-upon system programmer's hand - and has done so ever since NetView was assembled from its constituent parts because - so one was lead to believe by NetView development - the poor lambs of system programmers bleated that putting the components together as individual - separately priced - products made their skulls throb[2], these days system programmers no longer know how NetView works "under the covers" - unless perhaps they are involved in building products on top of NetView/NCCF as an application-enabling environment. - Anyhow, the point of all this preamble is that the DISPLAY (D), MODIFY (F) and VARY (V) commands are all identified using those tokens in a text table I seem to recall having the DSIPARM member name DSICMD - I Google-checked and I remembered correctly! One of the operands of the command definition is the name of the module which handles the command and in the case of these 6 commands it is something like DSIVTAM, the command processor module for what hitherto - from the days of NOSP - were expected to be exclusively VTAM commands. It seems that the NetView V5R4 change is that smarts have been added to - let's call it - DSIVTAM so that, rather than barfing - or letting VTAM barf - at having to deal with an unrecognised command, it constructs a new command from the unrecognised text string prepended with "MVS " and cycles it into the NetView command processing system - or something, in effect, equivalent to that. - Now I'm going to have a look at the rest of this thread in order to see if any of the above can in any way be used to understand anything of what has been said so far or, more likely, just may assist in refocusing the real "security" specialists on what may be going on and provide input for future thoughts. ... Well, no I'm a bit lost in understanding to which component the RACF message applies and how what appears to be, in effect, a change introducing convenience in NetView might introduce a change relevant to RACF. In addition, unless the commands in the clist are changed in order to remove the "MVS " which NetView is prepared to add, I can't see that anything has changed. If a change introduces a problem, then change back to the way it was. I guess this might boil down to asking what relevance does this description of not needing to specify the "MVS " prefix for DISPLAY, MODIFY and VARY commands have on the problem described. OK, maybe I'm seeing some light here. > The difference now is that it is checking against the invoking userid, not that of the Netview operator. Because of the convenience change that I found so amusing, is it that NetView has introduced a complementary change which you describe as this "difference"? This looks like it might be closing off a "security" hole that shouldn't really have existed before and perhaps you should be grateful that the NetView release change has dealt with it for you. Well, that's the way you are going to have to present it to the relevant "suit" or "suits"! Incidentally, have you also presented this problem on the NetView "forum"? In case you are not subscribed, this is the URL I access when I select "Visit Your Group on the Web" from the digest I got today: http://tech.groups.yahoo.com/group/NetView/ - [1] Fred Reznak, an "all the products mentioned above" developer - whom I got to know at one time long, long ago - made a wonderful observation about the addition of "Tivoli" to the NetView brand. I wish I had noted his comment, something to do with his having had an employer for a long time for whom he was not aware he was working - or something like that! [2] NetView development got quite shirty if it was suggested that this mollycoddling was a tad too excessive and really, as a user of the combined products, one might prefer just to assemble the parts necessary to do the particular job for which the product was purchased and cut out all the dross - a situation comparable to having to put up with bloatware on a laptop system. Incidentally I expect that the poor lambs of system programmers upon which NetView developers relied for their intransigence just happened to be a very small number from some customers with immense clout. At times like this I always used to use the name "Sears" to my students - with apologies to anyone reading this from "Sears" and especially if you were working with NCCF etc. in the mid-1980s! - Chris Mason On Fri, 5 Aug 2011 13:10:11 -0400, Barkow, Eileen <[email protected]> wrote: >From this excerpt, Netview 5.4 does pass the MVS commands on for security checking. >The difference now is that it is checking against the invoking userid, not that of the Netview operator. > >In NetView V5R4 there was a change to allow the D (DISPLAY), F > (MODIFY), and V (VARY) commands to be issued from a NetView > operator task without the MVS prefix. > These commands are now sent to the VTAM command processor > where they are checked to determine if they are VTAM commands > If they are not VTAM commands, they are forwarded to the MVS > command processor (CNMCMVS) where they are processed the same > as if they had been entered using the MVS command including > security checking. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Walt Farrell >Sent: Friday, August 05, 2011 12:20 PM >To: [email protected] >Subject: Re: Netview security problem > >On Fri, 5 Aug 2011 11:58:45 -0400, Barkow, Eileen <[email protected]> wrote: > >>We do not want the give the user access to issue MVS commands - >>That is not the way this worked. >>The clist does specific functions which the user cannot do directly with MVS commands. >> >>Netview 5.4 is doing security checking against the invoking userid which it did not do before. >>We need a way to stop it from doing so. > >Just to be clear, Netview is not doing security checking in the scenario you've showed us. Netview is issuing commands, and it's issuing them from the invoking user ID. It's MVS Console processing that's doing the security checking. > >I think your Netview person needs to be looking for Netview configuration parameters that control what user ID it runs work under. > >-- >Walt Farrell >IBM STSM, z/OS Security Design ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
