On 12/8/10 4:15 PM, "Quay, Jonathan (IHG)" <[email protected]> wrote:
>I don't. I don't have any human beings on my systems except for system >programmers that have full authority anyway. Having to GRANT linux >servers is an extra thing that has to be managed. I would like to >define a vswitch as unrestricted. > >Is there anyone out there that actually gains security from CP users not >being granted onto their vSwitches? How many people would like to be >able to >define a vSwitch as "open to the public" or not requiring a grant to be >accessed? I'll make a counter argument: there is a significant difference between being allowed to create a piece of infrastructure, and being allowed to use it. Granting permission to use something after it's created is that second item, and I would say that there is a very good reason to have the two steps separate so that they can be separately controlled and audited. So, I think I'm going to side with Alan. If you want an unrestricted VSWITCH, you need to kick your ESM vendor to allow you to control them and declare a rule that anyone can attach to said VSWITCH. OTOH, I think this also argues for a bigger step: for IBM to supply a default ESM and quit having to do it two different ways. We can always replace the default one with something better, but there's a lot of wheel-spinning being done in IBM development to support the two different models. Personally, I dislike RACF with a passion, but I'd rather have RACF be present by default and have one single way to do security management (via the ESM) than have to have a completely separate command authorization matrix to worry about via CP privilege classes, etc, etc, etc. It may have worked in the past, but it's time HAS past. There's too many regulations and too many hostile bozos out there to not have a comprehensive security management tool as part of the VM hypervisor suite. If that means we all have to suffer under RACF for long enough to turn it off, then so be it. >
