I apologize in advance to Karl Schmitz if I have a bit of this not quite exact.
>Perhaps some Integrity Vulnerability examples will help clarify: > >1) If your authorized program while executing in PSW key 0-7 stores >into an address provided by an unauthorized caller then this is a >violation of the IBM statement of integrity. The use of PSW key is imprecise. It's really "while not using the user's key, whether by that being the PSW key or by using MVCK/MVCDK/MVCSK/etc.". But, more important, the (corrected) statement applies both to stores into and fetches from an address. Not just stores. Still, with the exception that if the address has been validated to be a block that the authorized program owns and that cannot change attributes while mid-stream and that is known not to be fetch-protected, maybe. There are any number of cases where unauthorized "input" identifies a system-key system block (which is verified as being a system block) and that block gets updated as a result of a service call by the system running in system key. >3) If your authorized program while executing in PSW Key 0-7 or >supervisor state returns control to an unauthorized requester in an >authorized state then this is a violation of the IBM statement of >Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or >now has the ability to MODESET. You really also need to add "unintended" if "unauthorized" refers only to key, state, and APF. This is allowed as long as it is done correctly, which includes limiting it to only the intended requestor(s). Getting that correct is the difficult part. And of course that's at heart of this whole thread. Whether done by a PC FLIH intercept returning via LPSW(E), or an SVC routine manipulating the RB, or a stacking PC manipulating the linkage stack, the concept is the same. >4) If your authorized program while executing in PSW Key 0-7 copies >fetch protected storage to non-fetch protected storage then this is a >violation of the IBM statement of integrity. This is not necessarily a violation of the IBM statement of integrity. It depends on whose data is being copied. I am allowed to put my own non-sensitive data into fetch-protected storage and copy it to non-fetch protected storage if I so choose. The requirement is that I not allow the unauthorized user to access something he should not be given access to. Fetch protection is just one tool in the bag of tricks. The owner of the data is typically the one that decides what the access limitations are to be. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
