NIS+ Security

Andy Papp

With the growing size of today's networks and the publicity that the Internet has been receiving, administrators not only need tools to quickly and easily administer their networks, they need tools which will assist in the security of their networks. The new security features offered in Sunsoft's Network Information Service Plus (NIS+) provide a system administrator with the ability to protect information about their namespace from unauthorized access. Any tool which provides both ease of administration and security is extremely valuable, especially if it is bundled with the operating system. To my knowledge, there are no other operating systems that come bundled with a naming service with this level of security. In this article I discuss how information within a network is protected from unauthorized access as well as the steps and tools administrators can use to secure their data.

NIS+ Security Features

Several new security features were introduced with NIS+. One of the new features is the NIS+ server daemon, rpc.nisd, which can be configured to run at three different levels of security. At the highest level, DES encryption is used to create keys which authenticate clients within a domain. Additional features include UNIX-style owner, group and file type permissions on all tables. Yet another useful feature is that clients no longer broadcast for their servers at boot time. All server information is read from a startup file, NIS_COLD_START, at boot time. All modifications to the namespace are logged to a file, /var/nis/<hostname>.log, so that an administrator can track all changes.

What Is NIS+?

Any administrator who has used the Network Information Service (NIS) under Solaris 1.x will be familiar with the basics of NIS+. NIS+ and NIS are both name services that help you distribute or propagate information throughout your defined namespace. The similarities between the two services end with that basic service. There are sixteen preconfigured tables within NIS+ (see Table 1) and you can create custom tables as well. Instead of having to update a system file on each host within your network, NIS+ allows you to update a file and propagate that change throughout the entire namespace from any single system. The change is seen almost instantly on all systems.

Principals and Objects

Before I begin discussing the mechanics of security within NIS+, it will help to define the terms used within the name service. Everything within NIS+ consists of two things, principals and objects. A principal is an entity within the namespace which requests information. A principal can be either a user or a workstation where both are known as clients, with the latter usually being the root user on the workstation. Objects are structures which contain information pertaining to an entity within the namespace. Objects within NIS+ include directories, tables, entries, and groups. A user, who is a principal, requests information contained within a table, which is an object. Whether or not the principal will receive the information is the basis of security within NIS+.

Credentials and the Conversation Key

When the NIS+ service is running at the default security level, all requests for information must be authenticated in order for the request to be processed. Each request for information must be accompanied by the principal's credentials in order for the request to be authenticated. When a principal is added to the namespace, credentials are created for that principal by means of the nisaddcred command. The nisaddcred command creates two 192-bit mathematically related keys. One key is a public key which gets stored in the cred table; the other is a private key which gets registered to the keyserv daemon upon login. The keys are generated using the Diffie-Hellman cryptography scheme. Public keys are known by all principals, while private keys are known only to the specific principal.

Credentials are part of what is known as the conversation key. The conversation key accompanies each request and is created on the client side by the keyserv daemon. The conversation key contains a secure remote procedure call (RPC) netname, a common DES-encrypted key, and an encrypted timestamp and time window. The client obtains the secure RPC netname, in the format of <unix.UID@domainname>, from the cred table within NIS+. The common key is generated by using the client's private key and the server's public key obtained from the NIS_COLD_START file. A DES-encrypted timestamp and time window are combined with the common key and netname and sent forward to the server. The server, knowing its own private key and the principal's public key, uses these to decrypt the conversation key from the client. If the keys are decrypted successfully, the principal is then authenticated. Unknown to the client, every request for information undergoes authentication.

Security Basics

NIS+ security can best be described by two terms, authentication and authorization. Authentication is the process of a principal establishing his or her credibility. Authentication is effected by a server examining the credentials passed by the client. Credentials are the means by which a principal is authenticated. Each request for information must be accompanied by the principal's credentials.

Once a principal is authenticated, what is the principal authorized to see? There are four classes of principals within NIS+: owner, group, world, and nobody. The first three classes are similar to UNIX owner, group, and world permissions for files and directories. Each of the four classes provides four access rights to the objects/tables: read, modify, create, and destroy. Table 2 shows the default permissions for the tables within a domain. It should be noted that the permissions for nobody are listed first, then owner, group, and world. A server examines the appropriate permissions of the object based on the request from the authenticated principal and returns the information if the principal is authorized.

