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 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 Lebowitz                mailto:shim...@iname.com

                VM System Programmer           .

                Israel Police National HQ.     

                Jerusalem, Israel              phone: +972 2 542-9877
fax: 542-9308

        
************************************************************************

                 

Reply via email to