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 4-1 on page 54 for a schematic representation of this system.)

Figure 4-1

As you can see in Figure 4-1, 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.

  To enter the Secure RPC gate requires presentation of a Secure RPC password. 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" on page 82 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 a 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 5, "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 7, "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:

1. Authentication. NIS+ uses credentials to confirm that you are who you claim to be.

(You should not have to enter a password as part of the authentication process. However, if for some reason your Secure RPC password is different than your login password, you will have to perform a keylogin the first time you try to access NIS+ objects or services. To perform a keylogin, you must provide a valid Secure RPC password. See "Secure RPC Password versus Login Password Problem" on page 82.)

2. 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. For example, a given NIS+ table may allow one class to both read and modify the information in the table, but a different class is only allowed to read the information, and a third class is not even allowed to do that. This is similar in concept to the standard UNIX file and directory permissions system. (See "Authorization Classes" on page 63 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 who is either not logged in at all or logged in on machine B, 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 4-2 details this process:

Figure 4-2

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 workstation.

A 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 types of credential principals 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 4-1 on page 59.

Table 4-1

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 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.) In Solaris release 2.5 (and later), 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 a NIS+ service or access to a 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 either not logged in at all or logged in on another machine and then accessing NIS+ objects with the second user's NIS+ access privileges.

---

Caution - NIS+ cannot prevent someone who knows another user's login password from assuming that other user's identity and the other user's NIS+ access privileges. Nor can NIS+ prevent a user with root privileges from assuming the identity of another user who is currently logged in on the same machine.

---

