The bottom line is that the integrity/security of a current OS cannot be reduced to a lower integrity/security level by upgrading it to a new OS - as e.g. upgrading OS/390 to z/OS could not result in z/OS then being less secure than OS/390. Hence the argument that the integrity/security provided by 'REUS, RENT, REFR' in OS/390 does not apply to z/OS is absurd - as this would imply that z/OS is less secure than OS/390. BTW AFAIK It is programs running in key 0-7, not only in key 0, that are storage protected. If memory serves, CICS (and/or perhaps IMS) executes in key-7 not key-0. AFAIK2 LMOD storage is always allocated in multiples of 4K pages. If so, a 5K module would be allocated 2 pages of 4K each - and both its 4K pages (total 8K) would then be OS-protected.
On 30/08/2021 00:23, Joel C. Ewing wrote: > If REFRPROT is used, the affected module is loaded into a key-0 storage > pool, so even if a partial page at the end of the module is not "page > protected", it is still key-0-protected and only a program running in > key 0 can modify it. > > A program running in key-0 that could directly modify the final partial > page could also in theory page-fix any of the full pages of the module, > bypass any "page protection" and update a protected full page as well, > so if you allow malicious programs to run in key-0, as always all bets > are off. > > Since deliberate malicious modification by key-0 code is always > possible, this partial page additional exposure is probably minimal. > If you wanted to rule out the possibility of any accidental modification > by key-0 code of the entire module, the simplest solution would be to > force the length of REFR modules to a multiple of 4KiB so there are no > partial pages. Maybe this size rounding should be an option for REFR > modules now that real-storage and virtual-storage constraints are less > of an issue for many installations. > Joel C. Ewing > > On 8/29/21 5:59 AM, Lennie Dymoke-Bradshaw wrote: >> I realise I may be inviting a "YDNRC" but I think the REFRPROT (not REFPROT) >> option only protects entire pages of a module. If a module is 5K long then >> the last 1K is unprotected. Always sounded like an opportunity for >> exploitation; bit like a buffer overrun. >> >> Lennie Dymoke-Bradshaw >> https://rsclweb.com >> 'Dance like no one is watching. Encrypt like everyone is.' >> >> -----Original Message----- >> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >> Peter Relson >> Sent: 28 August 2021 15:02 >> To: [email protected] >> Subject: Re: RENT binder option >> >> <snip> >> RENT: MVS protects your module's virtual storage so that your module cannot >> be modified - and REFR implies RENT. >> </snip> >> >> z/OS ignores "refreshable" except when REFRPROT is in effect. >> Thus if "REFR implies RENT" then it is important that the RENT indicator be >> set when REFR is specified without RENT. I presume that that is what >> happens, but I have not tried it. >> >> "cannot be modified" is all a matter of degree. Anything can be modified if >> you are authorized enough. Some of the rules that apply (the rules are more >> complex, so this is not completely accurate): >> -- RENT modules not from an APF-authorized library are not placed in key 0 >> storage so they "can" be modified by an unauthorized program >> -- RENT modules from an APF-authorized library are placed in key 0 storage >> so they "can" be modified by a key 0 program. The same is true for a >> TCBKEY9 task >> -- REFR modules with REFPROT are page-protected. When page-fixed, they "can" >> be modified by using real addresses >> >> Peter Relson >> z/OS Core Technology Design >> >> >> ---------------------------------------------------------------------- >> 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
