On Tue, 5 Jul 2011 19:15:45 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:
># Enhancements are planned for the IEBCOPY utility that are intended > to improve performance when copying a partitioned data set (PDS) > to another PDS. In addition, IEBCOPY is planned to exploit 31-bit > storage for track buffers, and the current requirement for APF > authorization is planned to be removed in z/OS V1.13. > >Wow! Then I could run SMP/E also without APF authorization, >provided I avoid using the WAIT option on DDDEFS. Could this >result in a relaxation of the constraints introduced by the >notorious APAR IO11698? I insist on my view that if a program >operating without APF authorization can leverage an integrity >exposure, the OS itself needs repair; it is insufficient to >repair that program or restrict access to it. You don't need to "insist on (your) view", gil. That's the basic idea of our z/OS Integrity Statement. Unauthorized programs must not be able to compromise the system in contravention of the security and integrity controls the system implements. (That's just my unofficial rephrasing, for the purpose of this discussion, by the way, and not an official IBM statement of our policy.) The issue with SMP/E that resulted in that APAR is different, though, as SMP/E -does- operate with APF authorization, and therefore applying some restrictions (such as over who can run it) is an appropriate control mechanism, but it's not the situation you mention above (restricting who can run an unauthorized program). Additionally I'll note that we do allow unauthorized programs to perform sensitive operations under the control of a RACF authorization check. While one might view that as a form of restricting access to the program, it's really a control implemented at a lower level, within the system itself. And so we view that as an appropriate control mechanism. One example (among many) is that an unauthorized programs with authority to an appropriate CSVAPF-prefixed resource in the FACILITY class can make changes to the system APF configuration. But if you don't allow it via that FACILITY check, the action is not allowed unless the program runs authorized. If an unauthorized program were able to take that action, without having the appropriate RACF authority, then yes, I would agree that the OS is broken and needs a fix, and that asking you to restrict access to the program itself (e.g., via RACF PROGRAM control, or restricting access to the load library) would not be appropriate. By the way, I have no idea if or when we might plan to change SMP/E so it runs unauthorized, but I consider the change to IEBCOPY to be one step in the right direction that might help allow that change one day. I also have no idea what it would mean for the authorization checks that SMP/E APAR introduced, but that's clearly something for us to consider someday, too. -- Walt Farrell IBM STSM, z/OS Security Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
