Hello Ray! A pleasure to have a comment from one ACF2 developer himself.
Yes, I am talking about SVC A. and I have absolutely no problems with supercall being used in an authorized environment, when you are authorized you are GOD-like, we all know that. My problem is the allowance of it being used unrestricted in a MUSASS environment, even via a regular unauthorized program running in user key. That being said, I have to say that CA has called me back and said that the "working as designed" statement was a misunderstanding and they will be working on a solution. Thanks for everyone's feedbacks in-list and out-list. Regards, Leo -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ray Overby Sent: Wednesday, April 05, 2017 1:50 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. 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
