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:[email protected]] On Behalf Of O'Brien, Dennis L
Sent: Friday, March 06, 2009 10:31 AM
To: [email protected]
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:[email protected]] On Behalf Of Schuh, Richard
Sent: Friday, March 06, 2009 09:47
To: [email protected]
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:[email protected]] On Behalf Of O'Brien, Dennis L
Sent: Thursday, March 05, 2009 4:32 PM
To: [email protected]
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:[email protected]] On Behalf Of Schuh, Richard
Sent: Thursday, March 05, 2009 14:47
To: [email protected]
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:[email protected]] On Behalf Of Demeritt, Yvonne
Sent: Thursday, March 05, 2009 11:29 AM
To: [email protected]
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
[email protected]
From: The IBM z/VM Operating System
[mailto:[email protected]] On Behalf Of O'Brien, Dennis L
Sent: Wednesday, March 04, 2009 1:25 PM
To: [email protected]
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:[email protected]] On Behalf Of Shimon Lebowitz
Sent: Wednesday, March 04, 2009 02:14
To: [email protected]
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:[email protected]
VM System Programmer .
Israel Police National HQ.
Jerusalem, Israel phone: +972 2
542-9877 fax: 542-9308
************************************************************************
