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.

2017-04-06 Thread Steve Beaver 
Command-level Assembler Resource Rule Example
A command-level Assembler resource rule example follows:

FUNCT CLI TYPE,C'A'   TEST RECALCULATE 
FUNCTION BNE OTHER IF NOT, BYPASS 
* THE FOLLOWING ROUTINE WILL RECALCULATE PAYROLL AMOUNTS. 
* CALL CA ACF2 TO DETERMINE IF USER IS ABLE TO DO THIS FUNCTION. 
* DO NOT ABEND IF VIOLATION, JUST TELL US SO WE CAN CONTINUE. 
UPDAMTS   MVI UCRSCREQ,UCRSCRIN SET TO DO RULE INTERPRET 
   MVC UCRSCTNM,=CL8'PAYROLL' SET PAYROLL RESOURCE 
  MVC UCRSCNME,=CL40'RECALCULATE' SET FUNCTION CODE 
  MVI UCRSCAC,UCRSCAAC SET FOR GENERAL ACCESS 
  MVI UCRSCVER,UCRSCVEY LET CA ACF2 VERIFY PASSWORD 
 MVI UCRSCABD,UCRSCABN DO NOT ABEND IF VIOLATION 
EXEC CICS LINK LINK TO CA ACF2 CICS X 
 PROGRAM('ACFAEUCC') X 
 COMMAREA(ACFAEUCR) X 
 LENGTH(512) 
   MVC MSG1(L'UCRSCMTX),UCRSCMTX MOVE IN MESSAGE 
  CLI UCRSCRC,UCRSCRA TEST ACCESS ALLOWED 
  BE DOIT IF SO, LET IT RUN 
 MVC MSG2(43),=C'USER NOT AUTHORIZED TO UPDATE AMOUNT 
FIELDS' 
 B SCREEN DISPLAY AND GET NEXT REQUEST. 

* CA ACF2 PERMITS THIS, SO CONTINUE PAYROLL AMOUNT CHANGES. DOIT DS OH ROUTINE 
TO PROCESS PAYROLL AMOUNT FIELDS.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, April 6, 2017 3:30 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.

The issue with MUSASS (apparently an ACF2 term but applicable to any security 
product) is that the task itself has a SAF userid that is used for task-level 
accesses, but each logged in userid must be presented for user-level accesses. 
Unless this distinction is preserved meticulously, taskid access can spill over 
to an individual userid, granting (usually) elevated privilege that was never 
intended.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Thursday, April 06, 2017 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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.

Multiple Users in a Single Address Space. (MUSASS)

In the CICS program there is a HLL interface to ACF2.  Very easy to setup and 
use

Steve   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, April 6, 2017 2:33 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.

 
> Peter -  What are you attempting to do? 
 >
> Steve


Me? Its not my thread, I just followed it with interest. I did not
understand the term MUSASS. That's all


--
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

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.

2017-04-06 Thread Jesse 1 Robinson 
The issue with MUSASS (apparently an ACF2 term but applicable to any security 
product) is that the task itself has a SAF userid that is used for task-level 
accesses, but each logged in userid must be presented for user-level accesses. 
Unless this distinction is preserved meticulously, taskid access can spill over 
to an individual userid, granting (usually) elevated privilege that was never 
intended.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Thursday, April 06, 2017 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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.

Multiple Users in a Single Address Space. (MUSASS)

In the CICS program there is a HLL interface to ACF2.  Very easy to setup and 
use

Steve   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, April 6, 2017 2:33 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.

 
> Peter -  What are you attempting to do? 
 >
> Steve


Me? Its not my thread, I just followed it with interest. I did not
understand the term MUSASS. That's all


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

2017-04-06 Thread Steve Beaver 
Multiple Users in a Single Address Space. (MUSASS)

In the CICS program there is a HLL interface to ACF2.  Very easy to setup
and use

Steve   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Thursday, April 6, 2017 2:33 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.

 
> Peter -  What are you attempting to do? 
 >
> Steve 


Me? Its not my thread, I just followed it with interest. I did not
understand the term MUSASS. That's all. 

--
Peter Hunkeler 

--
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

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.

2017-04-06 Thread Peter Hunkeler 

> Peter -  What are you attempting to do?
 >
> Steve


Me? Its not my thread, I just followed it with interest. I did not understand 
the term MUSASS. That's all.

--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

2017-04-06 Thread Steve Beaver 
Peter -  What are you attempting to do?

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mullen, Patrick
Sent: Thursday, April 6, 2017 8:34 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.

ACF2 speak for multi-user address space, eg CICS, IMS, DB2, as opposed to a
single user address space like TSO, batch job.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Thursday, April 06, 2017 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: 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's either APF authorization or running in a MUSASS address space, the
second one is the problem. 
 

Pardon my ignorance, but can you explain in a few words what a MUSASS
address space is?




--
Peter Hunkeler



--
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

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.

2017-04-06 Thread Mullen, Patrick 
ACF2 speak for multi-user address space, eg CICS, IMS, DB2, as opposed to a 
single user address space like TSO, batch job.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, April 06, 2017 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: 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's either APF authorization or running in a MUSASS address space, the 
> second one is the problem. 
 

Pardon my ignorance, but can you explain in a few words what a MUSASS address 
space is?




--
Peter Hunkeler



--
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

Re: AW: 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.

2017-04-06 Thread Ray Overby 
Multiple User Address Space or MUSASS for short. MUSASS is a LOGONID 
attribute that is assigned via ACF command. It is assigned to an address 
space where multiple users are "active" in the address space.  Examples 
of a MUSASS address space are CICS and IMS. There are others.



On 4/6/2017 12:16 AM, Peter Hunkeler wrote:

It's either APF authorization or running in a MUSASS address space, the second 
one is the problem.
  


Pardon my ignorance, but can you explain in a few words what a MUSASS address 
space is?




--
Peter Hunkeler



--
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

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.

2017-04-06 Thread Anthony Thompson 
Muilti-User Single Address Space System.

Pretty much what it says. It's an ACF2 term that refers to things like CICS.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Thursday, 6 April 2017 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: 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's either APF authorization or running in a MUSASS address space, the 
> second one is the problem. 
 

Pardon my ignorance, but can you explain in a few words what a MUSASS address 
space is?




--
Peter Hunkeler



--
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

AW: 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.

2017-04-05 Thread Peter Hunkeler 
> It's either APF authorization or running in a MUSASS address space, the 
> second one is the problem.


Pardon my ignorance, but can you explain in a few words what a MUSASS address 
space is?




--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

2017-04-05 Thread Steve Beaver 
Ray

I was wondering when you were going to chime in

Steve  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonardo Vaz
Sent: Wednesday, April 5, 2017 1:30 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.

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

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.

2017-04-05 Thread Leonardo Vaz 
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

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.

2017-04-05 Thread Leonardo Vaz 
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

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.

2017-04-05 Thread Leonardo Vaz 
Hello Tony!

It's either APF authorization or running in a MUSASS address space, the second 
one is the problem.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, April 05, 2017 1:45 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.

On 5 April 2017 at 11:38, Leonardo Vaz  wrote:
> 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 thought use of ACF2's Supercall required APF authorization. We use it in our 
products, and our code comments imply the need for APF. If it doesn't, then 
what *does* control access to Supercall? If it does, and your CICS and IMS 
users are already running with APF auth, then all is lost already.

Tony H.

--
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

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.

2017-04-05 Thread Grinsell, Don 
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

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.

2017-04-05 Thread Ray Overby 

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 /

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.

2017-04-05 Thread Tony Harminc 
On 5 April 2017 at 11:38, Leonardo Vaz  wrote:
> 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 thought use of ACF2's Supercall required APF authorization. We use
it in our products, and our code comments imply the need for APF. If
it doesn't, then what *does* control access to Supercall? If it does,
and your CICS and IMS users are already running with APF auth, then
all is lost already.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

2017-04-05 Thread Steve Beaver 
For CA-ACF2 there is a HLI interface.  Not Much to set up.  As for changing
authority levels.  Can't be don



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonardo Vaz
Sent: Wednesday, April 5, 2017 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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.

"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

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.

2017-04-05 Thread Lizette Koehler 
If you have not done so, you may also wish to post this question on the RACF
list.  The generic question

SHOULD CIC/IMS be able to do this, could be a valid question for them

To join, if you have not done so use this URL
RACFhttp://www.listserv.uga.edu/archives/racf-l.html

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Leonardo Vaz
> Sent: Wednesday, April 05, 2017 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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.
> 
> "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

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.

2017-04-05 Thread Leonardo Vaz 
"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