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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
