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
