Wayne, I hadn't known that about the DSI keyword on PPT entries.
My understanding until now had been: 1) OPEN always invokes SAF, which then invokes RACHECK processing. 2) RACHECK processing bypasses all checks if the trusted or privileged bit is set (logging done for the former but not the latter). These bits are typically set in STDATA segments for STCs. I had always thought that NODSI was applied at ALLOCation time to determine whether or not a SYSDSN ENQ is to be issued. Ya learn something new every day. Thanks for that clarification. Alan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Wayne Driscoll Sent: Friday, April 02, 2010 15:12 To: [email protected] Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Paul, Thankfully, APF authorization and system resource access security are 2 separate things. When the OPEN SVC gets invoked, it will perform a RACROUTE REQUEST=AUTH call for the dataset being opened, regardless of the value in JSCBAUTH. The only way that security checks are bypassed is via the NODSI option in the PPT. Now an APF authorized program could switch to key 0 and update various fields so the security system thinks they have more authority than they really should, but that isn't an issue when using a utility, particularly one that is covered under the z/OS statement of integrity. =============================================== Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com =============================================== From: Paul Gilmartin <[email protected]> To: [email protected] Date: 04/02/2010 05:04 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Sent by: IBM Mainframe Discussion List <[email protected]> On Fri, 2 Apr 2010 16:47:54 -0500, Wayne Driscoll wrote: >Ed's concern is much more valid and realistic than Gil's. In Gil's case, >having SYSPUNCH refer to SYS1.PARMLIB, or some other protected dataset >really won't cause a problem, because APF authorization doesn't >automatically bypass the security system. However, a maliciously coded > OK. Educate me. I had thought that once a program was APF authorized, it became the responsibility of that program to issue the SAF calls and respect the replies; if not, the program could do anything it wanted. For example, suppose someone link edited IEBGENER into an APF authorized library and marked it AC=1. Now, I do: //STEP EXEC PGM=IEBGENER //STEPLIB DD DISP=SHR,DSN=... //SYSUT2 DD DISP=SHR,DSN=SYS1.PARMLIB(...) //SYSUT1 DD * ... Where does it fail? >HLASM user exit could, since it contains customer supplied code. Of >course, if the Assembler is invoked via SMP/E authorized, those HLASM >exits will have to be located in an APF authorized library, or else a 306 >abend will occur, so the writer of the malicious exit will still need a >way to update an APF library. > And that wouldn't happen, except at Bob Shannon's site. Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
