You can restrict the importing of accounts to particular users by following the + symbol with a particular username. For example, to include only the user george from your NIS server, you could use the following entry in your /etc/passwd file:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh
+george::120:5:::

Note that we have included a UID and GID for george. You must include some UID and GID so that the function getpwuid ( ) will work properly. However, getpwuid ( ) actually goes to the NIS map and overrides the UID and GID values that you specify.^[188]

You can also exclude certain usernames from being imported by inserting a line that begins with a minus sign (-). When NIS is scanning the /etc/passwd file, it will stop when it finds the first line that matches. Therefore, if you wish to exclude a specific account but include others that are on the server, you must place the lines beginning with the - symbol before the lines beginning with the + symbol.

For example, to exclude zachary’s account and include the others from the server, you might use the following /etc/passwd file:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh
-zachary::2001:102:::
+::999:999:::

Note again that we have included zachary’s UID and GID.

NIS allows you to selectively import some fields from the /etc/passwd database but not others. For example, if you have the following entry in your /etc/passwd file:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh
+:*:999:999:::

then all of the entries in the NIS passwd map will be imported, but each will have its password entry changed to "*“, effectively preventing it from being used on the client machine.^[189]

Why might you want to do that? Well, by importing the entire map, you get all the UIDs and account names so that ls -l invocations show the owner of files and directories as usernames. The entry also allows the ~user notation in the various shells to correctly map to the user’s home directory (assuming that it is mounted using NFS). But it prevents the users in the map from actually logging onto the client system.

The /etc/yp/makedbm program (sometimes found in /usr/etc/yp/makedbm) processes the netgroup file into a number of database files that are stored in:

Note that /etc/yp may be symbolically linked to /var/yp on some machines.

If you have a small organization, you might simply create two netgroups: one for all of your users, and a second for all of your client machines. These groups will simplify the creation and administration of your system’s configuration files.

If you have a larger organization, you might create several groups. For example, you might create a group for each department’s users. You could then have a master group that consists of all of the subgroups. Of course, you could do the same for your computers as well.

Consider the following science department:

Math (mathserve,,) (math1,,) (math2,,) (math3,,)
Chemistry (chemserve1,,) (chemserve2,,) (chem1,,) (chem2,,) (chem3,,)
Biology (bioserve1,,) (bio1,,) (bio2,,) (bio3,,)
Science Math Chemistry Biology

Netgroups are important for security because you use them to limit which users or machines on the network can access information stored on your computer. You can use netgroups in NFS files to limit who has access to the partitions, and in datafiles such as /etc/passwd to limit which entries are imported into a system.

You can use the netgroups facility to control which accounts are imported by the /etc/passwd file. For example, if you want to simply import accounts for a specific netgroup, then follow the plus sign (+) with an at sign (@) and a netgroup:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh
+@operators::999:999:::

The above will bring in the NIS password map entry for the users listed in the operators group.

You can also exclude users or groups if you list the exclusions before you list the netgroups. For example:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh
-george::120:5:::
-@suspects::999:999:::
+::999:999:::

The above will include all NIS password map entries except for user george and any users in the suspects netgroup.

NIS has been the starting point for many successful penetrations into Unix networks. Because NIS controls user accounts, if you can convince an NIS server to broadcast that you have an account, you can use that fictitious account to break into a client on the network. NIS can also make confidential information, such as encrypted password entries, widely available.

There are design flaws in the code of the NIS implementations of several vendors that allow a user to reconfigure and spoof the NIS system. This spoofing can be done in two ways: by spoofing the underlying RPC system, and by spoofing NIS.

As we noted in Chapter 13, the NIS system depends on the functioning of the portmapper service. This is a daemon that matches supplied service names for RPC with IP port numbers at which those services can be contacted. Servers using RPC will register themselves with portmapper when they start and will remove themselves from the portmap database when they exit or reconfigure.

