Article

More Network Security: Equivalency

Chris Hare

As a follow-on to Laurie Sefton's article in Sys Admin (Jan/Feb 93), I want to discuss an often overlooked area of network security: equivalency, also known as trusted access.

Types of Equivalency

TCP/IP environments allow for two types of equivalency: host and user. Host equivalency, or trusted host access, can be configured by the system administrator. This type of equivalency permits all of the users on the specified system to access the local system without using a password. Host equivalency is controlled through the file /etc/hosts.equiv.

User equivalency, or trusted user access, is controlled by the user. It allows that user, as well as any others specified, to access that account without using a password. This type of access is managed through the user of the file $HOME/.rhosts.

Equivalence is most useful in environments where the BSD r commands - rlogin, rcmd(rsh), and rcp - are supported.

Network Fundamentals

Organizations often start out with one or two computers, then add more, and suddenly there's a network. Unless the expansion path is carefully planned, security can be compromised inadvertently.

For example, my login name at one time was simply "chris". In one of our company's other offices, through poor planning, their was another user with a login name of "chris". The two offices were not connected using TCP/IP; however, when a SLIP line was introduced between the two offices, suddenly there were problems, the most obvious one being that each of us with the login "chris" could access files belonging to the other.

While changing the login name for one user solved the immediate problem, it did not address the real security issue, which was that each of the users should have had an account for each machine on the network, each with the same UID.

As a first step toward providing equivalency, keep in mind the following points when setting up your network:

you are essentially duplicating the /etc/passwd and /etc/group files on all of the machines in your organization. As a result, each user must have a unique login name and UID.

group permissions cross system boundaries, so the same guidelines apply for groups. The same groups with the same group IDs (GID) must exist on all machines.

Configuring Host Equivalency

The system administrator configures host equivalency, or trusted host access, using the file /etc/hosts.equiv, as shown in Figure 1. This file consists of host names, one per line (it is also a good idea to document in the file who the network administrator is).

Each entry in the hosts.equiv file is trusted. This means that, with the exception of root, users on the named machine can access their equivalent accounts on this machine without a password.

In the configuration shown in Figure 2, the two machines oreo and wabbit both have a user named chare. If I am currently logged into wabbit, and issue the command

rlogin oreo

with host equivalency established, then I can log into oreo without being asked for my password. If host equivalency is not established, then I will be asked for my password on the remote machine.

There are two things to bear in mind concerning entries to /etc/hosts.equiv:

all the users on the remote machine are trusted, with one exception

root is never trusted.

There is a second format for the hosts.equiv file, as shown in Figure 3. This format lists a system name and a username. With the addition of the username, the user can login under any username listed in /etc/passwd.

For example, consider the following entry on a machine named ovide

wabbit chare

This entry states that when coming in from the system wabbit, user chare can login under any valid account name from /etc/passwd - as, for example,

rlogin ovide -l andrewg

This means that user chare on wabbit is being equivalenced to the user andrewg on ovide. This is user equivalency, which is more typically configured using the methods described below.

To use the commands rcmd(rsh) and rcp, host equivalency must be set up and operational.

User Equivalency

User equivalency makes a particular user known to all of the machines in the network. It should be considered absolutely necessary for environments where NFS is being used or planned. (It has the further benefit of making the network administrator's job easier in the long run.)

To configure user equivalence, the user creates a file in his/her home directory called .rhosts. This file must be writeable only by the owner of the file. If it is not, the file will be ignored for validation purposes.

As with the hosts.equiv file, this file contains a system name per line. It generally also includes the name of the user who is being equivalenced.

As an example: in my company's network, two people are responsible for the maintenance and operation of news. In order to allow those people access to our news server, a .rhosts file is established in the news home directory, /usr/lib/news.

The .rhosts file looks like

wabbit	chare
ovide	andrewg

Both of these people can log in as news on the news server without using a password, as they are "equivalent" to the user news on that machine.

The potential for serious problems exist in networks where there is host equivalency, but not user equivalency. In fact, the security of any network without user equivalency is highly jeopardized. In the configuration shown in Figure 4, for example, two users with same login ID, Chris M. and Chris S., work on two different machines, but both have the same login ID. Chris S. can do an rlogin from wabbit to oreo without providing a password. He can therefore access all of Chris M.'s files. The problem here is that though there is host equivalence, there is no user equivalence.

How Does Equivalency Work?

Both local host and the remote host play a role in determining equivalency.

When a user runs an r command:

The local host

attempts to validate the hostname. If the hostname is not in /etc/hosts and cannot be resolved using the Domain Name Server, then the command is aborted, and the user is informed that the hostname is invalid.

if the hostname is validated, connects via TCP/IP to the remote host.

The remote host

looks up the requested account name in /etc/passwd. If the account name is not there, it aborts the command.

checks to see if the account has an encrypted password. If there is no password, then the command is executed.

checks to see if the user is root. If the user is root, checks /.rhosts for the local host's name. If it is there, then the command is executed. (This is an example of user equivalency.) If the user is not root, then checks /etc/hosts.equiv checked for the local hosts's name. If it is found, then the command is executed. If no match is found, looks for an .rhosts file in the user's $HOME directory. If .rhosts doesn't exist or there is no match, rcp and rcmd(rsh) commands will fail, and rlogin will prompt for a password.

Security Issues with Equivalence

The potential for security breaches is significant in organizations that make extensive use of root equivalency. If someone discovers the root password on one machine, he or she will then have access as root to all of the machines in the network.

The several offices of my company share a high volume of information, but as we are only using a 19.2 kilobaud PPP link, NFS usage is not practical.

To avoid using root equivalence, we send some of the information via rdist. On the machines involved in these transactions, we created a special user with write access to the files into the appropriate directories.

Remember, too, that having host equivalency but no user equivalency can also be dangerous, in that a host from outside your network with the same username as one of your users would be able to access your system almost unrestricted.

For further information on host and user equivalency, see your system documentation and the book TCP/IP Network Administration by Craig Hunt (Sebastopol, CA: O'Reilly and Associates, 1992).

About the Author

Chris Hare is Ottawa Technical Services Manager for Choreo Systems, Inc. He has worked in the UNIX environment since 1986 and in 1988 became one of the first SCO authorized instructors in Canada. He teaches UNIX introductory, system administration, and programming classes. His current focus is on networking, Perl, and X. Chris can be reached at chare@choreo.ca, or chare@unilabs.org, which is his home.