A special case arises in unauthenticated requests. This is the case where the server was unable to identify the principal as a "known" client. The principal class of "nobody" is assigned to all unauthenticated requests and the server grants or denies the request based on the authorizations of the object for class nobody. Figure 1 illustrates the authentication and authorization process.

Levels of Security

The daemon which runs on all servers within the namespace, rpc.nisd, can be run at three levels of security. You specify the level by supplying the "-S <level>" option. Level 0 is the lowest level and provides no security. At this level any principal can obtain, change, or destroy information within the namespace. Level 1 security accepts both LOCAL and DES credentials. The principal must have LOCAL credentials in the cred table in order to be authenticated. Level 2, the highest and default level, uses DES credentials. Only requests which have valid DES credentials are authenticated. The rpc.nisd daemon is started from the /etc/init.d/rpc (/etc/rc2.d/S71rpc) script at run level 2. You can modify this file if you wish to run the rpc.nisd daemon at a level other than level two, but this is not recommended.

NIS+ Groups

NIS+ groups are very similar to UNIX-style groups. Each table can have an owner and group assigned. Information about a domain's groups is stored within the /var/nis/<server>/group_dir directory. Just as UNIX files have owner and group permissions, NIS+ tables have the same. However, groups in the /etc/group file or in the NIS+ group table are not the same as NIS+ groups. NIS+ groups must be created separately from the UNIX groups. With the addition of NIS+ groups, an administrator can selectively assign other administrators or users the ability to read, modify, create, or destroy entries within tables on the basis of group permissions. For example, a group, useradm, could be created and assigned to the passwd and group tables. Users added to the group would then automatically receive permission to modify those tables.

NIS+ Commands

All of the commands within NIS+ are prefaced with "nis". Some of the more basic commands with which UNIX administrators will be familiar are niscat, nischgrp, nischmod, nischown, nisls, and nispasswd. All of the above commands operate like their UNIX counterparts, except that the operation is performed on an NIS+ object. Just as chown, chgrp, and chmod can be used to tighten security on UNIX files and directories, so can nischown, nischmod, and nischgrp on NIS+ objects.

Two specific administrative commands are nistbladm and nisgrpadm. As their names suggest the first deals with table administration while the second deals with group administration. Nistbladm allows an administrator the ability to create (-c), delete (-d), and modify (-m) tables and entries. Nisgrpadm provides the ability to create (-c) and delete (-d) groups as well as add (-a) and remove (-r) principals to specific groups.

The command which deals specifically with credentials is nisaddcred. When you use the nisserver script to set up servers, nisaddcred is run automatically to add credentials for all known principals within the domain. Figure 2 shows the nisaddcred command. A principal's key gets registered when the principal logs into his/her account. The login program has been modified to automatically do a keylogin. If the principal's UNIX and network passwords are identical, the key will be registered. If the principal's UNIX and network passwords differ, the principal can manually use keylogin to register the key. If the principal's key is not registered, requests will not be authenticated. The command chkey can be used to synchronize the UNIX and network password. Nisaddcred can also be used to remove (-r) credentials for a specific principal.

A few other commands of interest are nisshowcache, nischttl, nislog, and nisdefaults. Nisshowcache shows the contents of a client's cache, while nisdefaults displays the default parameters for a principal. Nischttl allows an administrator to change the time to live values for NIS+ objects, while nislog command allows viewing of the transaction log.

Summary

NIS+ is a completely different application from NIS. If your environment doesn't require security for your network information, NIS+ might not be what you need. I suggest that you read more about the capabilities of NIS+ and plan carefully before proceeding with setting up a namespace. This article is not meant to suggest that using NIS+ will completely protect your system from unauthorized access. Rather, NIS+ is just one more tool to be used in securing your network.

About the Author

Andy Papp is a Senior Systems Analyst with Computer Science Corporation under contract at NASA Langley Research Center in Hampton, VA. Andy has a B.S. in Computer Science from Old Dominion University and is currently working on his Master's, also at Old Dominion. Andy has been working with UNIX for seven years and is a Sun Microsystems Education certified instructor in several administration courses. Andy can be reached electronically at r.a.papp@larc.nasa.gov.