On Friday, 09/29/2006 at 11:57 EST, "Harding, Mike" <[EMAIL PROTECTED]> wrote: > Also look at the SYSSEC macro description in the Macros and Interfaces > manual. Changes do require reassembling HCPRWA and building a new CP > nucleus, so Alan's method is much simpler.
To clarify, SYSSEC is intended to control CP's response to RACF's deferrals and warnings. (I don't know why we let you change explicit failures and successes...that's not useful.) In a Common Criteria "evaluated configuration", for example, it is required that all RACF deferrals be translated to failures. Basically, the rule in that case is: "If RACF *can* control access, then it *must* control access." Fortunately we ship an alternate version of HCPRWA that includes the needed SYSSEC settings. But in most shops (as in the OP's case) "defer" is ok and means "let CP decide". When you deactivate a RACF class, all inquries about resources in that class come back with "defer". If you don't want RACF to control something, turn off the controls. Changing CP will simply confuse your auditors as it is not readily auditable from the 'outside'. Administrative confusion rarely results in improved security! Alan Altmark z/VM Development IBM Endicott
