Juan I have received a private communication in which it is pointed out that there *is* a potential reason why you might not want all and sundry[1] to be able to browse your VTAMLST partitioned data set.
In the spirit in which this note was sent, I will not divulge precisely what the potential security exposure is except that it is along the lines of what a disgruntled ex-employee might do in order to express his or her feelings over having been "let go". In the "hacker-friendly" world of today's communications, this would be described as a "denial of service" attack. However, the proper solution to this mystery problem is not necessarily to bar all users of a z/OS system from being able to browse the VTAMLST partitioned data set, but to employ a SAF interface designed specifically to deal with the exposure, namely the VTAMAPPL class.[2] >From the z/OS Communications Server SNA Network Implementation Guide manual:[3] <quote> 14.5.4 VTAM application security You can specify a password on the APPL definition statement and require the application program to specify both its APPL definition statement name and its password when it opens its access method control block (ACB). The authority of the application program to gain access to the network can be verified by comparing the password in the OPEN ACB macroinstruction of the program to the password specified on the PRTCT operand of the APPL definition statement. The VTAM application OPEN ACB security facility provides additional resource access control. To perform security processing, VTAM invokes a security management product (such as RACF) through the security authorization facility for any application program that is not APF-authorized. The security management product determines whether an application program access to the network is approved. To enable the VTAM application OPEN ACB security facility, register the application program with a class of VTAMAPPL (CLASS=VTAMAPPL) in a security management product that is capable of controlling authorization for VTAM application program execution (such as RACF Version 1 Release 9). VTAM bypasses any password checking if the security management product provides the resource access control. The application program is authorized to access the network based on either the approval of the security management product or the user-specified password check. ... </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b5b0/14.5.4 I would modify this text slightly as follows: "The VTAM application OPEN ACB security facility provides additional resource access control." changed to "The VTAM application OPEN ACB security facility provides a much superior means to control the possibility successfully to open an VTAM ACB. It is recommended that this is used in preference to the PRTCT operand of the APPL definition statement which is, in effect, superseded by the this security facility. The PRTCT operand is preserved only to assist migration." Development authors will not, of course, make such a change since they don't do "dogmatic"! However, it's the sort of text you might have found in a redbook covering the VTAMAPPL topic where clarity and honesty are more easily expressed.[4] There is also another piece of text containing a couple of curiosities which I *think* are a legacy of poor wordsmithing when composed so that it has not stood the text of time: "... in a security management product that is capable of controlling authorization for VTAM application program execution (such as RACF Version 1 Release 9)." A. It would surely be a poor "security management product" which had missed the opportunity to implement the VTAMAPPL class. B. I managed to discover an on-line bookshelf for RACF V1R9.2 dating from 1993! It is evident that, if you are serious about security as it applies to the definition of APPL statements in your VTAMLST partitioned data set, you will have invested in the VTAMAPPL class in conjunction with your chosen SAF product. Apart from the concern, expressed in the days of SNI for which the "back-to-back" configuration was in part invented, that one enterprise with SNI connectivity to another enterprise should have no knowledge of the other enterprise's SNA configuration, I can't see any worry that what, in this day and age populated by "lemmings", is left of the VTAM definitions could be of any use, malicious or otherwise, to unauthorised eyes. - Just a clarification: it may be thought to be implied from my previous post that I was suggesting that, for a system programmer to maintain definitions in the VTAMLST partitioned data set, UACC(READ) sufficed. Of course minimally UACC(UPDATE) is obviously required for these particular legacy "masters of the universe"! - [1] If you are not familiar with some possibly confusing English-speaker idiom you find in posts, just use Google to resolve the mystery - and maybe expand your command of English - which is pretty good already! [2] Much derided, in profuse ignorance, by the "Wizard of Lodz" as revealed on a previous occasion when you specifically asked about the VTAMAPPL class last August. See the "RACF Discussion List" archives for thread "VTAMAPPL": Initial post from Juan Mautalen: Thu, 11 Aug 2011 14:43:17 -0300 Nonsense post from the "Wizard of Lodz": Fri, 12 Aug 2011 09:53:31 +0200 [3] Incidentally, in the initial post of the thread which is the subject of footnote 2, you quote the first paragraph of the section in the z/OS Security Server RACF Security Administrator's Guide manual which describes the VTAMAPPL class and then complain "My close to zero knowledge about VTAM poses me many doubts regarding RACF VTAMAPPL class."! Surely, following the Product A talking possibly/probably unreliably about Product B principle, you would have been *way* better off having dipped into - and quoting - what the VTAM manual had to say about the VTAMAPPL class - which isn't just a *RACF* entity but a *SAF* entity. [4] Another reason this precise change would not be made is that a development author would never miss the opportunity to split an infinitive! I think that must be in the contract between IBM and its authors. - Chris Mason On Fri, 9 Mar 2012 09:00:34 -0800, Juan Mautalen <[email protected]> wrote: >Hi: > >We currently have our VTAMLST libraries protected with UACC(READ). IBM >suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix D- >Security for system datasets) . I want to make the change, but of course i >know i must be extremely carefull with this change. I need to detect all users >needing read access to VTAMLST. Human users are not my problem, my worry is >about non-human ones (users of system tasks, started tasks, etc.). > >What users need read access of VTAMLST? >Does any userid associated with a VTAM application need to read VTAMLST? > >Thanks in advance for your help, > >Juan Mautalen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
