Managing NFS and NIS, 2nd Edition - Mike Eisler [139]
Trusted hosts and trusted users
Defining a trusted host requires two machines: one that will be trusted and one that is extending the trust to it. The local host lh trusts remote host rh if users can log into lh from rh without supplying their passwords. Similarly, a user is trusted if he or she can log into a host from some remote machine without supplying a password. Trust is defined only for the local host; users and machines may be trusted on some systems but not on others.
The relationships between hosts often define the realm of trusted users and trusted hosts. Two NIS or NFS clients, for example, may trust all users and all other client hosts. On the NFS server, only other servers may be trusted hosts and only the system administration staff may be trusted users.
* * *
Warning
The following trusted user and trusted host descriptions apply in an environment in which you do not have to be wary of users or outsiders who will attempt to compromise security. These are basic security measures that fit in with the other network management strategies discussed in this book. If you need to secure your systems against all attacks, then you must consider the effects of having security compromised on any machine in your network. Again, these extensive security mechanisms are discussed in Practical Unix Security.
* * *
Some of the common patterns of trusting hosts and users are:
Server-Server
Generally, servers trust each other. A few users can be trusted in server-to-server relationships if each server has a password file that contains a subset of the NIS password map, or a password file with no NIS references. To emphasize the previous warning, extending trust between servers means that if one server is compromised, then they all are.
Server-Client
Most clients should trust the servers and users on the servers. A system administrator may need to run performance monitoring daemons on the client from the server and require transparent access to the client. Similarly, the server may be used to distribute files to the clients on a regular basis.
Client-Server
This is probably the most restrictive relationship. Only users with a need to use a service are generally given transparent access to the servers. Remote access to the server for access to a server's printer can be controlled via the -u option to the lpadmin command, instead of by trusting client machines on the server.
Client-Client
Client-client relationships depend upon how you have centralized your disk resources. If all files live on one or more fileservers, then client-to-client relationships are generally relaxed. However, if you are using the clients as isolated systems, with some per-client storage containing private data, then client-client relationships look more like those between clients and servers. The scope of the client-client relationships depends upon the sensitivity of the data on the clients: if you don't want other users to see the private data, then you must treat the client machine like a server.
The /etc/hosts.equiv and .rhosts files (in each user's home directory) define the set of trusted hosts, users, and user-host pairs for each system. Again, trust and transparent access are granted by the machine being accessed remotely, so these configuration files vary from host to host. The .rhosts file is maintained by each user and specifies a list of hosts or user-host pairs that are also parsed for determining if a host or user is trusted.
Enabling transparent access
Both rlogin and rsh use the ruserok( ) library routine to bypass the normal login and password security mechanism. The ruserok( ) routine is invoked on the server side