Richard, You probably have CPIGNORE DIRLINK specified in your VMXRPI CONFIG file. That tells VM:Secure to not check rules for directory links at logon time.
Dennis O'Brien There are 10 kinds of people in the world; those that understand binary and those that don't. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Tuesday, October 24, 2006 14:46 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VSWITCH Around here, the [EMAIL PROTECTED]& (expletive deleted) people are more interested in keeping our production network and systems clean. VM is a development machine on a development network (and ne'er the twain shall meet), so they pretty much come to us about issues or, sometimes we point out security risks/holes. Number 3 is not a major concern yet (but will be when we have production VMs with Linux guests). Since when didn't the LINK in the directory confer privilege, with or without an ESM? I just tried rejecting any LINK to any of my disks from a specific user. I then added a LINK to one of them in the user's directory. When I logged the user on, it quite happily had the specified disk linked. The REJECT rule was overridden or, maybe, not even consulted. We have that other product for our ESM and the Rules Facility is active. Still, the rest of the reasons make a good enough case. Thanks, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Tuesday, October 24, 2006 2:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VSWITCH On Tuesday, 10/24/2006 at 01:33 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Is there some reason that having a "NICDEF 500 TYPE QDIO LAN SYSTEM VMTEST" in > the directory does not authorize the user for that switch? Hmmm...you probably weren't looking for the "Because we didn't want it to work that way" response, were you? }:-) There are a few reasons rolling around in there. 1. The switch management model itself. Turning ports on and off and assigning VLANs is the job of the switch administrator. When you plug your OSA into a switch, you are not, just because you plugged the cable in, given access. 2. Auditability. The switch-based security model allows you to know who has access without regard to whether they are currently logged on. This improves auditability and avoids having to scan the directory. 3. Security. It is increasingly the case that the roles of "security admin" and "system admin" do not reside in the same person. 4. Consider the LINK command in the directory. Without an ESM, it confers permission. With an ESM, it does not. Do we continue that same weird model? Or do we just bite the bullet and separate authorization from configuration? Any one of them was probably not enough to do it the way we did (though #3 is pretty persuasive), but taken together and looking into our cheap glass ball (couldn't afford crystal), it seemed that separate of authorization and configuration were appropriate. I think you will find more of this, not less, as time goes on, being driven primarily by #3 any more. We have customers who are adamant on this point. I have been informed, in no uncertain terms, that System Programmers do not rule the world. They must beg permission from Security Administrators just like .... Users (gasp!)... [sorry to use such ugly language]. Explaining about Ultimate Power does no good since a sysprog who exercises it will be taken out to the coffee machine and be forced to drink plain water, and the candy machine will be rendered forever inoperable. Alan Altmark z/VM Development IBM Endicott
