LEICHTER-JERRY@YALE.ARPA (11/18/86)
[It appears that my wording in a recent info-vax message was open to misin-
terpretation; I doubt Greg was the only one to read it this way. I hope he
doesn't object to my making this reply, and excerpts from this note to me,
public.]
Your recent reply on info-vax implies that DECnet access controls are
useless unless all machines on the network are secured such that hostile
users don't have privileges. Is that true? Does a SYSPRV user on an
unknown machine really have the ability to NCP TELL a restricted machine,
or a machine with knowledge of the passwords of restricted machines, and
list the access control information?
No. When I talked about a user with SYSPRV being allowed in "despite such
access restrictions", the antecedent of "such" was intended to be a particular
kind of access restriction mentioned in the previous sentence: That control-
led by the NCP SET EXEC/NODE nnn ACCESS command. These commands allow you to
make an entire node accessible or not, incoming or outgoing. This is a very
non-specific form of access control, and as far as I know is not in very
wide-spread use. It, and no other form of access control that I know of, is
over-ridden by privileges on the remote machine. (Well, that's not quite true
- I think a privileged remote user can start a link to a machine whose EXEC is
set to state SHUT, which normally prevents any new links from being formed.
But I'm not absolutely certain of this.)
I thought that any machine that
wanted to use access controls in an open network should also apply an
access control to NML, thereby making it impossible for Joe Random SYSPRV
to list the privileged information from a remote machine.
NML is (a) the Network Management Listener protocol; (b) a network object that
speaks this protocol; (c) a program that implements this object. I'm not sure
which of these you mean, or what kind of access controls you would apply.
Normally, the remote NML runs non-privileged in the default DECnet account.
It can read most information in the database - passwords definitely excepted -
and it can't change anything. (Changing stuff in the permanent database
requires the ability to write to the files that store it - normally, SYSPRV
will do. Reading the passwords requires BYPASS. Changing the temporary
database requires something like SYSPRV, I'm not sure exactly what.) The only
way NML would be able to do this sort of stuff for you remotely is if it ran
in an appropriately privileged account, either via a proxy - not a good idea!
- or by the remote user providing explicit access control information - by
using a node specification of the form NODE"privileged-username password"::.
I haven't tried this myself, but if I'm right, you may want to update your
comments about the ability to violate security with remote SYSPRV
accounts. To reiterate, what I'm suggesting is this (and I haven't
checked to be sure): If you want to secure a machine, give it a password
for non-privileged connects.
Now you are talking about something else again: Password protection that
controls which machines can talk to each other over a given line. This is a
low-level control mechanism, and has no effect on messages routed through a
host once it is connected.
Distribute that password to all machines
that need to access the restricted machine. Then, for all machines that
have the password, including the restricted machine, secure their
privileged network control functions by putting a password on their NML
object (since that object could be used to read or set the non-privileged
password of the restricted machines). With this scheme, you need
cooperation from the system managers only of the machines that will have
access to the restricted machine.
I'm really unclear about what problem you claim to be solving here.
Now, what to do about node name aliases in the network?? GW
Yet another issue, almost in a class with protection against wiretappers.
Access control on DECnet is a complex subject. There's a lot of history
there, and all the old mechanisms co-exist with newer, generally better
mechanisms. The "Guide to Networking on VMS" contains about 12 pages of
general discussion of this issue, outlining the several layers and types of
such controls - plus, of course, detailed documentation of the NCP commands
that implement all these controls. There is additional information in the
"Guide to VAX/VMS System Security", including but not limited to a whole
chapter of some 27 pages on "Security for a DECnet Node". The general
security philosophy is that nodes are isolated security domains, and privilege
on one node does NOT, but default, imply any special privileges on another
(except in a couple of very limited special cases).
Given all the readily-available information, I strongly advise anyone really
concerned about this issue to do a little reading first. You are not likely
to get more than an overview from anything on this list.
-- Jerry
-------