Walt,
The documentation you are thinking of may have been
for IDCAMS and AUTHTSF:
TSO/E determines the authorization of commands and programs and
the execution environment they are running in by analyzing the
following statements in member IKJTSOxx of SYS1.PARMLIB:
AUTHCMD
identifies authorized commands to TSO/E
AUTHPGM
identifies programs that are authorized when invoked via the CALL
command
AUTHTSF
identifies programs that are authorized when invoked
through the TSO/E Service Facility. In most cases these
programs are not in AUTHPGM. They are primarily those that
expect more complex parameter lists than that of the CALL
command and use parameter 7 of the IKJEFTSR parmlist to
supply parameters to the invoked program. As a general rule
programs in this list, it should not accept parameters that
are pointers to code that will be executed (such as exit routines)
because this might introduce an integrity exposure.
Note: Do not place programs from any IBM® products in this
table unless the documentation of that product requires. For
example, do not put IDCAMS in AUTHTSF.
PLATCMD
identifies authorized and unauthorized commands that can run on a
command/program invocation platform.
PLATPGM
identifies authorized and unauthorized programs that can run on a
command/program invocation platform.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
"IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> wrote on
11/16/2019 04:16:27 PM:
> From: "Walt Farrell" <walt.farr...@gmail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/18/2019 01:03 PM
> Subject: Re: AUTHPGM in IKJTSOxx
> Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU>
>
> On Sat, 16 Nov 2019 15:30:01 +0000, Leonardo Vaz <leonardo....@cn.ca>
wrote:
>
> >I am curious now, does a custom homegrown program have to take
> extra precautions to be placed under AUTHPGM? What would those be?
> >
>
> Usually, no.
>
> Sometimes, depending on what the program does, yes.
>
> For example, consider a program which accepts as a parameter the
> address (not the name) of some code to be executed as a kind of
subroutine.
>
> Now consider what might happen if you were to link that program with
> AC(1), place it in a library that MVS considers APF-authorized, and
> put its name in AUTHPGM. At that point any TSO user could:
> (1) Write a program that had some malicious code in it.
> (2) Invoke your program using IKJEFTSR and passing the address of
> the malicious code.
>
> TSO would then pause the user's program (TCB) to preserve System
> Integrity, invoke your code running authorized, and your code would
> run the user's malicious code. Your program has then allowed the
> user to violoate MVS System Integrity.
>
> There are several solutions:
> (a) Don't put that program in AUTHPGM. If I remember correctly there
> was at least one MVS program whose documentation said it should not
> be placed in AUTHPGM.
>
> (b) Code the program to detect it's running authorized, and under
> TSO, and then skip calling the code. Perhaps, as an alternative, in
> that situation the program might allow the user to pass a module
> name instead of an address, and the program could LINK to it,
> allowing the system to determine whether it is safe to invoke the
> subroutine module.
>
> (c) Code the program to detect it's running authorized, and under
> TSO, and then to perform a security check to see the current user is
> trusted to run the program under TSO.
>
> --
> Walt
>
> ----------------------------------------------------------------------
> 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