Early versions of portmapper allowed any program to register itself as an RPC server, allowing attackers to register their own NIS servers and respond to requests with their own password files. Sun’s current version of portmapper rejects requests to register or delete services if they come from a remote machine, or if they refer to a privileged port and come from a connection initiated from an unprivileged port.^[191] Thus, in Sun’s version, only the superuser can make requests that add or delete service mappings to privileged ports, and all requests can only be made locally. However, not every vendor’s version of the portmapper daemon performs these checks. The result is that an attacker might be able to replace critical RPC services with his own booby-trapped versions.

Note that NFS and some NIS services often register on unprivileged ports, even on Sun systems. In theory, even with the checks outlined above, an attacker could replace one of these services with a specially written program that would respond to system requests in a way that would compromise system security. This would require some in-depth understanding of the protocols and relationships of the programs, but these are well-documented and widely known.

NIS clients get information from an NIS server through RPC calls. A local daemon, ypbind, caches contact information for the appropriate NIS server daemon, ypserv. The ypserv daemon may be local or remote.

Under early SunOS versions of the NIS service (and possibly versions by some other vendors), it was possible to instantiate a program that acted like ypserv and responded to ypbind requests. The local ypbind daemon could then be instructed to use that program instead of the real ypserv daemon. As a result, an attacker could supply her own version of the password file, for example, to a login request! (The security implications of this should be obvious.)

Current NIS implementations of ypbind have a -secure command-line flag (sometimes present as simply -s) that can be provided when the daemon is started. If the flag is used, the ypbind daemon will not accept any information from a ypserv server that is not running on a privileged port. Thus, a user-supplied attempt to masquerade as the ypserv daemon will be ignored. A user can’t spoof ypserv unless that user already has superuser privileges. In practice, there is no good reason not to use the -secure flag.

Unfortunately, the -secure flag has a flaw. If the attacker is able to subvert the root account on a machine on the local network and start a version of ypserv using his own NIS information, he need only point the target ypbind daemon to that server. The compromised server would be running on a privileged port, so its responses would not be rejected. The ypbind process would therefore accept its information as valid, and security could be compromised.

An attacker could also write a “fake” ypserv that runs on a PC-based system. Privileged ports have no meaning on PCs, so the fake server could feed any information to the target ypbind process.

A combination of installation mistakes and changes in NIS itself has caused some confusion with respect to the NIS plus sign (+) in the /etc/passwd file.

If you use NIS, be very careful that the plus sign is in the /etc/passwd file of your clients and not your servers. On an NIS server, the plus sign can be interpreted as a username under some versions of the Unix operating system. The simplest way to avoid this problem is to make sure that you do not have the + account on your NIS server.

Attempting to figure out what to put on your client machine is another matter. With early versions of NIS, the following line was distributed:

+::0:0:::                      Correct on SunOS and Solaris

Unfortunately, this line presented a problem. When NIS was not running, the plus sign was sometimes taken as an account name, and anybody could log into the computer by typing + at the login: prompt—and without a password! Even worse, the person logged in with superuser privileges.^[192]

One way to minimize the danger was to include a password field for the plus user. One specified the plus sign line in the form:

+:*:0:0:::                  On NIS clients only

Unfortunately, under some versions of NIS this entry actually means “import the passwd map, but change all of the encrypted passwords to *“—which effectively prevents everybody from logging in. This entry isn’t right either!

The easiest way to see how your system behaves is to attempt to log into your NIS clients and servers using a + as a username. You may also wish to try logging in with the network cable unplugged to simulate what happens to your computer when the NIS server cannot be reached. In either case, you should not be able to log in by simply typing + as a username. This approach will tell you that your server is properly configured.

If you see the following example, you have no problem:

login: +
password: anything
Login incorrect

If you see the following example, you do have a problem:

login: +
Last login: Sat Aug 18 16:11 32 on ttya
#

If you are running a recent version of your operating system, do not think that your system is immune to the + confusion in the NIS subsystem. In particular, some NIS versions on Linux got this wrong too.