On Tue, 10 Sep 2019 09:12:21 -0400, Jim Mulder wrote:
> RUCSA was (reluctantly) designed to allow a particular set of customers to
>move to z/OS 2.4 while continuing to run a mission critical application for
>which the source code has been lost. RUCSA is not intended to be a
>model for future application development.
>
I might then expect that its use would be (reluctantly) tolerated by
security auditors.
On Tue, 10 Sep 2019 09:27:00 -0500, Tom Marchant wrote:
>On Tue, 10 Sep 2019 09:54:43 +0200, Martin Packer wrote:
>
>>If you are enabled to use User-Key CSA via RUCSA I believe you "have a
>>ticket to THE party", the ONE AND ONLY party. Meaning you can access other
>>users' allocations of User Key CSA.
>
>If I understand it correctly, anyone can access RUCSA storage once someone
>obtains it. The limitation is on who can issue GETMAIN (or STORAGE OBTAIN)
>for user key CSA.
Back to:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieae100/ieae1-rucsa.htm
... Accessible only from address spaces that are running under user IDs
that have SAF READ authority
to the IARRSM.RUCSA profile ...
"Accessible only" seems to imply that the restriction applies to read and
write as well as to OBTAIN. This might be achieved by segment protection's
mapping RUCSA into only address spaces suitably authorized by SAF. This
is suggested by the coarse granularity of RUCSA.
Of course if the community of users of that "mission critical application"
is large there's little protection within that site.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
