The difference is that when run in batch, unless the JOBSTEP program is AC(1), loaded from an authorized library with a STEPLIB/JOBLIB concatenation that only contains authorized libraries, it will not, and cannot, become authorized. Also in general the JOBSTEP program can expect a "clean" environment at startup, ie no non-system provided modules will be loaded into the address space. A program run under the "authorized TMP" has no such control. The TSO user could run countless TSO commands that result in large numbers of "unanticipated" programs residing in the address space, so a poorly designed program in AUTHPGM, linked into an authorized library, and invoked via IKJEFTSR can allow a lot more potential violations of MVS system integrity than in general, an AC(1) module invoked as a batch job can.
Wayne Driscoll Rocket Software Note - All opinions are strictly my own. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Leonardo Vaz Sent: Saturday, November 16, 2019 6: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 ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
