Rights for Users and Roles

    Introduction

    Administrative Rights

    Users and Roles

    What Is a Role?

    Available Rights

    Rights for Regular Users

    Customizing Rights

    Real and Effective UIDs and GIDs

    Rights Hierarchies

    Command Line Interface

    Assigning the Primary Administrator Role to Others

    RBAC Databases

Introduction

Maintaining administrative security and control is of paramount importance in every networked environment. With this in mind, the Solaris 8 operating environment enables the most senior administrator (the one granted the right of Primary Administrator) to provide all other administrators with the tools and commands needed to perform their jobs, while restricting those administrators' access to additional tools and commands.

This section describes rights (the "units" of administrative control), how rights are granted or denied to an administrator, a description of rights that are included in Solaris, and how to create new rights.

Administrative Rights

A right is a named collection that includes three components: commands, authorizations to use specific applications (or to perform specific functions within an application), and other, previously-created rights. Rights can be granted or denied to an administrator. (Rights are also referred to as "Execution profiles" elsewhere in Solaris 8.) The ability to simply view data is also a right; by default all users who can log in (are successfully authenticated) have the right to view most data.

By granting or denying rights, senior administrators allow other administrators to perform specific administrative tasks through both the GUI (menu items, dialog boxes, icons, and so on) and the command line.

Controlling administrative rights has been problematic in the past because there are only two types of users on traditional UNIX systems: regular users (the vast majority) who have no administrative rights, and root users (those who know the root password for a computer) who have all rights and can perform all administrative tasks. Because an administrator needed to become the root user to perform even the simplest administrative task (setting the system date, for example) this opened the system to abuse and security problems.

Solaris 8 continues to provide the root user, but it reduces the security problem by allowing senior administrators to grant or deny specific rights to individual users. The effect is to divide all the rights contained within root and grant specific ones to individual administrators.

Users and Roles

Through the Solaris Management Console (SMC), senior administrators have two methods for granting rights:

What Is a Role?

