Re: ISPF Storage Protection
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Wednesday, March 05, 2014 8:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Storage Protection On Wed, 5 Mar 2014 07:10:11 -0800, dpewen : I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. Congratulations! You have made it easy for any program to do anything on every system that has your product. Yes, I'm also very impressed by this development, an amazing program, could think of a myriad of uses! ;) Best Regards, Thomas Berg Thomas BergSpecialistzOS/RQM/AMSwedbank AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ISPF Storage Protection
Hello, I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
Do NOT do this ! This is a serious system integrity exposure. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of dpewen Sent: 05 March 2014 15:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Storage Protection Hello, I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
On Wed, 5 Mar 2014 07:10:11 -0800 dpewen dpe...@bellsouth.net wrote: :Hello, : :I started this thread and I appreciate all the input I received from this list. :I have solved the problem by adding code to my user svc that is part of the product. :I added two functions to the svc: :1. to turn on the APF-auth bit in the job step TCB :2. to turn off the APF-auth bit in the job step TCB :This allows me to issue the MODESET svc successfully. Why on earth would you want to break system security? Encapsulate the function! The function is not to modeset, but to do something that requires authorization. -- Binyamin Dissen bdis...@dissensoftware.com 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
If this is part of a vendor product, and we were looking at said product, and I learned that it did this, I would _strongly_ recommend against acquiring the product. Having this around is like having small bottles of fulminate of mercury scattered around in the kids' play room. It is most likely going to explode and do a lot of damage. On Wed, Mar 5, 2014 at 9:12 AM, Rob Scott rsc...@rocketsoftware.com wrote: Do NOT do this ! This is a serious system integrity exposure. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of dpewen Sent: 05 March 2014 15:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Storage Protection Hello, I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
Please use google and search the IBM-Main archives for JSCBAUTH for *many* discussions about why you should not be flipping it on and off. Apart from the fact that it is difficult to secure any facility that elevates the authority of the caller, there is also the multi-tasking aspect to consider. The JSCBAUTH flip technique is analogous to something like the following : Someone is in the habit of leaving a unloaded gun on a table in a house with kids running around. No-one gets hurt as there is no ammunition in the house, so the kids happily pick up and play with the gun and put it back. Someone decides that they want to use the gun for hunting, so they load up a bullet and prepare to leave the house but get distracted by a phone call. They put the gun back on the table while they take the call and tell themselves to remember to unload it. Meanwhile some kid who has knocked back a fair amount of sugar, runs into the room, grabs the gun and starts play-shooting. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of dpewen Sent: 05 March 2014 15:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF Storage Protection Hello, I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
On 3/5/2014 7:10 AM, dpewen wrote: Hello, I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB Turning on JSCBAUTH makes _every TCB in the job step_ authorized! This is an exposure! There should be another way to achieve what you want. But, at the very least you must understand that any time you're going to modify a job step or address space-level setting, especially one that confers additional privileges to otherwise non-privileged TCBs, you MUST ensure that all such TCBs are marked non-dispatchable for the duration of the enhanced setting. This is what TSO/E does during execution of a program on the Authorized Leg of the TMP. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
Instead of adding function codes to the SVC to allow setting and resetting of the JSCBAUTH bit, add function codes to the SVC to perform the code that requires authorization. As others have mentioned, this type of magic SVC destroys any concept of system integrity. == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com All opinions are mine, and do not represent IBM Corporation. == IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 03/05/2014 09:10:11 AM: From: dpewen dpe...@bellsouth.net To: IBM-MAIN@listserv.ua.edu, Date: 03/05/2014 09:10 AM Subject: [IBM-MAIN] ISPF Storage Protection Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Hello, I started this thread and I appreciate all the input I received fromthis list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
Needing better illumination at his workstation, he built a device for turning on all of the lights in his offfice building. Apart from the security exposure, this use of the JSCBAUTH bit is ugly and inelegant, akin to setting a two-penny nail with a pile driver that you happen to have at hand. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
On Wed, 5 Mar 2014 15:32:03 +, Rob Scott wrote: Please use google and search the IBM-Main archives for JSCBAUTH for *many* discussions about why you should not be flipping it on and off. Apart from the fact that it is difficult to secure any facility that elevates the authority of the caller, there is also the multi-tasking aspect to consider. In my view, simply, no facility should *ever* elevate the authority of its caller. Discussions such as this reinforce my belief in the utter folly of allowing privileged and unprivileged code to operate in the same address space. It's complex; Byzantine, and disproportionately difficult to secure. I think z/OS UNIX got it right. (AFAIK.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
In 1394032211.10894.yahoomail...@web181501.mail.ne1.yahoo.com, on 03/05/2014 at 07:10 AM, dpewen dpe...@bellsouth.net said: I started this thread and I appreciate all the input I received from this list. I have solved the problem by adding code to my user svc that is part of the product. I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. It also opens a gaping security breach. I recommend a safer approach. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
The problem is not, or not only, that of elevating the authority of a 'caller'. It is frequently necessary to depress authority, and it is therefore necessary to elevate it too in order to restore the status quo ante. Worse, it is possible to do things with SRBs that cross address-space boundaries; and this facility too is necessary. Paul's proposed solution, admirably motivated, is akin to capital punishment for locksmiths in a jurisdiction where locks are ubiquitous. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
In my view, simply, no facility should *ever* elevate the authority of its caller. An admirable desire, however as pointed out earlier, there are circumstances where even standard IBM software has had to go down this route - eg TSO and AUTHTSF/PGM/CMD. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: 05 March 2014 16:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Storage Protection On Wed, 5 Mar 2014 15:32:03 +, Rob Scott wrote: Please use google and search the IBM-Main archives for JSCBAUTH for *many* discussions about why you should not be flipping it on and off. Apart from the fact that it is difficult to secure any facility that elevates the authority of the caller, there is also the multi-tasking aspect to consider. In my view, simply, no facility should *ever* elevate the authority of its caller. Discussions such as this reinforce my belief in the utter folly of allowing privileged and unprivileged code to operate in the same address space. It's complex; Byzantine, and disproportionately difficult to secure. I think z/OS UNIX got it right. (AFAIK.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
On Wed, 5 Mar 2014 07:10:11 -0800, dpewen : I added two functions to the svc: 1. to turn on the APF-auth bit in the job step TCB 2. to turn off the APF-auth bit in the job step TCB This allows me to issue the MODESET svc successfully. Congratulations! You have made it easy for any program to do anything on every system that has your product. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Storage Protection
In CAE1XxDHEY=r5tzjrpocmoggzsqtks7trlbs-tzqxf172znu...@mail.gmail.com, on 03/05/2014 at 11:41 AM, John Gilmore jwgli...@gmail.com said: It is frequently necessary to depress authority, and it is therefore necessary to elevate it too in order to restore the status quo ante. Nonsense; there are mechanisms to temporarily reduce authority with any tricks to reinstate the original authority. There is no excuse for using mechanisms such as magic SVC's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Douglas Do you have a server address space for your product? If so, can I suggest that perhaps a re-design would be beneficial here to remove any requirement for the client caller to be running in non-problem state : (1) Have your server setup a system-LX and ETDEF a space-switch PC routine (2) Your server creates a cell pool of request block elements in the required key (if you are using key-7 (Db2) then the easiest way is for your server to execute in key-7 using a definition in SCHEDxx) (3) The client caller then has some sort of macro interface to the PC-ss (4) The PC-ss routine gets a cell from the server key-7 private and populates it (5) The PC-ss routine adds the new request block to the server queue (6) Another task in the server address space processes the queue and releases the request cell back when done Notes : (o) MVCDK and MVCSK can be used to copy data to and from the server (running in Key7) to your client caller (running in whatever key) (o) If you require a synchronous response, then the PC-ss could SUSPEND the caller and then the request processing task can then RESUME him when done with the request (o) Task level resource managers are very useful to handle caller gone situations when sync response is required - (see RESMGR macro) (o) You may wish to SAF protect the logic in the PC-ss so that only authorized users can add to the queue. Using the above technique, there is no requirement for the client to be running in a non-problem state. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Douglas P Ewen Sent: 03 March 2014 23:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF storage protection Hello, I have a product that uses ISPF panels to allow the user to specify control information for the product. This control information is turned into a control block and then passed(XCTL) to a program that attempts to add the control block to a queue which resides in storage key=7. Although I have APF authorized the program that tries to update the que, I cannot get into a key=7 using the MODESET SVC. The MODESET SVC fails with system completion code=047. Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
It's.all a catch 22 as you need to authorized to create PC rtn's Sent from my iPhone On Mar 4, 2014, at 3:32 AM, Ed Jaffe edja...@phoenixsoftware.com wrote: On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Obviously the *server* code that owns the PC routines must run in an authorized environment - however the important thing here is that the *client* code runs in problem state. Using a PC-ss to add requests to a server ASID to perform the authorized function on behalf of the caller means that : (1) No updates required to IKJTSOxx (2) No MODESET in client code (3) Client code can run in non-authorized state in non-TSO environments (4) System integrity exposures are reduced Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: 04 March 2014 12:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection It's.all a catch 22 as you need to authorized to create PC rtn's Sent from my iPhone On Mar 4, 2014, at 3:32 AM, Ed Jaffe edja...@phoenixsoftware.com wrote: On 3/3/2014 4:52 PM, dpewen wrote: Yes ... SPKA requires SUP state SPKA works in problem state if the PKM allows it. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 9111247477380775.wa.dpewenbellsouth@listserv.ua.edu, on 03/03/2014 at 05:51 PM, Douglas P Ewen dpe...@bellsouth.net said: Although I have APF authorized the program that tries to update the que (sic) How? Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? Yes. Before doing that, have you considered setting up a PC interface for adding elements to the queue? ISPF is subject to the same rules as any other TSO application; in order to run authorized code, it has to use the relevant TSO services. The easiest way is to package the code in a TSO command that is defined to TSO as authorised and to include an ISPMTCM macro for the command with the appropriate FLAG, e.g., FLAG=X'22'.. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 1393894348.42329.yahoomail...@web181502.mail.ne1.yahoo.com, on 03/03/2014 at 04:52 PM, dpewen dpe...@bellsouth.net said: Yes ... SPKA requires SUP state Actually, it's only semiprivileged. In problem state it can set any key enabled in the PSW-key mask. However, z/OS will not (I hope) dispatch an unauthorized program with key 7 enabled in the mask. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
It has to do with the fact that the APF code itself could become corrupted (if loaded into key-8 storage) by some user code running under a different TCB. Or that some key 8 storage area used by the APF code could be corrupted by user code running on a different TCB. This corruption could be either due to poor coding, or even a malicious attempt to get non-APF code running in APF mode. TSO has an interface, IKJEFTSR, which can run APF safely under TSO. But it does this my using a separate TCB structure to run the APF code and doing a STATUS STOP on all the other TCBs in the address space. Well, most of them, anyway. However, things running via IKJEFTSR cannot do ISPF functions for the very same reason. The ISPF code runs on a different TCB and that TCB is in a more or less hard wait. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1.2 On Tue, Mar 4, 2014 at 9:51 AM, Leonardo Vaz leonardo@cn.ca wrote: True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
The difference is that TSO (and ISPF) runs in problem state and the jobstep is unauthorized. In batch, when executing a program linked AC(1) that comes from a valid APF authorized library, then the entire jobstep is considered authorized. TSO must jump through a few hoops to attempt to provide a safe way of invoking the authorized program - this involves having a parallel authorized jobstep TMP task and suspending all TCBs on the non-authorized leg while the authorized code is executing. Hence the various tables in TSO (and ISPF) to define these special circumstance commands (or programs) that can run authorized. Throw into the ring, the confusion that can occur with TSOLIB and ISPLLIB (and STEPLIB) - it can get messy to code applications and debug problems in this area - especially when your code is running on other people's systems. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: 04 March 2014 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Wow, this ended up way more interesting than I thought it would! Thanks for the info Rob and John! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Tuesday, March 04, 2014 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection The difference is that TSO (and ISPF) runs in problem state and the jobstep is unauthorized. In batch, when executing a program linked AC(1) that comes from a valid APF authorized library, then the entire jobstep is considered authorized. TSO must jump through a few hoops to attempt to provide a safe way of invoking the authorized program - this involves having a parallel authorized jobstep TMP task and suspending all TCBs on the non-authorized leg while the authorized code is executing. Hence the various tables in TSO (and ISPF) to define these special circumstance commands (or programs) that can run authorized. Throw into the ring, the confusion that can occur with TSOLIB and ISPLLIB (and STEPLIB) - it can get messy to code applications and debug problems in this area - especially when your code is running on other people's systems. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: 04 March 2014 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Tue, 4 Mar 2014 09:25:10 -0600, Paul Gilmartin paulgboul...@aim.com wrote: . . . Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? Perhaps you could get away without AUTHPGM, but AUTHTSF is required. Actually when the TSO Service Facility was created, the designers did not see a need for this, and they made use of AUTHPGM, which together with AUTHCMD already existed at that time. Some time later they saw the error of their ways and an APAR added AUTHTSF. For a long time the only place where the reason for this was explained was in the APAR that introduced it, and at some point even that was hidden from customers' view. These days the reason is explained in the TSO/E documentation: ... programs in this list (AUTHTSF) should not accept parameters that are pointers to code what is to be executed (such as exit routines) as this might introduce an integrity exposure. Such parameters cannot be provided when executing the program using JCL. The documentation even goes on to mention that IDCAMS should never be added to AUTHTSF. IDCAMS was the specific program that prompted the APAR that introduced AUTHTSF, but any number of other programs could have the same issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
About pointers to executable code Andy Wood wrote: | Such parameters cannot be provided | when executing the program using JCL. While this is of course literally true, it is not usefully so. It is, for example, possible to to provide offsets (in the form of unsigned external decimal-digit strings) that a knowledgeable routine can convert into such pointers. It is indeed possible to provide 8- or 16-digit external hexadecimal-digit pointer representations (in a PARM= string) that are immediately convertible into virtual-storage addresses. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
John, I ran into issues with that doing Rexx from a Cobol STC, that we haven't converted to C yet. I ended up calling a IRXJCL rexx stub that did a LINKMVS to some code..I cheated , I plead guilty ….lol Regards, Scott From: John McKown Sent: Tuesday, March 4, 2014 11:05 AM To: IBM Mainframe Discussion List It has to do with the fact that the APF code itself could become corrupted (if loaded into key-8 storage) by some user code running under a different TCB. Or that some key 8 storage area used by the APF code could be corrupted by user code running on a different TCB. This corruption could be either due to poor coding, or even a malicious attempt to get non-APF code running in APF mode. TSO has an interface, IKJEFTSR, which can run APF safely under TSO. But it does this my using a separate TCB structure to run the APF code and doing a STATUS STOP on all the other TCBs in the address space. Well, most of them, anyway. However, things running via IKJEFTSR cannot do ISPF functions for the very same reason. The ISPF code runs on a different TCB and that TCB is in a more or less hard wait. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b780/23.1.2 On Tue, Mar 4, 2014 at 9:51 AM, Leonardo Vaz leonardo@cn.ca wrote: True, I have never understood that either, gil. It might more to do with executing the program in the appropriate TCB than a security exposure. Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, March 04, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection On Tue, 4 Mar 2014 08:54:43 -0500, Shmuel Metz (Seymour J.) wrote: In 9819019940159674.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 06:14 PM, Paul Gilmartin paulgboul...@aim.com said: I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. Because it would be a major security breach. That doesn't tell me much. Why? How? Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
In 769b2e18f7b2fa48b3adea85570a28769a560...@mtl-hq-x01.cn.ca, on 03/04/2014 at 03:51 PM, Leonardo Vaz leonardo@cn.ca said: Would it be any less a security breach to invoke such a program from JCL with EXEC PGM=... which likewise causes it to run in the authorized state? Yes. What makes it a security breach is allowing an unauthorized program to invoke it authorized in an uncontrolled manner. IBM has written voluminously about this issue. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ISPF storage protection
Hello, I have a product that uses ISPF panels to allow the user to specify control information for the product. This control information is turned into a control block and then passed(XCTL) to a program that attempts to add the control block to a queue which resides in storage key=7. Although I have APF authorized the program that tries to update the que, I cannot get into a key=7 using the MODESET SVC. The MODESET SVC fails with system completion code=047. Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Sent from my iPhone On Mar 3, 2014, at 6:51 PM, Douglas P Ewen dpe...@bellsouth.net wrote: Hello, I have a product that uses ISPF panels to allow the user to specify control information for the product. This control information is turned into a control block and then passed(XCTL) to a program that attempts to add the control block to a queue which resides in storage key=7. Although I have APF authorized the program that tries to update the que, I cannot get into a key=7 using the MODESET SVC. The MODESET SVC fails with system completion code=047. Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Paul Now that you bought it up I think ISPF has a table ISPTCM where you specify authorized command it's in the ISPF customization guide Sent from my iPhone On Mar 3, 2014, at 7:14 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Mon, 3 Mar 2014 19:21:20 -0500, Micheal Butz wrote: Now that you bought it up I think ISPF has a table ISPTCM where you specify authorized command it's in the ISPF customization guide Hmmm. Didn't know about that. I see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.f54pc00/isptcm.htm ... ENTRY Parameter values are as follows: ENTNAME A valid TSO command name. This operand is required for ENTRY calls. The alphabetic characters in ENTNAME must be in uppercase letters. Duplicate entry names cause an error message to be issued. Sounds like a command processor. Command processors are subtly different from ordinary programs, although I believe either is found in the STEPLIB/TASKLIB/ISPLLIB concatenation. On Mar 3, 2014, at 7:14 PM, Paul Gilmartin wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key OP was trying for KEY 7. That may be harder. Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
The X'20' bit has to be set ? Sent from my iPhone On Mar 3, 2014, at 7:45 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:21:20 -0500, Micheal Butz wrote: Now that you bought it up I think ISPF has a table ISPTCM where you specify authorized command it's in the ISPF customization guide Hmmm. Didn't know about that. I see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.f54pc00/isptcm.htm ... ENTRY Parameter values are as follows: ENTNAME A valid TSO command name. This operand is required for ENTRY calls. The alphabetic characters in ENTNAME must be in uppercase letters. Duplicate entry names cause an error message to be issued. Sounds like a command processor. Command processors are subtly different from ordinary programs, although I believe either is found in the STEPLIB/TASKLIB/ISPLLIB concatenation. On Mar 3, 2014, at 7:14 PM, Paul Gilmartin wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key OP was trying for KEY 7. That may be harder. Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Yes ... SPKA requires SUP state From: Micheal Butz michealb...@optonline.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, March 3, 2014 5:05 PM Subject: Re: ISPF storage protection Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Sent from my iPhone On Mar 3, 2014, at 6:51 PM, Douglas P Ewen dpe...@bellsouth.net wrote: Hello, I have a product that uses ISPF panels to allow the user to specify control information for the product. This control information is turned into a control block and then passed(XCTL) to a program that attempts to add the control block to a queue which resides in storage key=7. Although I have APF authorized the program that tries to update the que, I cannot get into a key=7 using the MODESET SVC. The MODESET SVC fails with system completion code=047. Is there anyway to allow a program to successfully issue the MODESET SVC under ISPF? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Mon, 3 Mar 2014 18:14:00 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. In part because, depending on what the APF-authorized program does, it can be dangerous to allow it to run under TSO, or dangerous to allow it to run with certain forms of parameter list. And, I think, in part for performance. If a program is not in the table then the TMP does not need to figure out whether the program is in an APF-authorized library and linked AC(1), it can simply invoke it using ATTACH or LINK, without needing to setup the special protections needed for running APF-authorized programs under TSO. And in part for function, since a program invoked in the method required for APF-authorized programs is in some ways limited in what it can do (it can't interact with ISPF, for example, without special coding in the program). -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
That is exactly right if you are running an ISPF program e.g. One that used DM services It's best to be in problem state while issuing the DM service Being in supervisor whine issuing DM services causes problems Sent from my iPhone On Mar 3, 2014, at 8:06 PM, Walt Farrell walt.farr...@gmail.com wrote: On Mon, 3 Mar 2014 18:14:00 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. In part because, depending on what the APF-authorized program does, it can be dangerous to allow it to run under TSO, or dangerous to allow it to run with certain forms of parameter list. And, I think, in part for performance. If a program is not in the table then the TMP does not need to figure out whether the program is in an APF-authorized library and linked AC(1), it can simply invoke it using ATTACH or LINK, without needing to setup the special protections needed for running APF-authorized programs under TSO. And in part for function, since a program invoked in the method required for APF-authorized programs is in some ways limited in what it can do (it can't interact with ISPF, for example, without special coding in the program). -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
On Mon, 3 Mar 2014 20:25:40 -0500, Micheal Butz wrote: That is exactly right if you are running an ISPF program e.g. One that used DM services It's best to be in problem state while issuing the DM service Being in supervisor whine issuing DM services causes problems I would hope that anyone who codes a program to issue DM services and links it AC=1 into an authorized library would take suitable steps to ensure system integrity. On Mar 3, 2014, at 8:06 PM, Walt Farrell wrote: ... I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. In part because, depending on what the APF-authorized program does, it can be dangerous to allow it to run under TSO, or dangerous to allow it to run with certain forms of parameter list. Aha! The difference between a JCL-style PARM and the CPPL. But I see there's an AUTHCMD section of IKJTSOxx to take care of that. I see little need for AUTHPGM. But ... And, I think, in part for performance. If a program is not in the table then the TMP does not need to figure out whether the program is in an APF-authorized library and linked AC(1), it can simply invoke it using ATTACH or LINK, without needing to setup the special protections needed for running APF-authorized programs under TSO. Nearly pointless. There are numerous ways to waste resources without APF authorization. And in part for function, since a program invoked in the method required for APF-authorized programs is in some ways limited in what it can do (it can't interact with ISPF, for example, without special coding in the program). In which case, it simply fails. Does this threaten system integrity? See my first remark above. I can't imagine why someone would APF-authorize a program which interacts with ISPF without such special coding. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Homework posted. Not due till Friday. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: Monday, March 03, 2014 4:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection Paul Now that you bought it up I think ISPF has a table ISPTCM where you specify authorized command it's in the ISPF customization guide Sent from my iPhone On Mar 3, 2014, at 7:14 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb 400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF storage protection
Sorry off topic posts. I do not know why this some posts are going to IBM Main. I am trying to reply to my students. Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike La Martina Sent: Monday, March 03, 2014 5:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection Homework posted. Not due till Friday. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Micheal Butz Sent: Monday, March 03, 2014 4:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF storage protection Paul Now that you bought it up I think ISPF has a table ISPTCM where you specify authorized command it's in the ISPF customization guide Sent from my iPhone On Mar 3, 2014, at 7:14 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 3 Mar 2014 19:05:29 -0500, Micheal Butz wrote: Is your program in a APF authorized library link edit with AC=1 You can also use the SPKA instruction if the The only thing you desire to do is change the PSW storage key Additionally: see: http://pic.dhe.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ikjb 400/usmi.htm to run authorized under TSO, a program must be named in the AUTHPGM NAMES( ... ) section of SYS1.PARMLIB(IKJTSOxx). ISPF may impose further constraints. I have no idea why APF authorized library and link edit with AC=1 alone don't suffice. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
