It is obvious that SMP/E is in the business of "executing" SYSMOD installation instructions. SMP/E is an APF authorized/superuser program, therefore it is a tempting attack surface. Since SMP/E is privileged, it must be carefully designed and controlled in order to avoid arbitrary code execution. Regardless of how much review and testing SMP/E undergoes and it could have still have a security hole, known or unknown; therefore it is only prudent to restrict who can use it.
Of course, any APF authorized/superuser program could be a tempting attack surface. Obviously, they should be thoroughly reviewed and tested before allowing public access. If their design or function has the possibility of arbitrary code execution, their use should be restricted to trusted users. A fair number of years ago I submitted a DCR suggesting that customers should have an optional facility to control access to APF libraries. I don't remember the details I suggested. Perhaps it was CLASS(FACILITY) 'APF.data-set-name' or maybe a new class CLASS(APFLIB) 'data-set-name'. In either case, the profile would apply to all APF libraries, in addition to their normal RACF profiles. APF libraries would have some protection, even if they had no regular data set profile. A profile like CLASS(APFLIB) ** UACC(READ) would prevent updates to all APF libraries, but allow execution. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Walt Farrell Sent: Tuesday, April 06, 2010 11:39 AM To: [email protected] Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 6 Apr 2010 13:28:11 +0200, R.S. <[email protected]> wrote: >Of course in every case we should know the meaning of the profiles and I >believe that the GIM.** profiles will be documented. It does not >contradict with the APAR statement - the risk details can be still obscured. >BTW: I bet the case is very bizarre case and it does not affect majority >of us, BUT the APAR officially falls into category "integrity" and gets >all the attributes of secrecy. I consider it as SPE (Small Programming >Enhancement) with disputable qualification. Sorry, Radoslaw, but while the implementation may have happened to provide a functional enhancement that some of you will find useful, we would not have released an APAR that -requires- those migration actions if it were merely an enhancement. We might have introduced such improved function via an APAR, but it would have been optional (e.g., "if you want to control function x you can define this profile", not "if you want to allow the program to continue working at all you must define a profile"). We do not lightly make such changes mandatory and force migration actions on our users in the service stream. There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). -- Walt Farrell, CISSP IBM STSM, z/OS Security Design ---------------------------------------------------------------------- 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
