Hello Don! That's my problem with it, that a non-APF module can do that, I am talking about a regular DFHRPL loaded module.
Regards, Leo -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Grinsell, Don Sent: Wednesday, April 05, 2017 2:11 PM 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. 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
