NIS+ Security Overview
This chapter describes the NIS+ security system and how it affects the entire NIS+ namespace.
Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.
Solaris Security--Overview
In essence, Solaris security is provided by gates that users must pass through in order to enter the Solaris environment, and permission matrixes that determine what they are able to do once inside. (See Figure 11-1 for a schematic representation of this system.)
Figure 11-1 Solaris Security Gates and Filters
As you can see in the above figure, the overall system is composed of four gates and two permission matrixes:
Dialup gate. To access a given Solaris environment from the outside through a modem and phone line, you must provide a valid Login ID and Dialup password.
Login gate. To enter a given Solaris environment you must provide a valid login ID and user password.
File and Directory Matrix. Once you have gained access to a Solaris environment, your ability to read, execute, modify, create, and destroy files and directories is governed by the applicable permissions matrix.
Root gate. To gain access to root privileges, you must provide a valid super user (root) password.
Secure RPC gate. In an NIS+ environment running at security level 2 (the default), when you try to use NIS+ services and gain access to NIS+ objects (servers, directories, tables, table entries, and so forth) your identity is confirmed by NIS+ using the Secure RPC process.
Consult your Solaris documentation for detailed descriptions of the Dialup, Login, and Root gates, and the File and Directory permissions matrix.
To enter the Secure RPC gate requires presentation of a Secure RPC password. (In some contexts Secure RPC passwords have been referred to as network passwords.) Your Secure RPC password and your login password normally are identical and when that is the case you are passed through the gate automatically without having to re-enter your password. (See "Secure RPC Password Versus Login Password Problem" for information regarding cases where the two passwords are not the same.)
A set of credentials are used to automatically pass your requests through the Secure RPC gate. The process of generating, presenting, and validating your credentials is called authentication because it confirms who you are and that you have a valid Secure RPC password. This authentication process is automatically performed every time you request an NIS+ service.
In an NIS+ environment running in NIS-compatibility mode (also known as YP-compatibility mode), the protection provided by the Secure RPC gate is significantly weakened because everyone has read rights for all NIS+ objects and modify rights for those entries that apply to them regardless of whether or not they have a valid credential (that is, regardless of whether or not the authentication process has confirmed their identity and validated their Secure RPC password). Since that allows anyone to have read rights for all NIS+ objects and modify rights for those entries that apply to them, an NIS+ network running in compatibility mode is less secure than one running in normal mode.
For details on how to create and administer NIS+ authentication and credentials, see Chapter 12, Administering NIS+ Credentials.
NIS+ objects matrix. Once you have been properly authenticated to NIS+ your ability to read, modify, create, and destroy NIS+ objects is governed by the applicable permissions matrix. This process is called NIS+ authorization.
For details NIS+ permissions and authorization, see Chapter 15, Administering NIS+ Access Rights.
NIS+ Security--Overview
NIS+ security is an integral part of the NIS+ namespace. You cannot set up security and the namespace independently. For this reason, instructions for setting up security are woven through the steps used to set up the other components of the namespace. Once an NIS+ security environment has been set up, you can add and remove users, change permissions, reassign group members, and all other routine administrative tasks needed to manage an evolving network.
The security features of NIS+ protect the information in the namespace, as well as the structure of the namespace itself, from unauthorized access. Without these security features, any NIS+ client could obtain and change information stored in the namespace or even damage it.
NIS+ security does two things:
Authentication. Authentication is used to identify NIS+ principals. Every time a principal (user or machine) tries to access an NIS+ object, the user's identity and Secure RPC password is confirmed and validated.
Authorization. Authorization is used to specify access rights. Every time NIS+ principals try to access NIS+ objects, they are placed in one of four authorization classes (owner, group, world, nobody). The NIS+ security system allows NIS+ administrators to specify different read, modify, create, or destroy rights to NIS+ objects for each class. Thus, for example, a given class could be permitted to modify a particular column in the passwd table but not read that column, or a different class could be allowed to read some entries of a table but not others.
In essence, then, NIS+ security is a two-step process:
Authentication. NIS+ uses credentials to confirm that you are who you claim to be.
Authorization. Once your identity is established by the authentication process, NIS+ determines your class. What you can do with a given NIS+ object or service depends on which class you belong to. This is similar in concept to the standard UNIX file and directory permissions system. (See "Authorization Classes" for more information on classes.)
This process, for example, prevents someone with root privileges on machine A from using the su command to assume the identity of a second user and then accessing NIS+ objects with the second user's NIS+ access privileges.
Note, however, that NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is logged in from the same machine.
Figure 11-2 details this process:
Figure 11-2 Summary of the NIS+ Security Process
NIS+ Principals
NIS+ principals are the entities (clients) that submit requests for NIS+ services. An NIS+ principal may be someone who is logged in to a client machine as a regular user, someone who is logged in as superuser, or any process that runs with superuser permission on an NIS+ client machine. Thus, an NIS+ principal can be a client user or a client machine.
An NIS+ principal can also be the entity that supplies an NIS+ service from an NIS+ server. Since all NIS+ servers are also NIS+ clients, much of this discussion also applies to servers.
NIS+ Security Levels
NIS+ servers operate at one of two security levels. These levels determine the type of credential principals that must submit for their requests to be authenticated. NIS+ is designed to run at the most secure level, which is security level 2. Level 0 is provided only for testing, setup, and debugging purposes. These security levels are summarized in Table 11-1.
Table 11-1 NIS+ Security Levels
Security Level | Description |
|---|---|
0 | Security level 0 is designed for testing and setting up the initial NIS+ namespace. An NIS+ server running at security level 0 grants any NIS+ principal full access rights to all NIS+ objects in the domain. Level 0 is for setup purposes only and should only be used by administrators for that purpose. Level 0 should not be used on networks in normal operation by regular users. |
1 | Security level 1 uses AUTH_SYS security. This level is not supported by NIS+ and should not be used. |
2 | Security level 2 is the default. It is the highest level of security currently provided by NIS+. It authenticates only requests that use DES credentials. Requests with no credentials are assigned to the nobody class and have whatever access rights that have been granted to that class. Requests that use invalid DES credentials are retried. After repeated failure to obtain a valid DES credential, requests with invalid credentials fail with an authentication error. (A credential might be invalid for a variety of reasons such as the principal making the request is not keylogged in on that machine, the clocks are out of synch, there is a key mismatch, and so forth.) |
Security Levels and Password Commands
In Solaris releases 2.0 through 2.4, you used the nispasswd command to change your password. However, nispasswd could not function without credentials. (In other words, it could not function under security level 0 unless there were credentials existing from some previous higher level.) Starting with Solaris Release 2.5, the passwd command should now be used to change your own password regardless of security level or credential status.
NIS+ Authentication and Credentials--Introduction
The purpose of NIS+ credentials is to authenticate (confirm) the identity of each principal requesting an NIS+ service or access to an NIS+ object. In essence, the NIS+ credential/authorization process is an implementation of the Secure RPC system.
The credential/authentication system prevents someone from assuming some other user's identity. That is, it prevents someone with root privileges on one machine from using the su command to assume the identity of a second user who is not logged in and then accessing NIS+ objects with the second user's NIS+ access privileges.
Once a server authenticates a principal, the principal is placed in one of four authorization classes. The server then checks the NIS+ object that the principal wants to access to see what activities that class of principal is authorized to perform. (See "NIS+ Authorization and Access--Introduction" for further information on authorization.)
User and Machine Credentials
There are two basic types of principal, users and machines, and thus two different types of credentials:
User credentials. When someone is logged in to an NIS+ client as a regular user, requests for NIS+ services include that person's user credentials.
Machine credentials. When a user is logged in to an NIS+ client as superuser, request for services use the client machine's credentials.
DES versus LOCAL Credentials
NIS+ principals can have two types of credential: DES and LOCAL.