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
************************************************************************
