With respect to the part about making other parts of TSO non-dispatchable, I
think this is achieved through some parameters on a STATUS macro.
TSO runs two TMP TCBs. The first executes commands which do not require APF
authorisation. The second executes those requested to run with APF
authorisation (i.e. in the AUTHPGM, AUTHCMD or AUTHTSF lists) or any program
invoked by TSOEXEC. ISPF runs without authorisation but examines the AUTHxxx
lists to determine whether to invoke the program via TSOEXEC.
TSOEXEC passes the program to the APF-authorised TCB which stops other TCBS in
the address space so that they cannot alter the environment while the
authorised program is running.
The bit TCBAREQ in byte TCBNDSP3 is set by the STATUS macro. I vaguely remember
that there is an undocumented parameter of STATSU for this, but I am not on a
z/OS system at the moment so I cannot check.
Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web: www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Paul Gilmartin
Sent: 16 November 2019 19:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx
On Sat, 16 Nov 2019 17:20:31 +0000, Leonardo Vaz wrote:
>Thanks for the input. Peter said something about making sure non authorized
>units of work are non dispatchable while the authorized program runs, is this
>something the authorized program added to AUTHPGM has to do or something that
>TSO does? If it is something that TSO already does, then why limit TSO to only
>run authorized programs on the AUTHPGM list? What is the harm of allowing any
>authorized programs as long as they don’t violate system integrity.
>
>I’m still curious.
>
Me, too. (The scope of the quantifier "only" is confusing.)
>> On Nov 16, 2019, at 11:43 AM, retired mainframer wrote:
>> ..
>> If it is in an authorized library, it needs to take the exact same
>> precautions any other homegrown program that runs authorized would need to
>> take. When you authorize any program, you are trusting it not to violate
>> your system's integrity. How it earns that trust varies from site to site
>> but I expect most have additional requirements above and beyond normal
>> release procedures.
>>
Do those precautions exceed those required for JCL //STEP EXEC PGM=HOMEGROWN?
>>> -----Original Message-----
>>> From: Leonardo Vaz
>>> Sent: Saturday, November 16, 2019 7:30 AM
>>>
>>> I am curious now, does a custom homegrown program have to take extra
>>> precautions to be placed under AUTHPGM? What would those be?
>>>
At one point, wanting to invoke GIMSMP via ssh with:
/* Rexx exec1*/
address TSO "exec exec2"
...
/* Rexx exec2 */
"ALLOCATE ..."
...
"call *(GIMSMP) ..."
... I needed to have my sysprog add GIMSMP to AUTHPGM.
He did so. Did this create a hazard? Which?
(After circa 2010, I needed also to be added to a RACF profile to avoid some
ineffable hazard. IBM representatives have provided no further guidance beyond
"Be careful!". I take that to mean, "If something breaks, it's on you, and we
still won't tell you what you did wrong.")
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
