NIS+ Transition Guide

Chapter 3 Planning NIS+ Security Measures

This chapter provides general guidelines and recommendations for making choices about security in your namespace.

Understanding the Impact of NIS+ Security

Because NIS+ provides security that NIS did not, it requires more administrative work. It may also require more work from users who are not accustomed to performing chkey, keylogin, or keylogout procedures. Furthermore, the protection provided by NIS+ is not entirely secure. Given enough computing power and the right knowledge, the Diffie-Hellman public-key cryptography system can be broken.

Using Diffie-Hellman keys longer than 192 bits significantly increases NIS+ security. You might, however, experience a degradation in performance as the longer key length requires more time to authenticate.

Note -

Use nisauthconf to configure the type of Diffie-Hellman key. See nisauthconf(1M) for information about using longer keys.

In addition, the secret key stored with the key server process is not automatically removed when a credentialed nonroot user logs out unless that user logs out with keylogout(1). Security may be compromised even if the user logs out with keylogout(1) because the session keys may remain valid until they expire or are refreshed. (See keylogout(1) for more information.) Root's key, created by keylogin -r and stored in /etc/.rootkey, remains until the .rootkey file is explicitly removed. The superuser cannot use keylogout. Nevertheless, NIS+ is much more secure than NIS.

How NIS+ Security Affects Users

NIS+ security benefits users because it improves the reliability of the information they obtain from NIS+ and it protects their information from unauthorized access. However, NIS+ security requires users to learn about security and requires them to perform a few extra administrative steps.

Although NIS+ requires a network login, users are not required to perform an additional key login because the login command automatically gets the network keys for the client when the client has been correctly configured. Clients are correctly configured when their login password and their Secure RPC password are the same. The secret key for the user root is normally made available in the /etc/.rootkey file (with a possible security problem, as noted earlier). When the NIS+ user password and credential are changed with the passwd command, the credential information is automatically changed for the user.

To change the NIS+ machine's local root password, run the passwd command.

To change the root credential, run the chkey command.

However, if your site allows users to maintain passwords in their local /etc/passwd files in addition to their Secure RPC passwords, and if these passwords are different from the Secure RPC passwords, then users must run keylogin each time they run login. The reasons for this are explained in the Solaris Naming Administration Guide.

How NIS+ Security Affects Administrators

Because the Solaris operating environment includes the DES encryption mechanism for authentication, administrators who require secure operation do not need to purchase a separate encryption kit. However, administrators must train users how to use the passwd and the passwd -r commands, and when to use them.

Furthermore, setting up a secure NIS+ namespace is more complex than setting up a namespace without any security. The complexity comes not only from the extra steps required to set up the namespace, but from the job of creating and maintaining user and machine credentials for all NIS+ principals. Administrators have to remove obsolete credentials just as they remove inactive account information from the passwd and hosts tables. Also, when servers' public keys change, administrators have to update the keys throughout the namespace (using nisupdkeys). Administrators also have to add LOCAL credentials for users from other domains who want to remote login to this domain and have authenticated access to NIS+.

How NIS+ Security Affects Transition Planning

After you become familiar with the benefits and the administrative requirements of NIS+ security, you must decide whether to implement NIS+ security during or after the transition. It is recommended that you use full NIS+ security even if you operate some or all servers in a domain in NIS-compatibility mode. (All servers in a domain should have the same NIS-compatibility status.) However, this entails a heavy administrative burden. If you prefer a simpler approach, you could set up the NIS+ servers and namespace with NIS-compatible security, but decline to create credentials for NIS+ clients. Administrators and servers would still require credentials. The NIS+ clients would be relegated to the nobody class, along with the NIS clients. This reduces training and setup requirements, but it has the following drawbacks:

Users lose the ability to update any NIS+ tables, but they retain their ability to change their login password. (Solaris 2.5 and later only.)
Users are not able to verify that the name service information is coming from an authenticated NIS+ server.

Selecting Credentials

NIS+ provides two types of credential: LOCAL and DES.

Note -

In this manual, the term, DES credentials, applies to the extended 640-bit Diffie-Hellman keys as well as to the original 192-bit Diffie-Hellman (default) key length. In the cred table, the extended keys use designations such as DH640-0, rather than the DES keyword. See nisauthconf(1M) for information about using longer keys.

All NIS+ principals need at least one of these credentials. When the namespace is running at security level 2 (the default), all NIS+ principals (clients) must have DES credentials in their home domains. In addition, all users (not workstations) must have LOCAL credentials in their home domains and in every other domain for which they need login access.

To determine the credential needs of your namespace, consider the:

Type of principal
Type of credential

NIS+ principals can be users or the superuser identity on the client workstation. See Figure 3-1.

Figure 3-1 NIS+ Principals

