Network Identifiers - Selectivity in Information Sharing
			by Glenn C. Everhart


	It has been well known for some time now that UIC based access
controls for file permissions are often too coarse grained to be adequate
on many systems. In particular, world access is generally too broad and
group access too narrow. (On unix systems, this has been addressed by
allowing one to belong to multiple groups, but such a solution imposes
considerable burdens on system administrators.) The VMS solution to this
has been to allow ACLs (Access Control Lists) which give a fine grained
method for control of who may access what. Within a system (or a cluster
in the case of VMS) this works well and permits sharing as desired. 
	Another useful VMS feature is that one can place ACLs or other
protections on a device. These function to control access at device
level. While such features are not widely used (the default being to
allow universal device access and control access at file level), they can
resemble mandatory security controls from the point of view of many
users. In other words, if either an ACL on a device or its' UIC
protection mask prevents access to the device, a process cannot access a
file on that device, even if file access is permitted by ACLs on the
files. Give an identifier FINANCIAL to a group of people, and put the
financial data you have on a disk with a device ACL that specifies no
access to anyone except those with the FINANCIAL identifier, and others
cannot access the data, even if someone with ownership rights to it wants
to try to leak it out by allowing others to grab it. Placing ACLs on
other disks preventing writing by someone with the identifier FINANCIAL
will also prevent leaks by someone with access trying to copy the
information to a non-controlled disk. (It also guards against trojan
horse programs trying to do this.) The availability of free virtual disk
drivers on the VAX SIG tapes makes it feasible to tailor volume control
in this way, as volumes need not be chosen from the (possibly small) pool
of physical devices, but can be simply virtual volumes within a system.
	(Note that privilege can be used to violate these constraints,
but its use can at least be audited in a VMS environment.)

	As can be seen, access controls within a system are fairly robust
and can be tailored for many needs.

	Over networks, the picture is far more primitive. If one has
default DECnet access enabled, to allow network file sharing, "world"
access really can mean the entire planetary population in worst case. One
has the ability to assign an identifier to the default DECnet account to
create two classes of "world" (everyone on one's cluster, and everyone on
DECnet). In a large DECnet, though, this is not much of an improvement. 

	As an aside, in the unix world one uses NFS, which also
propagates at most some UIC identifiers and has no ability to detect
spoofing of clients, to accomplish this sort of transparent file access.
In that space, the newer AFS (Andrew File System, being commercially
handled by Transarc Corp.  in Pittsburgh) gives marked improvement. In
AFS, one has network wide ACLs, secure authentication services, server
performance that scales well as the networks grow large (NFS scales very
poorly), and administration tools to allow the network ACLs and users to
be administered intelligently. Since AFS has recently been adopted by
OSF, to which DEC is a contributor, we may expect to hear more about it
in the future.

	In a large DECnet, it can be difficult or impossible to
coordinate ALL identifiers assigned, and even creating a uniform
population of person to numeric UIC codes rapidly becomes infeasible.
Proxy logins also are not useful for discriminating finely enough where
there are thousands of nodes in one's net; the system administrative
burden far exceeds what anyone can handle. Besides, the information
propagated during connects in DECnet carries no security parts. The most
efficient method of handling security would be for each DECnet connection
to be able to transmit security relevant information in some form as part
of the connection. Something like this may be available (for considerable
cost) from VMS SES. Many networks will however resist quite strongly the
suggestion they spend so heavily for this kind of function. It's easier
(though arguably incorrect) to say the benefits of information sharing
don't justify the cost, or that the good old "Sneakernet" should be used.

	In many company DECnets, there is benefit to allowing employees
to share data over the net as transparently as possible. However, some
data is proprietary and should not be available to non-employees (e.g.,
consultants who have temporary access to a net), while other data has
export sensitivity and therefore should not be routinely available to
non-citizens, though it may be permissible to allow consultants at it.
Some classes of employees (new hires, people about to retire, or
temporary people, for example) may also be considered candidates for
reduced trust, as might those identified as troublesome in a security
sense by site administrators. Other candidate classes exist, but for
information one wants to be able to share widely, these seem particularly
useful ones.

	The key to propagating identifiers is first to agree on a set to
be propagated. In the network propagators on the Spring '90 tapes, there
are four identifiers propagated, with the following meanings (the names
are NOT identical to these):

  1. Non-employee - this identifier refers to anyone with a valid account
		who is not known to be an employee. Note that shared
		accounts often will have this also.
  2. Non-citizen - This refers to a noncitizen.
  3. Short-timer - Anyone not a long-term employee (or long term
		consultant perhaps; someone working as a long term
		consultant might be reasonably deemed to have some
		interest in the stability of his employer).
  4. Twit - This is given to anyone who is seen to be a problem user for
		whatever reason by local folks. It can indicate general
		security laxness of some kind, security breaches that
		aren't serious enough to fire them for, gross
		inexperience that causes system problems a lot, or
		anything else.

	Notice that all these identifiers are chosen so their presence
can be used to reduce file access rights. The idea is also that these are
(hopefully) exceptional conditions. That is, most accounts will belong to
employees, citizens, and hopefully not many short-timers and even fewer
twits. Therefore for most accounts, these identifiers don't have to be
granted, and agreeing to grant them to appropriate users isn't a major
burden at each site.

	In actual use, there are two identifiers for each of the four