Once a server authenticates a principal, it then checks the NIS+ object that the principal wants to access to see what activities that principal is authorized to perform. (See "NIS+ Authorization and Access--Introduction" on page 63 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 workstation's credentials.

DES versus LOCAL Credentials

NIS+ principals can have two types of credential: DES and LOCAL.

DES Credentials

DES (Data Encryption Standard) credentials are the type of credential that provide secure authentication. When this guide refers to NIS+ checking a credential to authenticate a NIS+ principal, it is the DES credential that NIS+ is validating.

Each time a principal requests a NIS+ service or access to a NIS+ object, the software uses the credential information stored for that principal to generate a credential for that principal. DES credentials are generated from information created for each principal by a NIS+ administrator, as explained in Chapter 5, "Administering NIS+ Credentials."

• When the validity of a principal's DES credential is confirmed by NIS+, that principal is authenticated.
• A principal must be authenticated in order to be placed in the owner, group, or world authorization classes. In other words, you must have a valid DES credential in order to be placed in one of those classes. (Principals who do not have a valid DES credential are automatically placed in the nobody class.)
• DES credential information is always stored in the cred table of the principal's home domain, regardless of whether that principal is a client user or a client workstation.

LOCAL Credentials

LOCAL credentials are simply a map between a user's User ID number and NIS+ principal name which includes their home domain name. When users log in, the system looks up their LOCAL credential, which identifies their home domain where their DES credential is stored. The system uses that information to get the user's DES credential information.

When users log in to a remote domain, those requests use their LOCAL credential which points back to their home domain; NIS+ then queries the user's home domain for that user's DES credential information. This allows a user to be authenticated in a remote domain even though the user's DES credential information is not stored in that domain.

Figure 4-3

LOCAL credential information can be stored in any domain. In fact, in order to log into a remote domain and be authenticated, a client user must have a LOCAL credential in the cred table of the remote domain. If a user does not have a LOCAL credential in a remote domain the user is trying to access, NIS+ will be unable to locate the user's home domain to obtain the user's DES credential. In such a case the user would not be authenticated and would be placed in the nobody class.

User Types and Credential Types

A user can have both types of credential, but a machine can only have a DES credential.

Root cannot have NIS+ access, as root, to other machines because the root UID of every machine is always zero. If root (UID=0) of machine A tried to access machine B as root, that would conflict with machine B's already existing root (UID=0). Thus, a LOCAL credential doesn't make sense for a client workstation; so it is allowed only for a client user. :

Table 4-2

Type of Credential	Client User	Client Workstation
DES	Yes	Yes
LOCAL	Yes	No

NIS+ Authorization and Access--Introduction

The basic purpose of NIS+ authorization is to specify the access rights that each NIS+ principal has for each NIS+ object and service.

Once the principal making an NIS+ request is authenticated, NIS+ places them in an authorization class. The access rights (permissions) that specify which activities a principal may do with a given NIS+ object are assigned on a class basis. In other words, one authorization class may have certain access rights while a different class has different rights.

• Authorization classes. There are four authorization classes: owner, group, world, and nobody. (See "Authorization Classes" below for details.
• Access rights. There are four types of access rights (permissions): create, destroy, modify, and read. (See "NIS+ Access Rights" on page 67 for details.)

Authorization Classes

NIS+ objects do not grant access rights directly to NIS+ principals. Instead, they grant access rights to four classes of principal:

• Owner. The principal who happens to be the object's owner gets the rights granted to the owner class.
• Group. Each NIS+ object has one group associated with it. The members of an object's group are specified by the NIS+ administrator. The principals who belong to the object's group class get the rights granted to the group class.
• World. The world class encompasses all NIS+ principals that a server has been able to authenticate. (That is, everyone who has been authenticated but who is not in either the owner or group classes.)

• Nobody. Everyone belongs to the nobody class even those who are not authenticated.

Figure 4-4

For any NIS+ request, the system determines which class the requesting principal belongs to and the principal then can use whatever access rights belonging to that class.

An object can grant any combination of access rights to each of these classes. Normally, however, a higher class is assigned the same rights as all the lower classes, plus possible additional rights.

For instance, an object could grant read access to the nobody and world classes, both read and modify access to the group class, and read, modify, create, and destroy access to the owner class.

The four classes are described in detail below.

The Owner Class

The owner is a single NIS+ principal.

A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) before being granted owner access rights.

By default, an object's owner is the principal that created the object. However, an object's owner can cede ownership to another principal in two ways:

• One way is for the principal to specify a different owner at the time the object is created (see "Specifying Access Rights in Commands" on page 120).
• A second way is for the principal to change the ownership of the object after it is created (see "Changing Ownership of Objects and Entries" on page 132).

Once a principal gives up ownership, that principal gives up all owner's access rights to the object and keeps only the rights the object assigns to either the group, the world, or nobody.

The Group Class

The object's group is a single NIS+ group.

A principal making a request for access to an NIS+ object must be authenticated (present a valid DES credential) and belong to the group before being granted group access rights.

An NIS+ group is a collection of NIS+ principals, grouped together as a convenience for providing access to the namespace. The access rights granted to an NIS+ group apply to all the principals that are members of that group. (An object's owner, however, does not need to belong to the object's group.)

When an object is created it may be assigned a default group. A nondefault group can be specified for an object when it is created or later. An object's group may be changed at any time.

Information about NIS+ groups is stored in NIS+ group objects, under the groups_dir subdirectory of every NIS+ domain:

Figure 4-5

Instructions for administering NIS+ groups are provided in Chapter 9, "Administering NIS+ Groups."

The World Class

The world class contains all NIS+ principals that are authenticated by NIS+. In other words, everyone in the owner and group class, plus everyone else who presents a valid DES credential.

Access rights granted to the world class apply to all authenticated principals.

The Nobody Class

The nobody class is composed of anyone who is not properly authenticated. In other words, anyone who does not present a valid DES credential.

Authorization Classes and the NIS+ Object Hierarchy

There is a hierarchy of NIS+ objects and authorization classes that can apply independently to each level. The standard default NIS+ directory hierarchy is:

• Directory level. In each NIS+ domain there are two NIS+ directory objects: groups_dir and org_dir. Each groups_dir directory object contains various groups. Each org_dir directory object contains various tables.
• Group level or table level. Groups contain individual entries and possibly other groups. Tables contain both columns and individual entries.

• Column level. A given table will have one or more columns.
• Entry (row) level. A given group or table will have one or more entries.

The four authorization classes apply at each level. Thus, a directory object will have its own owner and group. The individual tables within a directory object will have their own individual owners and groups which may be different than the owner and group of the directory object. Within a table, a column or an entry may have its own individual owner or group which may be different than the owner and group of the table as a whole or the directory object as a whole.

NIS+ Access Rights

NIS+ objects specify their access rights as part of their object definitions. (You can examine these by using the niscat -o command, described on page 172.)

NIS+ objects specify access rights for NIS+ principals in the same way that UNIX files specify permissions for UNIX users. Access rights specify the types of operations that NIS+ principals are allowed to perform on NIS+ objects.

NIS+ operations vary among different types of objects, but they all fall into one of the four access rights categories: read, modify, create, and destroy.

• Read. A principal with read rights to an object can view the contents of that object.
• Modify. A principal with modify rights to an object can change the contents of that object.
• Destroy. A principal with destroy rights to an object can destroy or delete the object.
• Create. A principal with create rights to a higher level object can create new objects within that level. In other words, if you have create rights to a NIS+ directory object, you can create new tables within that directory. If you have create rights to a NIS+ table, you can create new columns and entries within that table.

Every communication from an NIS+ client to an NIS+ server is, in effect, a request to perform one of these operations on a specific NIS+ object. For instance, when an NIS+ principal requests the IP address of another workstation, it is effectively requesting read access to the hosts table object,

which stores that type of information. When a principal asks the server to add a directory to the NIS+ namespace, it is actually requesting modify access to the directory's parent object.

Keep in mind that these rights logically evolve down from directory to table to table column and entry levels. For example, to create a new table, you must have create rights for the NIS+ directory object where the table will be stored. When you create that table, you become its default owner. As owner, you can assign yourself create rights to the table which allows you to create new entries in the table. If you create new entries in a table, you become the default owner of those entries. As table owner, you can also grant table-level create rights to others. For example, you can give your table's group class table-level create rights. In that case, any member of the table's group can create new entries in the table. The individual member of the group who creates a new table entry becomes the default owner of that entry.

The NIS+ Administrator

An NIS+ administrator is anyone who has administrative rights over an NIS+ object. For the purpose of this discussion, administrative rights are defined as create, destroy, and for some objects, modify rights. (See "NIS+ Access Rights" on page 67 for a description of NIS+ access rights.)

Whoever creates an NIS+ object sets the initial access rights to that object. If the creator restricts administrative rights to the object's owner (initially the creator), than only the owner has administrative power over that object. On the other hand, if the creator grants administrative rights to the object's group, then everyone in that group has administrative power over that object.

Thus, who ever has administrative rights over an object is considered to be an NIS+ administrator for that object.

In other words, the NIS+ software does not enforce any requirement that there be a single NIS+ administrator.

Theoretically, you could grant administrative rights to the world class, or even the nobody class. The software allows you to do that. But granting administrative rights beyond the group class effectively nullifies NIS+ security. Thus, if you grant administrative rights to either the World or the nobody class you are, in effect, defeating the purpose of NIS+ security.

NIS+ Password, Credential, and Key Commands

Use the following commands to administer passwords, credentials, and keys (see the appropriate man pages for a full description of each command):

• chkey. Changes a principal's Secure RPC key pair. Do not use chkey unless necessary, use passwd instead. See "Changing Keys for a NIS+ Principal" on page 100 for more information.
• keylogin. Decrypts and stores a principal's secret key with the keyserv. See "Keylogin" on page 99 for more information.
• keylogout. Deletes stored secret key from keyserv.
• keyserv. Enables the server for storing private encryption keys. See "Keylogin" on page 99 for more information.
• newkey. Creates a new key pair in public-key database.
• nisaddcred. Creates credentials for NIS+ principals. See "Creating Credential Information" on page 86 and "Administering NIS+ Credential Information" on page 96 for more information.
• nisupdkeys. Updates public keys in directory objects. See "Updating Public Keys" on page 105 for more information.
• passwd. Changes and administers principal's password. See Chapter 8, "Administering Passwords" for more information.