Jim My advice would be to have a resource owning server that the batch caller would be a client of.
The client invokes a PC owned by the server that performs some sort of SAF check before using IEAMSCHD to run the SRB in the client. Personally I would use a PC-ss and a task level RESMGR routine to protect your caller. MVCSK and MVCDK are your friends to read from and write to caller storage when the server key does not match the client caller. Rob Scott Rocket Software > On 1 Dec 2013, at 02:25, "Jim Thomas" <[email protected]> wrote: > > Sir/s et'al, > > My service is a SRB and given, SRBPARM, will be executing some code that I > am given. > > No, there will not be any I/O and such, I am adhering to the rules of a SRB. > That said, the 'code' > that I am passed will be referencing and updating storage that will > ultimately be hardened after > I am done and pass control back to my caller. > > My main issue was to find out ways on how I can be called, given that my > caller would be > un-authorized. > > Binyamin. Chris and others have stated very good points and what to watch > out for. Art I thank > you for the .PDF that you referenced. > > In a nutshell, I'm trying to find out what the best way is for an > un-authorized called to call / invoke > a SRB. > > Kind Regards. > > Jim Thomas > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Binyamin Dissen > Sent: Saturday, November 30, 2013 5:25 PM > To: [email protected] > Subject: Re: Un-authorized caller calling authorized services. > > On Sat, 30 Nov 2013 21:53:06 +0000 "Blaicher, Christopher Y." > <[email protected]> wrote: > > :>There are a number of things you need to do to prevent an integrity > exposure. At one point I saw a presentation by IBM on this, but right now I > can't place my hands on it. If I do find it, I will post it. Here are the > main points of it, as I remember them. > > :>- Don't ever read data from a caller's address space when you are not in > the caller's key. As an SVC or PC your routine can be entered in key > zero/supervisor state, I.E. you are a god and can do anything you want. > > :>- Don't EVER, EVER write data to a caller's address space when you are not > in the caller's key. > > :>- You may have written the routine for your exclusive use, but don't > assume/think/hope that no one else is going to find it. Someone will and > then they will try to exploit it or use it for nefarious purposes. > > :>- TPROT data areas to be referenced. > > If you do the above, the TPROT is superfluous. And if you do not, realize > that unless appropriately locked, the results may no longer be valid when > you try to use it. > > -- > Binyamin Dissen <[email protected]> http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, you > should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, especially > those from irresponsible companies. > > ---------------------------------------------------------------------- > 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
