Rights for Users and Roles

    Introduction

    Rights

    Users and Roles

    What Is a Role?

    Available Rights

    Rights for Normal 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 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 (usually through special accounts called roles), a description of rights that are included in Solaris, and how to create new rights.

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 "rights profiles" elsewhere in Solaris.) 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 rights has been problematic in the past because there are only two types of users on traditional UNIX systems: normal users (the vast majority) who have no 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.

The Solaris operating environment now provides a way to reduce potential security problems 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, 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 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).

With Role-Based Access Control (RBAC), users first log in with their own user name and password. The console 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 continues to 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.

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


Granting Rights to Users and Roles

The following information applies only to administrators 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 console applications, or portions of applications, for performing those tasks.

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

For convenience in assigning rights, the individual rights have been grouped into three overall rights: Primary Administrator, System Administrator, and Operator. Each of these consists of a collection of rights that could also be granted individually.

Rights for Normal Users

By default, any normal user is authorized to list and read information in the console 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 normal users the ability to view Solaris Management Console information, set PROFS_GRANTED= to empty.

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

  1. In the left pane of the console, 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 Descriptions at the bottom of the tab.
    Note: View As Names shows you the names that are included in the /etc/security/auth_attr file, which lists all authorizations. The authorization to view a tool is written in the auth_attr file as "read."
  4. Open the entries in the Authorizations Included column, then select the "view" authorization you want to deny, and click Remove. (As you select each "view" 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 roles. Use the Rights tool in the Solaris Management Console 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 console'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 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 Solaris Management Console allow roles and users to work in both the graphical user interface 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.

=>su rolename
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.

Note: 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 System Administration Guide: Security Services. Also, reference the RBAC man pages, starting with man rbac.