A program designed to run as a jobstep expects a parameter list whose first word points to a halfword length field followed by a character string of that length. The Initiator will always flag the first word with an end-of-list bit. So if the program follows normal rules, you can't pass it an address that way. Of course, another, unauthorized, program can call it with a longer parameter list, but then it won't be running authorized and there is no exposure.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Leonardo Vaz <[email protected]> Sent: Saturday, November 16, 2019 7:33 PM To: [email protected] Subject: Re: AUTHPGM in IKJTSOxx Hello Walt! Thanks for your input! But wouldn’t that program be violating system integrity even if not placed on AUTHPGM? The user could execute it batch first example and change his ACEE or anything else. I guess depending on the authorized program code, it might keep integrity when executed under its own address space but if it executed under TSO it might allow other units of work to run something they shouldn’t be able to, i think it would have to be something really specific and it’s still unclear to me why AUTHPGM exists. Thanks Gil for your input too. zLeo > On Nov 16, 2019, at 4:17 PM, Walt Farrell <[email protected]> wrote: > > On Sat, 16 Nov 2019 15:30:01 +0000, Leonardo Vaz <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
