Rob, Yes, this was, in part, one of the options I'd been considering. I was however, trying to stay away from having to add a new address space to the product. I will take your suggestions and re-consider again.
Yes, MVCS/DK is what I usually use, as much as possible. Thank you for your suggestions and advice. Kind Regards. Jim Thomas -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: Sunday, December 01, 2013 8:10 AM To: [email protected] Subject: Re: Un-authorized caller calling authorized services. 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
