On Tue, Mar 17, 2015 at 10:18 AM, Walt Farrell <[email protected]> wrote: > On Tue, 17 Mar 2015 09:14:56 -0500, John McKown > <[email protected]> wrote: > >>I just had a thought (and it's lonely). You start off APF authorized, >>key 8 as a "normal" APF program. You want to run program "B" from the >>STEPLIB, but without APF authorization. Perhaps the simplest way is to >>use SYNCHX something like: >> >> LOAD EP=B >> ST R0,EPA_B >> MODESET KEY=ZERO >> USING PSA,0 >> L R3,PSATOLD MY TCB >> USING TCB,R3 >> L R3,TCBJSCB GET JSCB ADDRESS >> DROP R3 >> ICM R3,B'1000',=X'00' CLEAR HIGH BYTE >> USING IEZJSCB,R3 >> NI JSCBOPTS,255-JSCBAUTH NOT APF >> L R15,EPA_B >> SYNCHX (15) INVOKES PROGRAM B IN TCB KEY >> OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION >> MODESET KEY=NZERO >> >>The SYNCHX is the magic which allows your code to stay key 0 while >>invoking the other program "in line" in key 8. When the program >>returns, your code is still key 0. At which point you restore APF >>authorization and continue on. > > At which point you have a _major_ system integrity flaw. What about all that > key 8 storage your APF-authorized program has been using? The program you > SYNCHX'd to is free to overwrite it. You cannot trust any of it, including > the initial save area that MVS passed to your program, and where you > presumably stored the registers on entry (including the return address). > > When you go to return to the system it's quite possible that you'll go to an > address selected by the rogue routine, and it will be running with APF > authority at that point. > > This can only be fully safe if you never have any key 8 storage, or if you > copy all your key 8 data to a system key area before you invoke the > unauthorized program, and never use the old key 8 storage again. That would > be made a bit easier for you if your program was added to the PPT as running > in a system key. Then your initial save area and everything you GETMAIN would > be in that system key by default. But if you start out in key 8, you have > more work to do. >
All of the above is very true. But as I understand the original problem, it is how to run untrusted code in the same address space as APF authorized code. IMO, this, in and of itself, is a possible? integrity exposure in z/OS. The only real solution would be to only run code which you have written or vetted to be safe (assuming you trust yourself). In the original post, it was running an IBM utility. But Charles didn't want to trust it enough to simply LINK to it and allow it to "do its thing". What he wanted is what I gave: a way to temporarily turn off APF authorization, run the other code, then turn it back on. I, personally, would not do this. Being a paranoid heretic, I would go the UNIX route and figure out a way to run the untrusted code in a child process in another address space by using fork() and, likely, attach_execmvs(). And I again acknowledge the problems associated with DD statements in this environment. Too bad that z/OS does not have a easy way, in a UNIX child process, to have the child process do I/O to DDs allocated in the parent's address space. Perhaps by scheduling IRBs to a specialized TCBs in the parent which is set up to do this. Of course, this would be a massive new facility in DFSMSdfp. I can imagine a DCB or ACB option which would say "the DD for this is in my parent". That would cause DFP to set things up in the child, and parent, so that the when the child did I/O to the DCB/ACB, DFP would schedule a routine to run in the parent to do the actual function (OPEN, CLOSE, READ, WRITE, ???) and pass the associated data back and forth (or use DAS or AR mode somehow). This would probably be very difficult. Which means expensive and time consuming. And for little actual need. > -- > Walt -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
