On Mon, 9 Sep 2019 13:19:40 -0400, Tom Conley wrote:
>On 9/9/2019 1:04 PM, Mark Zelden wrote:
>> On Mon, 9 Sep 2019 07:55:29 -0500, Peter Fatzinger wrote:
>>
>>> The 1M increment for RUCSA storage was not chosen haphazardly. We
>>> understand the scarcity of below-the-line memory, but in order to provide
>>> the isolation needed to adequately protect the area we couldn't use any
>>> increment smaller than 1M.
>>
>> I pretty much assumed that, but thanks for the confirmation.
>>
>>> Also, in case anyone is unaware, beginning in z/OS V2R4 RUCSA is a
>>> separately ordered paid feature.
>
>Youse wants to break da rules, youse gotta pay.
>
How might security auditors look at RUCSA which:
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 in the FACILITY class, or
on z/OS® V2R3 or earlier systems that have the VSM ALLOWUSERKEYCSA(YES)
parameter specified
I suppose it depends on the breadth of the exposure.
This is vaguely similar to the changes introduced by IO11698: IBM found it
impractical to make the facility secure so they wrapped it with SAF so the
onus can be placed on the customer.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
