It should also be noted that the vast majority of CICS application programs are loaded from the DFHRPL concatenation which contains many libraries that are not typically APF authorized. I think you are pretty safe.
-- Donald Grinsell, Systems Programmer Enterprise Technology Services Bureau SITSD/Montana Department of Administration 406.444.2983 (D) "There couldn't be a society of people who didn't dream. They'd be dead in two weeks." ~ William S. Burroughs > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ray Overby > Sent: Wednesday, April 05, 2017 11:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Do you use CA-ACF2 and CICS or IMS? Be aware your CICS/IMS > developers have security admin priviledges and can do whatever they want to > the ACF2 database. > > Leonardo, > > Do the CICS and IMS developers have WRITE or higher access to an APF > authorized library? In other words, when they create a program to issue the > ACF2 SVC A supercall request is that load library APF? I would assume that > the program was link edited as AC(1). > > I was the ACF2 developer that originally implemented the ACF2 supercall > support. This update was likely completed by me sometime in the early 80's. I > left SKK/UCCELL/CA in July of 1988 so I have no idea what changes were made > to the ACF2 code after I left. There are several things to point out for the > code I created way back when: > > - Supercall was implemented in SVC A only. SVC S was not changed. > > - SVC A implements system entry validation (logon) and system exit > (logoff) as well as LOGONID, ACCESS RULE, and INFOSTG database i/o. > > - Supercall (as I implemented it) required the requester (i.e. the > program that issued SVC A with Supercall) to be "apf authorized". I can't > remember if I tested for PSW Key 0-7 and/or Supervisor state in addition to > APF. > > - PSW Key 8 problem state programs that are not APF authorized were > not allowed to successfully issue SVC A supercalls. > > - Supercall was not limited to just CICS/IMS developers. It was > limited to any ACF2 user who has WRITE or higher authority to an APF > authorized library AND the program is link edited as AC(1). > > Bottom line is application programs (PSW Key 8 problem state NON-APF) should > not be able to successfully issue the SVC A Supercalls. I can't say how the > ACF2 code works today but I believe this was how it worked as of July, 1988. > > So, if your CICS and IMS developers CAN successfully issue ACF2 SVC A > supercall requests AND they do not have WRITE or higher access to an APF > authorized library then there may be an "integrity" problem. I would suggest > reporting to CA that your PSW Key 8 problem state non-apf authorized program > can successfully issue ACF2 SVC A supercall requests. > Be prepared to provide the program as well as the output from the call to > demonstrate it works. > > If your installation has given WRITE or higher access to an APF authorized > library to the CICS and IMS developers then this is a problem created by the > installation. Note that giving WRITE or higher access to an APF authorized > library is analogous to giving a linux user root authority. Users with WRITE > or higher access to an APF authorized library can do anything they want to > the system......... > > You should note that RACF (and probably TSS) have similar capability to the > ACF2 SVC A supercall support. For example, as an APF authorized program I can > issue SAF calls (RACROUTE) to create and delete security credentials with NO > extra ordinary RACF privileges. I can also issue ICHEINTY's to read/update > the RACF database as an APF authorized program with NO extra ordinary RACF > privileges. In my mind, I see no difference between the "original" ACF2 > supercall support and how RACF works today (I may be biased ). > > In general, z/OS APIs that have a code path that any user can execute and > other code paths that are restricted to authorized users will ALLOW APF > authorized program to execute the restricted code path. So, by giving someone > update access to an APF authorized library you are saying "they can invoke > ANY API that is available on this system that would normally be restricted". > That would include the ACF2 SVC A supercalls. > This would include all RACROUTE requests........... > > Assuming that the CICS and IMS developers have WRITE or higher access to an > APF authorized library the real question is: Why would an organization give > CICS and IMS application developers WRITE or higher access to an APF > authorized library? CICS transactions "normally" would not need to be APF. I > am not as familiar with IMS application coding but would think they would not > require it either. By giving these developers WRITE or higher access to an > APF authorized library the INSTALLATION is allowing them to issue ANY of the > restricted APIs on the installations z/OS system (not just the ACF2 SVC A > supercalls). > > I hope this information helps clarify things for you. > > Ray Overby > On 4/5/2017 10:38 AM, Leonardo Vaz wrote: > > "And that's working as designed" is the reply I got from CA... and they > don't see it as a security exposure... > > > > Well, I do see it as a HUGE security exposure, and I would like to know > what my fellow IBM-MAIN'ers think. > > > > ACF2 has an SVC call facility called "Supercall Facility", which any > program executing under a CICS region or IMS region can use. If they do, they > have unrestricted read/write access to the ACF2 database. > > > > I just can't get my head around CA thinking that's ok just because it has > "always been that way (TM)". Am I being overdramatic? Do you think it's OK > for CICS/IMS developers to have security admin privileges? > > > > Thanks for any feedback, > > Leo > > > > ---------------------------------------------------------------------- > > 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