A role has all the attributes of a user account -- including a name, user identification number (UID), password, home directory, and specific set of administrative rights. One difference is that, instead of the usual login shell, roles are given a role shell (Administrator's Bourne, rather than Bourne, for example). You can think of root as a role with all rights, while other roles have more limited rights.

With Role-Based Access Control (RBAC), users first log in with their own user name and password. The SMC then offers them a list of roles that they can assume -- the roles must be explicitly assigned through the User Accounts or Administrative Roles tools. The user either chooses a role, and logs in with the role password, or can log in with his or her own user name. When logging in as a role, the user relinquishes his or her user identity and takes on all the attributes of the role, including the rights granted to that role.

Assigning rights to users is recommended for smaller sites, where fewer administrators each perform a wide range of administrative tasks. RBAC, assigning rights to roles, is recommended for large sites where there are many administrators, each with specific administrative tasks to perform.

Roles are managed with the Administrative Roles tool. After the SMC is installed, all authenticated users can run the Administrative Roles tool and read data, but only the user or role assigned the right of Primary Administrator can add roles and assign them to users. Once the Primary Administrator assigns rights to users and roles, any user or role with the User Security right can add, modify, or delete roles.


Granting Rights to Users and Roles

The following information applies only to users and roles who are authorized to grant rights. Those who are not authorized will not see the rights tab.


Available Rights

The Solaris operating environment provides more than a dozen named rights, each name descriptive of the kinds of tasks the right allows -- Mail Management, Name Service Administration, User Management, and so forth. Included in each right are the commands for performing management tasks and the authorizations needed to use the SMC applications, or portions of applications, for performing those tasks.

Rights can be assigned to a user or to a role. Rights can be assigned individually, so a user or role might, for example, receive the right to perform media backups only, or multiple rights can be assigned to a single user or role.

For convenience in assigning rights, the individual rights have been grouped into three overall rights: Primary Administrator, System Administrator, and Operator.

Rights for Regular Users

By default, any regular user is authorized to list and read information in the SMC tools, without an administrator explicitly assigning rights to that user. This default authorization is provided through the entry in the /etc/security/policy.conf file that states PROFS_GRANTED=Basic Solaris User. You can add rights to this line, separating rights with commas (without any spaces). Rights listed on the PROFS_GRANTED= line are added to each user or role's set of rights.

To deny all regular users the ability to view SMC information, set PROFS_GRANTED= to empty.

To prevent regular users from using a specific SMC tool, remove that tool's "Read" authorization from the Basic Solaris User Right:

  1. In the left pane of the SMC, open System Configuration, then Users.

  2. Open the Rights tool and double-click Basic Solaris User (the Right Properties dialog box opens).

  3. Click the Authorizations tab and click View As Names at the bottom of the tab.

  4. Open the entries in the Authorizations Included column, then select the "read" authorization you want to deny, and click Remove. (As you select each "read" authorization, the context help provides descriptions of each authorization.)

Customizing Rights

After using the predefined rights, the Primary Administrator may want to refine them, set up more narrowly defined rights for specific administrators, for example, or even create entirely new rights. These rights can then be assigned to users or to roles. Use the Rights tool in the Solaris Management Console (SMC) to customize rights.


Creating and Modifying Rights


Real and Effective UIDs and GIDs

All commands executed after the user assumes a role, or through the SMC's Legacy Launcher, have two types of group IDs (GIDs) and user IDs (UIDs) -- effective and real.

Effective user and group IDs are used for access control to protected resources, while real user and group IDs are used for establishing ownership and responsibility. For example, when users create files, the files are created with the users' real user and group IDs, but the ability to open a file is based on the effective user and group IDs.

In most cases, effective IDs are sufficient for granting access to restricted system resources. In other cases, the real IDs are required. If you are not sure which to use, try effective first. This is consistent with the principle of least privilege, where you grant only what is necessary and sufficient to perform a task. If the command does not perform as expected, then the real IDs are probably necessary.

Commands are executed under the real or effective UID and GID established for the command, whether launched by the Solaris Management Console, executed as a role, or executed by a user in an Administrator's shell.


Changing Real and Effective UID and GID

From the Rights tool, double-click the name of the right containing the command you want to change. Click the Commands tab and select the command. Then click Set Security Attributes. In the dialog box that opens, you can change between real and effective user and group IDs.


Rights Hierarchies

With the Rights tool, you can add a right to a right, which means the same command could occur more than once in a right. When Solaris searches for a command in a right, it uses the first occurrence of the command it finds, much the same as how the PATH variable works. For example, the command /usr/bin/date may be specified in one right with an effective user ID of root, but in another right the command is specified to run as normal user. Therefore, the order of the rights becomes very important. The most specific and powerful rights should be listed first, followed by subordinate rights, and wild card entries should be kept last in the list.

The same attention to the relative power and specificity of rights is also important when assigning rights to user and roles.


Changing the Order of Rights Within Rights

From the Rights tool, double-click the name of the right you want to reorder. When the Right Properties dialog box opens, click the Supplementary Rights tab and use the Move Up and Move Down arrows on the right you select.


Command Line Interface

Rights provided through the SMC allow roles and users to work in both the graphical user interface of the SMC and in a terminal or console window, in an administrator's shell.

To assume a role and work in an administrator's shell, a user enters su followed by a role name, and then that role's password. A user can also work under his or her own user account in an administrator's shell -- by being given the shell through the User Properties dialog box, or by typing pfsh, pfcsh, or pfksh in the command line of a normal user shell. When a user or role enters a command in an administrator's shell, the command can be executed only if it is included in rights assigned to the user or role.

The command will be executed under the real or effective ids set in the rights entry.

Assigning the Primary Administrator Role to Others

It is possible for the Primary Administrator role to be assigned to users other than root. Before making that assignment, however, for auditing purposes, root itself should be identified as a role (which is not the default) so it is possible to identify who has taken on the root identity. From a command line, edit the /etc/user_attr entry for root and change it from type=normal to type=role. Once this is done, root cannot be used as a login account.

RBAC Databases

To learn about where Role-Based Access Control information is stored, and the relationship among the databases, see the Solaris 8 System Administration Guide, Volume 2. Also, reference the RBAC man pages, starting with man rbac.