Re: Using LBYONLY
On Friday, 03/06/2009 at 12:47 EST, Schuh, Richard rsc...@visa.com wrote: Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. I was given 50 lashes with a wet noodle here when I previously proposed that if you have LOGON BY authority to a user you should be able to - LOGON to the user - XAUTOLOG the user - Use FOR - Use SEND (even if not the secuser) - be the SECUSER or OBSERVER Except that I would not allow SET SECUSER/OBSERVER, SEND or FOR if the user was logged on or someone else is the secuser. Unlike the privileged versions of those commands, serial access to the user ID would be enforced. Alan Altmark z/VM Development IBM Endicott
Re: Using LBYONLY
I did not wield one of those noodles :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Sunday, March 08, 2009 10:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY On Friday, 03/06/2009 at 12:47 EST, Schuh, Richard rsc...@visa.com wrote: Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. I was given 50 lashes with a wet noodle here when I previously proposed that if you have LOGON BY authority to a user you should be able to - LOGON to the user - XAUTOLOG the user - Use FOR - Use SEND (even if not the secuser) - be the SECUSER or OBSERVER Except that I would not allow SET SECUSER/OBSERVER, SEND or FOR if the user was logged on or someone else is the secuser. Unlike the privileged versions of those commands, serial access to the user ID would be enforced. Alan Altmark z/VM Development IBM Endicott
Re: Using LBYONLY
On Friday, 03/06/2009 at 03:31 EST, Bob Bolch b...@zenoroad.com wrote: It?s perfectly fine to discuss the way things ?should be? ?vs- the way things ?are?, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. I think that we must continually assess the somewhat, uh, arcane nature of VM commands. By default, I believe that the ability for UserX to bring UserY onto the system should not be restricted by the particular mechanism used, even though you should be able to exert control over a particular mechanism if desired. A good example is communications. Should I have to protect MSG, WNG, MSGNOH, SMSG, COUPLE, NICDEF, IUCV, VMCF, ADRSPACE PERMIT, shared R/W DCSS, and shared mdisk separately? I don't like that. It's a never-ending quest to discover what new interfaces have been added, and it is a terribly large hammer to swing to enable mandatory access controls in your ESM. I much prefer to be able to protect an activity rather than a command or interface, but we are stuck with history for the nonce. Alan Altmark z/VM Development IBM Endicott
Re: Using LBYONLY
And if we do not discuss the way things should be vs. the way they are, there will never be any progress. We will always be mired in the past and become, dare I say it, dinosaurs. Even T-Rex was only around for about 3 million years - a very short time in geological terms (the Cretaceous Period, the one in which T-Rex lived, lasted about 80 million years). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, March 09, 2009 8:24 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY On Friday, 03/06/2009 at 03:31 EST, Bob Bolch b...@zenoroad.com wrote: It?s perfectly fine to discuss the way things ?should be? ?vs- the way things ?are?, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. I think that we must continually assess the somewhat, uh, arcane nature of VM commands. By default, I believe that the ability for UserX to bring UserY onto the system should not be restricted by the particular mechanism used, even though you should be able to exert control over a particular mechanism if desired. A good example is communications. Should I have to protect MSG, WNG, MSGNOH, SMSG, COUPLE, NICDEF, IUCV, VMCF, ADRSPACE PERMIT, shared R/W DCSS, and shared mdisk separately? I don't like that. It's a never-ending quest to discover what new interfaces have been added, and it is a terribly large hammer to swing to enable mandatory access controls in your ESM. I much prefer to be able to protect an activity rather than a command or interface, but we are stuck with history for the nonce. Alan Altmark z/VM Development IBM Endicott
Re: Using LBYONLY
Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order
Re: Using LBYONLY
Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid
Re: Using LBYONLY
You say, They don't and they shouldn't. That is where we have a philosophical difference. And no, I am not trying to tie them together; they are inextricably tied together by use of the same, not a similar or parallel, process. I realize that AUTOLOG is not LOGON followed by DISCONNECT; however the code used to create the virtual machine is the same except for the handling of the console. The difference is only a very small percentage of the code executed in creating the virtual machine. As you say, there is no LOGONBY command. The problem is that somebody chose arbitrarily to make LOGONBY one word while the real command is LOGON with a parameter of BY. You do not use a command LOGONBY, you really do enter a LOGON command. Therefore, ACCEPT userid LOGONBY should be treated as a peer of ACCEPT 1A0 LOGON and ACCEPT ipaddr LOGON. If only BY had never been affixed to LOGON, there never would have been any question and we would not be having this discussion.. Your argument is essentially saying that is how it is, so that is how it should be. I am saying that the implementation is not the standard by which it should be measured. Rather, it is the design. And, in this case, the design is, in my opinion, lacking and why I say that it is inconsistent. If LOGONBY were actually a separate command, I might be more inclined to agree with you. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Friday, March 06, 2009 10:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging
Re: Using LBYONLY
It's perfectly fine to discuss the way things should be -vs- the way things are, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. An obvious exception has to be made when the way it works now conflicts with some new behavior, that was unanticipated by the original design, but I don't think this is one of those cases. Bob Bolch
Re: Using LBYONLY
Richard, Yes, we have a philosophical difference. I'm not saying that the current design is right just because it's the current design. I'm saying the current design is right because it makes sense. External security managers don't evaluate virtual machine creation, they evaluate commands. AUTOLOG and LOGON are separate commands, and should be treated separately. I agree that LOGONBY rules are a special case, because there's no LOGONBY command. The problem with making LOGON and LOGONBY rules peers is that it complicates conflict resolution. More specific rules take precedence over general rules, but what do you do when the requestor is different for the two types of rules? The requestor for a LOGON rule is a terminal. The requestor for a LOGONBY or AUTOLOG rule is a userid (or member of an ACI group). Consider the following two rules: REJECT 1A0 LOGON ACCEPT RICHARD LOGONBY Both rules are as specific as they can be. One rejects logons from a single terminal. The other accepts logon by a single userid. What happens when someone enters LOGON BY RICHARD from terminal 1A0? Should it be accepted or not? Right now, the answer is clear. The LOGON rule is evaluated first. No one can log on from terminal 1A0. Checking the password or byuser is irrelevant. Under your proposal, the answer is ambiguous. While this simple example could be resolved in code, you can quickly get into a very confusing mess with ACI groups and ranges of terminals. If we treat AUTOLOG and LOGON rules the same, we also get into a wonderful grey area. Should we be able to allow AUTOLOG from a given userid, but not if it's entered on a certain terminal? Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 11:56 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY You say, They don't and they shouldn't. That is where we have a philosophical difference. And no, I am not trying to tie them together; they are inextricably tied together by use of the same, not a similar or parallel, process. I realize that AUTOLOG is not LOGON followed by DISCONNECT; however the code used to create the virtual machine is the same except for the handling of the console. The difference is only a very small percentage of the code executed in creating the virtual machine. As you say, there is no LOGONBY command. The problem is that somebody chose arbitrarily to make LOGONBY one word while the real command is LOGON with a parameter of BY. You do not use a command LOGONBY, you really do enter a LOGON command. Therefore, ACCEPT userid LOGONBY should be treated as a peer of ACCEPT 1A0 LOGON and ACCEPT ipaddr LOGON. If only BY had never been affixed to LOGON, there never would have been any question and we would not be having this discussion.. Your argument is essentially saying that is how it is, so that is how it should be. I am saying that the implementation is not the standard by which it should be measured. Rather, it is the design. And, in this case, the design is, in my opinion, lacking and why I say that it is inconsistent. If LOGONBY were actually a separate command, I might be more inclined to agree with you. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Friday, March 06, 2009 10:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON
Re: Using LBYONLY
Not if you add function. Let it work both ways. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bolch Sent: Friday, March 06, 2009 12:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY It's perfectly fine to discuss the way things should be -vs- the way things are, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. An obvious exception has to be made when the way it works now conflicts with some new behavior, that was unanticipated by the original design, but I don't think this is one of those cases. Bob Bolch
Re: Using LBYONLY
Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of preference, a rule is chosen that indicates: 1.A specific user ID as requester 2.A specific group as requester 3.An asterisk (*) as requester; this indicates all user IDs /quote So, when someone NOT mentioned in the specific ACCEPT rule tries to logonby, the REJECT * LOGON catches them. But if the user specified in the accept attempts it, the ACCEPT rule is more specific and will allow the logonby. In fact, the manual gives an example just like Richard's rules, except that it is dealing with LINK requests: REJECT * LINK 191 RR ACCEPT FRAISERC LINK 191 RR Shimon Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556 -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Using LBYONLY
It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of preference, a rule is chosen that indicates: 1.A specific user ID as requester 2.A specific group as requester 3.An asterisk (*) as requester; this indicates all user IDs /quote So, when someone NOT mentioned in the specific ACCEPT rule tries to logonby, the REJECT * LOGON catches them. But if the user specified in the accept attempts it, the ACCEPT rule is more specific and will allow the logonby. In fact, the manual gives an example just like Richard's rules, except that it is dealing with LINK requests: REJECT * LINK 191 RR ACCEPT FRAISERC LINK 191 RR Shimon Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556 -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax
Re: Using LBYONLY
There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of preference, a rule is chosen that indicates: 1.A specific user ID as requester 2.A specific group as requester 3.An asterisk (*) as requester; this indicates all user IDs /quote So, when someone NOT mentioned in the specific ACCEPT rule tries to logonby, the REJECT * LOGON catches them. But if the user specified in the accept attempts it, the ACCEPT rule is more specific and will allow the logonby. In fact, the manual gives an example just like Richard's rules, except that it is dealing with LINK requests: REJECT * LINK 191 RR ACCEPT FRAISERC LINK 191 RR Shimon Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids
Re: Using LBYONLY
I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of preference, a rule is chosen that indicates: 1.A specific user ID as requester 2.A specific group as requester 3.An asterisk (*) as requester; this indicates all user IDs /quote So, when someone NOT mentioned in the specific ACCEPT rule tries to logonby, the REJECT * LOGON catches them. But if the user specified in the accept attempts it, the ACCEPT rule is more specific and will allow the logonby. In fact, the manual gives an example just like Richard's rules, except that it is dealing with LINK requests: REJECT * LINK 191 RR ACCEPT FRAISERC LINK 191 RR Shimon Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556 -- Shimon Lebowitz mailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Using LBYONLY
Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of preference, a rule is chosen that indicates: 1.A specific user ID as requester 2.A specific group as requester 3.An asterisk (*) as requester; this indicates all user IDs /quote So, when someone NOT mentioned in the specific ACCEPT rule tries to logonby, the REJECT * LOGON catches them. But if the user specified in the accept attempts it, the ACCEPT rule is more specific and will allow the logonby. In fact, the manual gives an example just like Richard's rules, except that it is dealing with LINK requests: REJECT * LINK 191 RR ACCEPT FRAISERC LINK 191 RR Shimon Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556 -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Using LBYONLY
LOGONBY or LBYONLY as special passwords as is NOLOG. If you use LOGONBY or LBYONLY as the password and have LOGONBY statement specifying userx then you can logon as follows: LOGON OSASF By userx And when prompted you must supply userx's password. Hans -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: March 3, 2009 6:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Using LBYONLY Can some tell me if LBYONLY can be used as a password, with an appropriate LOGONBY statement for OSASF, OSAMAINT, OSADMIN1, OSADMIN2, and OSADMIN3 *and* the GUI interface? Thanks in Advance, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Using LBYONLY
And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY With the LBYONLY method, you are more restricted in the number of users who can have LOGONBY privileges, but, considering the ids you listed, that is unlikely to be a consideration. If someone else has the ability to reset passwords for users, you need to take steps to guard the LBYONLY passwords of the machines of interest. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Hans Rempel Sent: Tuesday, March 03, 2009 3:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY LOGONBY or LBYONLY as special passwords as is NOLOG. If you use LOGONBY or LBYONLY as the password and have LOGONBY statement specifying userx then you can logon as follows: LOGON OSASF By userx And when prompted you must supply userx's password. Hans -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: March 3, 2009 6:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Using LBYONLY Can some tell me if LBYONLY can be used as a password, with an appropriate LOGONBY statement for OSASF, OSAMAINT, OSADMIN1, OSADMIN2, and OSADMIN3 *and* the GUI interface? Thanks in Advance, Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Using LBYONLY
Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556
Re: Using LBYONLY
We use vmsecure password someuser (byonly It puts a special comment in the directory. Appropriate LOGONBY rules are then created. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Tuesday, March 03, 2009 6:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Richard Schuh wrote: And with VM:Secure, you can accomplish the same effect by using the Rules Facility. With the following rules, the actual password is immaterial: REJECT * LOGON ACCEPT userx LOGONBY That doesn't work. The REJECT * LOGON rule takes precedence, and you don't even get a chance to enter your password for LOGONBY. Set the password to LBYONLY and create ACCEPT xxx LOGONBY rules for the userids you want to log on. That's all you need. If you don't have VM:Secure or another external security manager, then set the password to LBYONLY and add LOGONBY statements to the directory. Dennis O'Brien 39,556