classes above. One is permanent and gets assigned in the UAF to the user;
the other is dynamic and gets assigned to the default DECnet (or default
FAL) account.  The reason is that a dynamic identifier can be turned off
or on by the SET RIGHTS/ENABLE or SET RIGHTS/DISABLE commands, requiring
no image activation.

	In implementing the propagators, one does two things in addition
to defining the identifiers mentioned above:

  1. Add a DECnet object which serves to propagate the identifiers from
	one machine to others querying it, and
  2. Modify the FAL (File Access Listener) object to run a modified
	FAL.COM command file to interact with this object at the remote
	machine.

	The FAL.COM as modified does not immediately run FAL.EXE as
happens in normal DECnet. Instead, it first attempts to send a message to
the new identifier propagator object on the remote DECnet (let's call it
NETIDENT) and in the message sends the remote username (or PID, depending
on which is available in the Network Connect Block locally) to NETIDENT.
On the originating sytem, NETIDENT reads the username or PID (and gets
the PID if it gets a username instead), and using the $GRANTID and
$REVOKID VMS system services finds out which identifiers are held and
active by the process that is trying to talk to FAL. It does this in
pairs, so that if EITHER the static or dynamic identifier is "turned on",
this is transmitted back. NETIDENT then sends back a string containing
letters NFST or XXXX in appropriate positions (Nonemployee, Foreign,
Shorttimer, Twit) depending on which identifiers it finds. XXXX would be
sent if the process is found to have none of the identifiers. The default
is to assume all of them, both in NETIDENT and in FAL.COM, so that they
are turned OFF ONLY where they are known to be absent. 

	Now the FAL.COM reads this string and sets or resets the dynamic
identifiers for each of the four classes, then closing the connection to
NETIDENT. It may also check the nodename and refuse to believe any
"missing identifiers" messages from some untrusted nodes, and for
performance reasons may also skip the extra DECnet connection for some
accounts, or make it only for a default account.

	Once the dynamic identifiers are set, the FAL.EXE image is run,
which completes the FAL connection and does file access. Since the
process now has identifiers on the local system corresponding to those on
the remote side, ACLs on the system addressed now can refine world access
so that (for example) files may be made available to employees, but not
others, with some assurance the constraints are meaningful.

	The setup of extra DECnet connections imposes performance
degradation for FAL access, obviously. For this reason, I recommend that
the setup in FAL.COM be that in essence there are two "default" accounts.
One of these, the standard default account, will set all identifiers and
skip calling NETIDENT. Thus it can access whatever is TRULY world
accessible data. Another account, which could be accessed by node"File
access"::  for instance (or some other widely broadcast username/password
combination set up for network access by the FAL object only), would be
detected by FAL.COM and in this account, NETIDENT would be used. Thus,
file sharing would be possible through this account where it normally
would be disabled altogether, and yet sharing of any data where no
security concerns existed would not be degraded significantly.  In some
cases proxy access could be set to direct default FAL access to one or
the other accounts automatically as well.

	Limitations:

	Because what is transmitted to a node does not always include a
process ID remotely, it is difficult to be certain which process of a
given username on the remote system one is accessing. Taking the penalty
of another image activation on the local system to find the link number
and then getting the remote PID by the link number within NETIDENT is
possible, but not fast. It would be desirable, though, because if someone
is using Poor Man's Routing and accessing a file (e.g. with
NODE1::NODE2::device:[directory]file.typ) then NODE2 sees it is being
accessed by FAL running on NODE1 in the default DECnet account there.  If
FAL.COM in NODE1 were talking to NETIDENT on the originating node, then
FAL.COM on NODE2 would be able to inherit the identifiers by getting
NETIDENT on NODE1 to propagate them. However, if NODE2 gets only the
username DECNET, then NETIDENT on NODE1 may find the wrong process
running in the DECnet account and fail to get the identifiers.
	For this reason, one should set the logical name FAL$LOG to
contain the string "/DISABLE=8" to disable this sort of file access.
Given this logical, the poor man's routing access of files cannot be done
(FAL.EXE rejects it). This is often done anyway to make file access
traceable better over a net.
	Finally, and most obviously, the network objects here are written
for VMS DECnet only (at the moment). A new NETREMOTID server would be
needed for, say, Ultrix DECnet, to get these services to work correctly
with that environment.

	Summary:

	The remote identifier propagators allow you to have ACLs on your
files allowing them to be shared by cooperating parts of your DECnet by
people with attributes you allow. It is designed to be easy to administer
and use, and to allow one to trust exactly the part of the network one is
willing to trust. The benefits are allowing information sharing as widely
as your trust allows, without major burdens on any site's system
management or excessive performance costs. Where you did not allow
default FAL access before, this may allow it, and where you did allow it,
you may now expand it. Complete sources are supplied to allow the tools
to be expanded or customized. Also, the binary values of identifiers are
totally decoupled between systems, so no conflicts can exist and no
central administration is needed. Parts of this may break under Phase V
DECnet, but the calls are chosen to be extremely vanilla DECnet, so the
likelihood of this happening is not great.

	Hopefully there will someday be tools to do these sorts of things
as DECnet built-ins. For the present, though, one can do them by tools
such as NETIDENT.

	The utilities will appear on the Spring 1990 VAX SIG tapes in
directory [.GCE90A.NET90A.IDENTNET].