Bob
There are a couple of points I missed from my previous post.
-
A. It was implied but I should have said that I would trust any advice
regarding access to data sets *only* from a publication originating from the
development authors of the product involved. Obvious really.
I did check the manuals of the SNA component (VTAM) of z/OS Communications
Server using likely keywords but I found no general recommendations. Thus it
would appear that the VTAM folk are just relying on product knowledge and
common sense in order for a system programmer to decide access requirements.
So this leads to some advice for Juan:
Juan
In the thread you initiated last August in the RACF-L list regarding the
VTAMAPPL class, you said you didn't know a great deal about VTAM. Well, it
would seem that the person to whom you should turn first is the VTAM specialist
in your installation for advice on anything to do with VTAM. Then he or she can
post - probably the best place being the IBMTCP-L list[1] - for any additional
help.
I have, of course, always to assume that in any installation where VTAM is used
in earnest - not necessarily in conjunction with "business-critical" activity
but close to it - there is such a specialist. Unfortunately I have heard of
installations with holes in their feet!
-
B. In my footnote criticising the supplied VTAMLST sample member of SEZAINST, I
forgot to mention the operand which should feature but doesn't. This is the
REGISTER operand. With this in mind the "rightness" percentage drops well under
50% and the "wrongness" percentage rises correspondingly.
It is very likely these days that installations are relying on APPN in order,
first and long ago, to escape the tyranny of PATH statements and, secondly, in
order to support Enterprise Extender. With APPN enabled, it is a complete waste
of time to have the name of any activated APPL statement - I am assuming sense
has prevailed (no thanks to the SEZAINST VTAMLST member) and a *model* APPL
statement is in use - representing a TELNET client which always causes the SNA
session to be *initiated*, such as applies to a "display" connection/session,
registered in the APPN directory system. Thus, for a "display" model APPL
statement REGISTER=NO should be present.
Sensible sample:
VBUILD TYPE=APPL
TD* APPL EAS=1,REGISTER=NO,SESSLIM=YES
For any activated APPL statement representing a TELNET client which relies upon
the primary LU application to initiate the SNA session such as applies to a
"printer" connection/session, the opposite applies and such a potential session
end-point needs to be registered in the APPN directory system. Thus, for a
"printer" model APPL statement REGISTER=CDSERVR should be present - or, note
well, assumed by default!
VBUILD TYPE=APPL
TP* APPL EAS=1,REGISTER=CDSERVR,SESSLIM=YES
-
[1] For IBMTCP-L subscribe / signoff / archive access instructions, send email
to lists...@vm.marist.edu with the message: INFO IBMTCP-L
-
Chris Mason
On Sat, 10 Mar 2012 12:23:58 -0600, Chris Mason <chrisma...@belgacom.net> wrote:
>Bob
>
>Please see the post which adds to my initial post in this thread.
>
>> When IBM suggests UACC(NONE) for a system dataset, this is usually an
>> indicator the dataset contains security control information that should be
>> kept secret.
>
>If you rely on the VTAMAPPL class for proper security, VTAMLST partitioned
>data sets don't - with the possible exception of the means to reconstruct
>configuration information of a business rival which no longer applies in these
>post-SNI days - see my earlier post.
>
>> In this particular case, it may ...
>
>I'm not interested in "may" but precisely what. System programmers should not
>have to be dealing with "Smoke and mirrors"!
>
>> ... such as the ability to specify clear text passwords with PRTCT= on VTAM
>> APPL definitions.
>
>I'm also not interested in "such as" but "precisely as".
>
>Taking the case of PRTCT, this was what passed (playing with words!) for
>security in the mid-1970s and - rather a joke - development described it as
>being a "password". So very obviously the VTAMAPPL class knocks spots off the
>PRTCT operand.
>
>Do you have any VTAM features in mind other than PRTCT or was "such as" an
>application of the "mushroom" principle?
>
>> Whereas the RACF team at IBM may not always provide detailed information
>> about why they made a particular suggestion, I have always found them to be
>> very thoughtful and never arbitrary.
>
>That Table 48, "UACC values for system data sets" in the z/OS Security Server
>RACF Security Administrator's Guide manual falls foul of the principle that
>you cannot - a priori - take what product A says about product B as
>reliable.[1] I will accept they are not arbitrary and demonstrate thought when
>they justify their pontifications and indicate what their wise thoughts
>actually were!
>
>> Whereas the RACF team at IBM may not always provide detailed information
>> about why they made a particular suggestion, ...
>
>IMNSHO this is an unacceptable approach. Even if they discuss RACF topics
>where we might hope that they are reliable, there should be reasonable
>explanations. However RACF would not be alone in exhibiting such a deficiency;
>the Communications Server product, which I know best if it wasn't obvious, can
>be found wanting in this regard also.
>
>-
>
>[1] One example of this I mention from time to time and have done so recently
>is the sample APPL statement for the secondary LUs managed by the SNA-oriented
>TELNET server provided in SEZAINST member VTAMLST. It is IMNSHO approximately
>half-right and so is approximately half wrong - and this is one side of the
>same product talking about the other side![1.1]
>
>TCP00001 APPL AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM,SESSLIM=YES
>
>Wrong half:
>The AUTH=NVPACE operand is utter, unmitigated rubbish!
>The MODETAB=ISTINCLM operand is addlepated!
>
>Right half:
>The EAS=1 operand is obviously correct and saves 4K in comparison with the
>default EAS=509.
>The SESSLIM=YES operand is obviously correct and has a rather complex role to
>play in some configurations as indicated by an APAR the text of which is no
>longer available.
>
>Dubious (tending to wrong):
>PARSESS=NO is pointless since it is a default for which PARSESS=YES is the
>override which adds function.
>
>[1.1] Well, we must recognise that z/OS Communications Server originally was a
>product A, VTAM, and a product B, "TCP/IP for MVS" .
>
>-
>
>Chris Mason
>
>On Sat, 10 Mar 2012 06:40:35 -0500, Robert S. Hansel (RSH)
><r.han...@rshconsulting.com> wrote:
>
>>Chris,
>>
>>When IBM suggests UACC(NONE) for a system dataset, this is usually an
>>indicator the dataset contains security control information that should be
>>kept secret. In this particular case, it may have to do with options such as
>>the ability to specify clear text passwords with PRTCT= on VTAM APPL
>>definitions. Whereas the RACF team at IBM may not always provide detailed
>>information about why they made a particular suggestion, I have always found
>>them to be very thoughtful and never arbitrary.
>>
>>Regards, Bob
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
