On Fri, 16 Mar 2018 19:44:11 +0000, Farley, Peter x23353 wrote: >I do not understand -- How can a second authorized program running >concurrently to an already-running authorized program provide opportunity for >an integrity threat? Or am I just not clever (or evil) enough to conceive of >a way to violate integrity in such a scenario? Don't all the normal >authorized integrity rules and fences still hold for concurrent programs? > Others can probably provide better answers than mine.
Suppose the second program is not authorized, but a user written program? Suppose the authorized program uses user key storage, at risk for modification by the non-authorized program. There are elaborate rules for providing itegrity for programs with AC=1 or loaded from APF authorized libraries, with many assumptions: o Authorized programs are loaded as job step tasks. There is no issue of concurrency. o Or authorized programs are loaded by the TSO TMP which strives to provide a job step like environment by locking out all other processes while a CALLed program runs. o Or ATTACHed by APF-authorized programs, in which the caller is responsible for providing integrity of the operation. I believe failure of these assumptions led to IO11698. IBM discovered a weakness that couldn't be fixed, so IBM wrapped the facility in RACF so that, according to the Statement of Integrity IBM could blame the customer if anything went wrong because the customer violated some rule that IBM has chosen never to disclose. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
