12.3. Password and NIS securitySeveral volumes could be written about password aging, password guessing programs, and the usual poor choices made for passwords. Again, this book won't describe a complete password security strategy, but here are some common-sense guidelines for password security:
12.3.1. Managing the root password with NISNIS can be used to solve a common dilemma at sites with advanced, semi-trusted users. Many companies allow users of desktop machines to have the root password on their local hosts to install software, make small modifications, and power down/boot the system without the presence of a system administrator. With a different, user-specific root password on every system, the job of the system administrator quickly becomes a nightmare. Similarly, using the same root password on all systems defeats the purpose of having one. Root privileges on servers should be guarded much more carefully, since too many hands touching host configurations inevitably creates untraceable problems. It is important to stress to semi-trusted users that their lack of root privileges on servers does not reflect a lack of expertise or trust, but merely a desire to exert full control over those machines for which you have full and total responsibility. Any change to a server that impacts the entire network becomes your immediate problem, so you should have jurisdiction over those hosts. One way to discourage would-be part-time superusers is to require anyone with a server root password to carry the 24-hour emergency beeper at least part of each month. Some approach is required that allows users to gain superuser access to their own hosts, but not to servers. At the same time, the system administrator must be able to become root on any system at any time to perform day-to-day maintenance. To solve the second problem, a common superuser password can be managed by NIS. Add an entry to the NIS password maps that has a UID of 0, but login name that is something other than root. For example, you might use a login name of netroot. Make sure the /etc/nsswitch.conf file on each host lists nis on the passwd: entry:
Users are granted access to their own host via the root entry in the /etc/passwd file. Instead of creating an additional root user, some sites use a modified version of su that consults a "personal" password file. The additional password file has one entry for each user that is allowed to become root, and each user has a unique root password. With either system, users are able to manage their own systems but will not know the root passwords on any other hosts. The NIS-managed netroot password ensures that the system administration staff can still gain superuser access to every host.passwd: files nis
12.3.2. Making NIS more secureAside from the caveats about trivial passwords, there are a few precautions that can be taken to make NIS more secure:
WARNING: There is no mechanism for removing the PROM security without supplying the PROM password. If you forget the PROM password after installing it, there is no software method for recovery, and you'll have to rely on Sun's customer service organization to recover!
188.8.131.52. The secure nets fileIf the file /var/yp/securenets is present, then ypserv and ypxfrd will respond only to requests from hosts listed in the file. Hosts can be listed individually by IP address or by a combination of network mask and network. Consult your system's manual pages for details. The point of this feature is to keep your NIS domain secure from access outside the domain. The more information an attacker knows about your domain, the more effective he or she can be at engineering an attack. The securenets file makes it harder to gather information. Because ypserv and ypxfrd only read the securenets file at startup time, in order for changes to take effect, you must restart NIS services via:
# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart
12.3.3. Unknown password entriesIf a user's UID changes while he or she is logged in, many utilities break in esoteric ways. Simple editing mistakes, such as deleting a digit in the UID field of the password file and then distributing the "broken" map file, are the most common source of this problem. Another error that causes a UID mismatch is the replacement of an NIS password file entry with a local password file entry where the two UIDs are not identical. The next time the password file is searched by UID, the user's password file entry will not be found if it no longer contains the correct UID. Similarly, a search by username may turn up a UID that is different than the real or effective user ID of the process performing the search. The whoami command replies with "no login associated with uid" if the effective UID of its process cannot be found in the password file. Other utilities that check the validity of UIDs are rcp, rlogin, and rsh, all of which generate "can not find password entry for user id" messages if the user's UID cannot be found in the password map. These messages appear on the terminal or window in which the command was typed.
Copyright © 2002 O'Reilly & Associates. All rights reserved.