When you determine the credentials you need to create, make sure you know which type of principal needs the credential. For instance, when you set up an NIS+ client with the nisclient script, you create credentials for both the workstation and for the user. Unless credentials for the user are also created, the user only has the access rights granted to the nobody class. This can work very well. But if you don't give any access rights to the nobody class, the namespace won't be available to users.

Choosing a Security Level

NIS+ is designed to be run at security level 2, which is the default. Security levels 0 and 1 are provided only for the purposes of testing and debugging. Do not run an operational network with real users at any level other than level 2. See Solaris Naming Administration Guide for more information on the NIS+ security levels.

Establishing Password-aging Criteria, Principles, and Rules

Password-aging is a mechanism that you can use to force users to periodically change their passwords. Password-aging allows you to:

Specify the maximum number of days that a password can be used before it has to be changed.

Specify the minimum number of days that a password has to be in existence before it can be changed.

Specify a warning message to be displayed whenever a user logs in a specified number of days before the user's password time limit is reached.

Specify the maximum number of days that an account can be inactive. If that number of days pass without the user logging in to the account, the user's password is locked.

Keep in mind that users who are already logged in when the various maximums or dates are reached are not affected by the above features. They can continue to work as normal. Password-aging limitations and activities are activated only when a user logs in or performs one of the following operations:

login
rlogin
telnet
ftp

These password-aging parameters are applied on a user-by-user basis; you can have different password-aging requirements for different users. You can also set general default password-aging parameters that apply to all users except those you have individually set.

When planning your NIS+ namespace, decide which password-aging features you want to implement, and the default values you want to specify. For additional information on password-aging, see the Password chapter of Solaris Naming Administration Guide.

Planning NIS+ Groups

NIS+ introduces a new type of group to name service administration, which NIS does not have. An NIS+ group is used only as a means to provide NIS+ access rights to several NIS+ principals at one time; it is used only for NIS+ authorization.

An NIS+ group is one of the four authorization classes on which access rights are based. The four classes are:

Owner. Every NIS+ object has one owner who is a single user. The owner is usually the person who created the object, but ownership can be transferred to another user.

Group. A collection of users grouped together under a group name for the purpose of granting that collection of users specified NIS+ access rights.

World. All authenticated users. In other words, any user with valid DES credentials. By definition, an object's owner and members of an object's group are also part of the world class so long as their credentials are valid.

Nobody. Anyone who does not have a valid DES credential. If the credentials of some member of one of the other classes are invalid or missing or corrupted or not found, then that user is placed in the nobody class.

The default name of the group created by NIS+ scripts for such purposes is the admin group. You can create other groups with different names, and assign different groups to different NIS+ objects.

Member users of an object's group usually have special privileges to access that object, such as permission to make certain changes to the object. For example, you could add several junior administrators to the admin group so that they can only modify the passwd and hosts tables, but they would be unable to modify any other tables. By using an admin group, you can distribute administration tasks across many users and not just reserve them for the superuser of the entire hierarchy. The NIS+ admin group must have credentials created for its members, even if you are running the domain in NIS-compatibility mode, because only authenticated users have permission to modify NIS+ tables.

After identifying the type of credentials you need, you should select the access rights that are required in the namespace. To make that task easier, you should first decide how many administrative groups you need. Using separate groups is useful when you want to assign them different rights. Usually, you create groups by domain. Each domain should have only one admin group.

Planning Access Rights to NIS+ Groups and Directories

After arranging your principals into groups, determine the kinds of access rights granted by the objects in the namespace to those groups, as well as to the other classes of principal (nobody, owner, group, and world). Planning these assignments ahead of time will help you establish a coherent security policy.

As shown in Table 3-1, NIS+ provides different default access rights for different namespace objects.

Table 3-1 Default Access Rights for NIS+ Objects


Object	Nobody	Owner	Group	World
Root-directory object	`r---`	`rmcd`	`rmcd`	`r---`
Non-root directory object	`r---`	`rmcd`	`rmcd`	`r---`
groups_dir directory objects	`r---`	`rmcd`	`rmcd`	`r---`
org_dir directory objects	`r---`	`rmcd`	`rmcd`	`r---`
NIS+ groups	`----`	`rmcd`	`r---`	`r---`
NIS+ tables	`varies`	`varies`	`varies`	`varies`

You can use the default rights or assign your own. If you assign your own, you must consider how the objects in your namespace will be accessed. Keep in mind that the nobody class accepts all requests from NIS+ clients, whether authenticated or not. The world class comprises all authenticated requests from NIS+ clients. Therefore, if you don't want to provide namespace access to unauthenticated requests, don't assign any access rights to the nobody class; reserve them only for the world class. On the other hand, if you expect some clients--through applications, for instance--to make unauthenticated read requests, you should assign read rights to the nobody class. If you want to support NIS clients in NIS-compatibility mode, you must assign read rights to the nobody class.

