Determine the Impact of Implementing 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 used 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. In addition, the secret key stored with the key server process is not automatically removed when a credentialed non-root user logs out unless that user logs out with keylogout(1). Security may still 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(1). Nevertheless, NIS+ is much more secure than NIS.

Keeping these trade-offs in mind, consider the impact NIS+ security will have on both users and administrators before you decide what security level to use.

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 a bit 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. A client is correctly configured when their login password and their network password are the same. The secret key for the user root is normally made available in the /etc/.rootkey file (a possible security problem as noted earlier). When the NIS+ user password and credential are changed with the nispasswd 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 network passwords, and if these passwords are different from the network passwords, then users must run keylogin each time they run login. The reasons for this are explained in the security chapter in the Name Services Administration Guide.

How NIS+ Security Affects Administrators

Because Solaris 2.x bundles the DES encryption mechanism for authentication, administrators who need secure operation do not need to purchase a separate encryption kit. However, administrators must train users how to use the nispasswd and the chkey commands, and when to use them.

Furthermore, setting up a secure NIS+ namespace is more complex than setting up one 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 dead 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 to 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 should use full NIS+ security even if you operate some or all servers in a domain in NIS-compatibility mode. (It is preferable though that all servers in a domain 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 category, 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 and, in particular, their network passwords.
• Users will not be able to verify that the name service information is coming from an authenticated NIS+ server.

Select Credentials

NIS+ provides two types of credential: LOCAL and DES. All NIS+ principals need at least one of these credentials. If the namespace is running at security level 2 (the default), all NIS+ principals (clients) must have DES credentials in their home domain. 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

Type of Principal

NIS+ principals can be users or the superuser identity on the client workstation.

Figure 3-1 NIS+ Principals

When you determine the credentials you need to create, make sure you know which type of principal the credential is for. For instance, when you set up an NIS+ client (use nisclient), you will create credentials for both the workstation and for the user. Unless credentials for the user are also created, the user would only have the access rights granted to the nobody class. This can work perfectly well if that's how you choose to set up your namespace. But if you don't give any access rights to the nobody class, the namespace won't be available to the users.

NIS+ cannot distinguish between a human principal and a workstation principal when requests are made. Therefore, all user names must be different from machine names in the same namespace. For example, under NIS, it is acceptable to have a user with the login name of jane whose local machine is also named jane. So that user's network address is jane@jane. This user will have to change either her login or her machine name when her site converts to NIS+. Identical user and machine names are a problem even when the machine with the duplicate name does not belong to the user with the same name. The following examples illustrate duplicate name combinations not valid with NIS+:

• jane@jane in the same namespace
• tree@jane and jane@tree in the same namespace
• joe@tree and tree@mike in the same namespace

The best solution to this problem is to check all /etc files and NIS maps before you use the data to populate NIS+ tables. If you find duplicate names, change the machine names rather than the login names, and later create an alias for the machine's old name.

Selecting a Security Level

Even though NIS+ servers can operate at three security levels, you should not run your domain at lower than level 2, the highest level of NIS+ security unless you have a very good reason. Security level 2 is also the default level set when you use the NIS+ scripts to create your NIS+ namespace. If you run your domain at a lower level of security than level 2, then any user will have the access rights to modify the name service information and the namespace's structure. Security level 0 is only useful for creating the namespace. At this level, any user can become root on any machine in the network. Security level 1 uses only the user id for authorization and does no authentication of the user.

Security level 2 sends only requests that use DES credentials to appropriate NIS+ principals. Requests that only use LOCAL credentials or none at all are assigned the access rights granted to the nobody class. Requests that use invalid DES credentials are denied. See Name Services Administration Guide for more information on the NIS+ security levels.

Forming NIS+ Groups

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

The default name of the group created by NIS+ scripts for such purposes is the admin group. Member users of the admin group have special privileges, such as permission to make certain changes to the namespace information. 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 will 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.

Determine Access Rights to NIS+ Groups and Directories

After arranging your principals into groups, determine the kind of access rights granted by the objects in the namespace to those groups, as well as to the other categories 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

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 (see Table 3-2 on page 40)	varies	varies	varies	varies

You can use the default rights or assign your own. If you assign your own, you will have to consider how the objects in your namespace will be accessed. Keep in mind that the nobody class comprises 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 will have to assign read rights to the nobody class.

Also consider the rights each type of namespace object will assign 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 only want 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 may be 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.

Determine Access Rights to NIS+ Tables

NIS+ objects other than NIS+ tables are primarily structural. NIS+ tables, however, are a different type 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 bit different.

Table 3-2 on page 40 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" on page 41 provides just one example of how to change table rights to accommodate different needs.

Table 3-2

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---	----	----	----
1 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---

Table 3-2 (Continued)

Table/Column	Nobody	Owner	Group	World
rpc table	r---	rmcd	rmcd	r---
auto_home table	r---	rmcd	rmcd	r---
auto_master table	r---	rmcd	rmcd	r---

Protecting the Encrypted Passwd Field As you can see in Table 3-2, 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 Figure 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.

Figure 3-2 Default Passwd Table Access Rights for NIS-compatible Domains

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:

Figure 3-3 Default Passwd Table Access Rights for Standard NIS+ Domains

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:

                      Nobody  Owner   Group   World
Passwd Table Rights   :  ----    rmcd    rmcd    r---
Passwd Column Rights  :  ----    -m--    ----    ----

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. To use this scheme in earlier versions of the Solaris software, follow the instructions in the task titled, "How to Limit Access to the Passwd Column," in Name Services Administration Guide.