On Wednesday, 06/16/2010 at 02:02 EDT, David Boyes <[email protected]> wrote: > I'd make a counterargument that if IBM intends to position z/VM only as a Linux > hosting environment, then the current setup that requires the user to have the > skills to rebuild CP to enable an ESM (which Chuckie usually recommends) is > highly user-hostile, and needs to be resolved at the CP layer, not in > third-party products. Every ESM shouldn't have to invent the CP interface > wheel. A cleaner, less intimately entwined, set of security interfaces would be > good for everyone, including the IBM products, and with the enormous amount of > work going into z/VM 6.next, this would be a good time to architect it in.
When building an ESM, you have some fairly complex challenges. At the top of the list, the ESM 1. Cannot be simply or easily circumvented (even by a sysadmin [as opposed to sysprog] ), 2. Must enforce a limited set of operations when the ESM server is down sufficient only to get the ESM server back up and running or to declare "The ESM's dead, Jim." 3. Must recognize and differentiate system initialization activities from 'steady state' stuff 4. Must generally support the idea the CP is the enforcement point. Policy may be derived from a server, but CP is where the Real Decisions are made and where it is understood that, sometimes, the policy does not apply or is a Really Bad Idea in some cases. That's impossible to do if all the logic is in the server. If the complaint is that ESMs are too hard to install and/or configure, then people who feel that way should open requirements. Neither IBM nor CA need changes in the published CP-ESM interfaces to address such requirements. Alan Altmark z/VM Development IBM Endicott