Also consider the rights that each type of namespace object assigns to the NIS+ groups you specified earlier. Depending on how you plan to administer the namespace, you can assign all or some of the available access rights to the group. A good solution is to have the user root on the master server be the owner of the admin group. The admin group should have create and destroy rights on the objects in the root domain. If you want only one administrator to create and modify the root domain, then put just that administrator in the admin group. You can always add additional members to the group. If several administrators are involved in the setup process, put them all in the group and assign full rights to it. That is easier than switching ownership back and forth.

Finally, the owner of an object should have full rights, although this is not as important if the group does. A namespace is more secure if you give only the owner full rights, but it is easier to administer if you give the administrative group full rights.

Planning Access Rights to NIS+ Tables

NIS+ objects other than NIS+ tables are primarily structural. NIS+ tables, however, are a different kind of object: they are informational. Access to NIS+ tables is required by all NIS+ principals and applications running on behalf of those principals. Therefore, their access requirements are a somewhat different.

Table 3-2 lists the default access rights assigned to NIS+ tables. If any columns provide rights in addition to those of the table, they are also listed. You can change these rights at the table and entry level with the nischmod command, and at the column level with the nistbladm -u command. "Protecting the Encrypted Passwd Field" provides just one example of how to change table rights to accommodate different needs.

Table 3-2 Default Access Rights for NIS+ Tables and Columns


Table/Column		Nobody	Owner	Group	World
hosts table		`r---`	`rmcd`	`rmcd`	`r---`
bootparams table		`r---`	`rmcd`	`rmcd`	`r---`
passwd table		`----`	`rmcd`	`rmcd`	`r---`
	name column	`r---`	`----`	`----`	`----`
	passwd column	`----`	`-m--`	`----`	`----`
	uid column	`r---`	`----`	`----`	`----`
	gid column	`r---`	`----`	`----`	`----`
	gcos column	`r---`	`-m--`	`----`	`----`
	home column	`r---`	`----`	`----`	`----`
	shell column	`r---`	`----`	`----`	`----`
	shadow column	`----`	`----`	`----`	`----`
group table		`----`	`rmcd`	`rmcd`	`r---`
	name column	`r---`	`----`	`----`	`----`
	passwd column	`----`	`-m--`	`----`	`----`
	gid column	`r---`	`----`	`----`	`----`
	members column	`r---`	`-m--`	`----`	`----`
cred table		`r---`	`rmcd`	`rmcd`	`r---`
	cname column	`----`	`----`	`----`	`----`
	auth_type column	`----`	`----`	`----`	`----`
	auth_name column	`----`	`----`	`----`	`----`
	public_data column	`----`	`-m--`	`----`	`----`
	private_data column	`----`	`-m--`	`----`	`----`
networks table		`r---`	`rmcd`	`rmcd`	`r---`
netmasks table		`r---`	`rmcd`	`rmcd`	`r---`
ethers table		`r---`	`rmcd`	`rmcd`	`r---`
services table		`r---`	`rmcd`	`rmcd`	`r---`
protocols table		`r---`	`rmcd`	`rmcd`	`r---`
rpc table		`r---`	`rmcd`	`rmcd`	`r---`
auto_home table		`r---`	`rmcd`	`rmcd`	`r---`
auto_master table			`rmcd`	`rmcd`	`r---`

Note -

NIS-compatible domains give the nobody class read rights to the passwd table at the table level.

Protecting the Encrypted Passwd Field

As you can see in Table 3-2, default read access is provided to the nobody class by all tables except the passwd table. NIS+ tables give the nobody class read access because many applications that need to access NIS+ tables run as unauthenticated clients. However, if this were also done for the passwd table, it would expose the encrypted passwd column to unauthenticated clients.

The configuration shown in Table 3-2 is the default set of access rights for NIS-compatible domains. NIS-compatible domains must give the nobody class read access to the passwd column because NIS clients are unauthenticated and would otherwise be unable to access their passwd column. Therefore, in an NIS-compatible domain, even though passwords are encrypted, they are vulnerable to decoding. They would be much more secure if they were not readable by anyone except their owner.

Standard NIS+ domains (not NIS-compatible) provide that extra level of security. The default configuration (provided by nissetup) uses a column-based scheme to hide the passwd column from unauthenticated users, while still providing access to the rest of the passwd table. At the table level, no unauthenticated principals have read access. At the column level, they have read access to every column except the passwd column.

How does an entry owner get access to the passwd column? Entry owners have both read and modify access to their own entries. They obtain read access by being a member of the world class. (Remember that at the table level, the world class has read rights.) They obtain modify access by explicit assignment at the column level.

Keep in mind that table owners and entry owners are rarely and not necessarily the same NIS+ principals. Thus, table-level read access for the owner does not imply read access for the owner of any particular entry.

As mentioned earlier, this is the default setup from the Solaris 2.3 release forward. For a more complete explanation and discussion of table-, entry-, and column level-security, see Solaris Naming Administration Guide.