Not to overbeat this dead horse, but I thought I'd add another one to the list here of ways to call authorized commands from TSO or Rexx.
By adding an authorized module name (in authorized library) to the IKJTSOxx AUTHCMD list and calling it from TSO or Rexx. CALL *(authmodule). It only kinda sorta fits because it really isn't a Rexx or TSO function per se and other than passing information to it through a file and retrieving the results from a file (or PUTLINEs) I can't think of any better way to interact with it. (Nothing better than the TSO service routine that is). Lindy -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: 15. huhtikuuta 2008 20:42 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Authorized Rexx Assembler Function Lindy Mayfield wrote: > For completeness, since I started this whole, ah, thing, I'm curious > what they are. Here are the techniques I've learned so far, including > the one that violates system integrity: > > __ The standard acceptable method is to call TSO/E Service Facility, > IKJEFTSR and pass it the name of an authorized module. > > __ Call an SVC that flips the JSCBAUTH bit back on. This is > non-standard. If it is to be implemented even on a development system > then added security needs to be built in to make sure it isn't misused. > I don't believe it's possible to add security to ensure this method doesn't get misused. (I'm almost sorry you posted it as an option.) The whole issue of validating the SVC caller is a hairy one. And, the requirements -- for example, to not even preserve a single register or storage address across the call -- are onerous. But, even more of a problem is the idea of setting JSCBAUTH. That flag affects all TCBs in the job step tree. It would be a fairly trivial matter for a savvy programmer to ATTACH a TCB that loops waiting for this flag to be turned on by the SVC running your code in another TCB. To protect against this, you would essentially have to make all TCBs in the address space non-dispatchable *before* JSCBAUTH was turned on. And, leave things that way until after JSCBAUTH is turned off again. This is not unlike what is done with IKJEFTSR. Your program runs under the authorized "leg" of the TMP. All unauthorized TCBs are made non-dispatchable while the authorized code runs. Keep in mind that similar integrity issues apply to any action that offers additional privilege to unauthorized work running asynchronously in the address space. For example, AXSET. > __ Simply put all the authorized stuff into an SVC or PC routine. > > That's all I've collected so far. Are there more ways? > > Lindy > -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
