Thank you to
Phil Poole <poole_at_ncifcrf.gov>
Michael Matthews <matthewm_at_sgate.com>
Christophe Colle <colle_at_krtkg1.rug.ac.be>
Steve VanDevender <stevev_at_hexadecimal.uoregon.edu>
Karl Marble <marblek_at_city.ci.worcester.ma.us>
Original Question:
>We have several hosts on campus. Are login names are unique across
>all systems. (Example: User Thomas Aquinas will have a login name
>of "aquintho." Thomas Aquinas, and only Thomas Aquinas, will use
>the login name "aquintho" to access all hosts to which he has
>access). Are UIDs are unique across all systems (User Thomas
>Aquinas with login name of "aquintho" will have a UID of 299.
>Thomas Aquinas, and only Thomas Aquinas, will have the UID of 299
>on all hosts to which he has access.)
>We are obtaining another Digital Unix host which will be running an
>application. Initially we are looking to support this application
>as a turnkey system. This turnkey system will not allow us to
>display or set the UID. We will not have access to the root
>password.
>What are security implications of no longer having unique UIDs in a
>networked environment? Please indicate which
>applications/protocols that could be affected (NFS, ftp, mail,
>etc).
>How does your site handle recycling UIDs for departed users? We
>have a high turn over of users in our student population.
Summarized Answer to Security Issues Regarding
Non-Aquinas Administered Resources Connected to Aquinas' Network:
If Aquinas, as network administrator, does not have administrative
access to a host in our domain, then not only is there no way to
predict the administrative problems it might cause, but there is no
way for us to establish or guarantee its security or to prevent it
from being used to undermine the security of other hosts at our
site. Slight lapses in security can compromise entire hosts and
networks. The network is only as secure as its weakest host.
Administratively, we will not be monitoring the host. We will not
be aware of or in control of the normal operating procedures such as
backup/recover procedures. We will not be able to be proactive in
troubleshooting problems such as resource management. We will only
be able to be involved in a limited fashion in reactive
troubleshooting.
Aquinas has developed a security policy which balances access to and
protection of Aquinas' information resources. Aquinas' security
policy is a dynamic document. Changes are made to reflect industry
standards, identified security problems, and changes in the
technology needs of Aquinas College. We have configured the Unix
hosts over which we have administrative control and have implemented
procedures on the Unix hosts to comply with existing Aquinas security
policies. We have no way of implementing and enforcing our security
policy on hosts connected to our network over which we have no
administrative control. As our security policies change we have no
way of implementing the changes on these hosts.
The login name and UID issues are one aspect of Aquinas' security
policy. Here specifically is the concern regarding login names and
uids.
Login Name:
If you have more than one machine, login names should be unique in
two senses. First, a user should have the same login on every
machine. This is mostly for convenience, both for the administrator
and the user. Second, a particular login name should always refer to
the same person. Large security holes are created if the same name
refers to two different users in a network environment. For example,
if smithter_at_host1.aquinas.edu was Teresa Smith and
smithter_at_host2.aquinas.edu was Terry Smith, then either smithter
could access the other's files under certain circumstances.
UID number:
Once you login to a Unix host, the host no longer identifies you by
your username but by your UID. The text names that correspond to
UIDs (User ID Numbers) and GIDs (Group ID Numbers) are defined only
for the convenience of the hosts's human users. When commands such
as ls want to display ownership information in a human-readable
format, they have to look up each name in the appropriate file.
The UID is the user identification number of the person who created
the process or file. The creator of a process can make changes to a
process (kill, stop, nice, priority). The owner of a file specifies
which operations the group owners may perform on it.
In a networked environment, UIDs must be unique across the entire
network. That is, a particular UID must refer to the same login
name and the same person throughout the network. We avoid recycling
UIDs, even those of users who have left our organization and have had
their accounts removed. This precaution avoids confusion if files
are later restored from backups, where users are identified by UID
rather than by login name. (We have not had to recycle UIDs. The
upper limit rises with Digital Unix 4.x.)
NFS (Network File System), FTP (File Transfer Protocol), and all the
r-commands (rsh, rcp, etc.) are examples of protocols and
applications which use the UID across hosts to determine access to
network resources.
For example, if user aquintho has UID 299 on all Aquinas hosts
except one (turnkey), then any files shared among those hosts
will show up with an ownership of aquintho.
Say user jonesjan has UID of 299 on host turnkey. If any disks
are mounted from other hosts, then user aquintho's files will not
be aquintho's on the turnkey host, they will be owned by user
jonesjan. This is because user jonesjan has UID of 299.
Therefore, if user aquintho has restricted or private files that
get mounted on the host turnkey, then user jonesjan could,
potentially, have full access to those files. User jonesjan
could write, delete, and change permissions of those files, since
user jonesjan, to the other hosts, would own them.
This is potentially bad if a HOME directory containing a .rhosts
file is shared in this manner.
User jonesjan could modify the .rhosts file to something similar
to the following:
turnkey.aquinas.edu jonesjan
This would allow user jonesjan to rlogin/rsh to all hosts that
mount user aquintho's home directory without specifying a
password. At that time, user jonesjan would appear as user
aquintho to those hosts.
This is potentially a big security risk to all hosts on the same
network, in this case the external network.
------------------------------
Laura Grabinski, Network Administrator
Aquinas College, 1607 Robinson RD SE, Grand Rapids MI 49506 USA
mailto:grabilau_at_aquinas.edu 616-459-8281,
http://www.aquinas.edu
Personal e-mail: mailto:laurag9909_at_aol.com
Received on Tue Apr 01 1997 - 17:02:56 NZST