*2. Run authorized tasks in parallel with unauthorized tasks - bigger issue.You cannot use any user key storage - even the passed save area or the LEanchor. No LM 14,12,12(13) at the end of your module - use SVC 3. AllSTORAGE/GETMAIN to protected subpools. And if you will be fetching fetchprotected storage, you must block the unauthorized tasks while doing it so* *that they cannot examine your RBs and possible see storage contents. *
Binjamin, Are supervisor PC routines included? The save areas and PR instruction are handled by z/OS. I definitely see the exposure of modifying user passed data without any validation, but this same exposure is present in space switching PC routines hosted by an authorized address space. Thank you, Brian Chapman On Thu, Mar 28, 2019 at 10:45 AM Binyamin Dissen <bdis...@dissensoftware.com> wrote: > Two separate things: > > 1. Prepare user supplied authorized services and then change the job to > unauthorized - perfectly fine,as long as you follow standard authorized > service logic, i.e., never trust any user supplied address and use > protected > storage as your worrkarea. > > 2. Run authorized tasks in parallel with unauthorized tasks - bigger issue. > You cannot use any user key storage - even the passed save area or the LE > anchor. No LM 14,12,12(13) at the end of your module - use SVC 3. All > STORAGE/GETMAIN to protected subpools. And if you will be fetching fetch > protected storage, you must block the unauthorized tasks while doing it so > that they cannot examine your RBs and possible see storage contents. > > On Thu, 28 Mar 2019 09:06:02 -0400 Brian Chapman <bchapma...@gmail.com> > wrote: > > :>Searching through the archives, I quickly saw that this has been a repeat > :>heated discussion, but > :>all of the discussions seem to ignore the fact that CICS initializes as > an > :>authorized address space, performs authorized work, and then disables > :>authorization to load unathorized programs from the DFHRPL tasklib. It > does > :>what so many people deem to be a security integrity violation. > :> > :>I have an unauthorized address space that collects information from the > :>system and uses MQ or CICS EXCI (if MQ is unavailable) to transport the > :>data to another address space which stores the data to DB2. Having the > :>ability to execute authorize services would greatly increase the > :>functionality of this address space. Since neither of these transport > :>mechanisms are authorized, i cannot run authorized in the current setup. > :> > :>The idea is to execute the authorized requests as non-system supervisor > PC > :>routines. One of the PC routines would be to simply disable JSCBAUTH > (ONLY > :>disable. NEVER enable). Before invoking this PC routine, I perform a > :>MODESET to switch back to problem state and key 8. The only authorized > :>services performed before this switch would be the LXRES, ETDEF, ETCRE, > and > :>ETCON services to build the PC routines. After invoking the JSCBAUTH > :>disable PC routine from the job step program, I cannot switch back. > :>Invoking a MODESET after the switch abends address space with a 047. > :> > :>From this point forward, all of the ATTACH and LOAD services are > performed > :>with the supplied tasklib. The unauthorized code is COBOL. Before this > :>program is invoked, it initializes LE and replaces the default CEEZLOD > and > :>CEEZDEL with my own version that loads from the tasklib. > :> > :> > :>Thank you, > :> > :>Brian Chapman > :> > :>---------------------------------------------------------------------- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
