Real and Effective UIDs and GIDs
Assigning the Primary Administrator Role to Others
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.
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.
Through the Solaris Management Console, senior administrators have two methods for granting rights:
Assign rights directly to users. This is not the recommended approach for most
rights, although it might be useful to assign some minor rights directly to users. See Getting Started With Users Tools.
Assign rights to roles and then permit only certain users to assume each role. This is the recommended method. Users who wish to perform administrative tasks must assume a role and relinquish their own identity.
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.
The following information applies only to administrators authorized to grant rights. Those who are not authorized will not see the rights tab.
Granting Rights to a User
Assigning rights to users is not recommended because of potential security problems, but this information is presented in case you do want to assign some lesser rights directly to users.
From the User Accounts tool, double-click the user's name in the right pane of the console. In the User Properties dialog box, click the Rights tab and add the rights for that user. (Alternatively, select the user's name and click Action->Assign Rights to User, then choose the rights from the dialog box that opens.)
Granting Rights Through a Role
From the Administrative Roles tool, double-click the role you want to permit a user to assume. Assign the specific rights through the Rights tab of that role. Add the user's name to the Users tab of the same role -- granting the user permission to assume this role. (Alternatively, select the role and click Action->Assign Rights to Role and choose the rights from the dialog box that opens.) Then, tell the user which role he or she can assume, and the role password to use when logging in to the console.
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.
Primary Administrator
The Primary Administrator
has all the rights of the root user, including the rights to access
all administrative functions, to grant rights to other
administrators, and to create and change the rights associated with
administrative roles. The Primary Administrator can make anyone else
a Primary Administrator. Or, the Primary Administrator can grant the
right of Rights Delegation, which gives other administrators the
limited ability to grant to others only those rights they already
have or only those roles they already have.
When the Solaris Management Console and the user management tools are installed on a new
server, a comprehensive set of user rights is included. However, no
user accounts (except for those special accounts included in the
Solaris operating environment) exist, and no administrator has the
rights needed to begin creating users, assigning roles, and so forth.
To begin adding groups and users, assigning rights, and creating roles, the first administrator to log in to the console must log in as the root user on a local system, create the role of Primary Administrator, and then assume that role. See Getting Started With Users Tools.
System Administrator
The System Administrator has an extensive set of rights, but no security-related rights. So, for example, the System Administrator can add new user accounts but not change a user's password. Nor can the System Administrator grant rights to another user.
Operator
An Operator takes care of such tasks as media backup and printer administration.
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:
/etc/security/auth_attr
file, which lists all authorizations. The authorization to view a tool is written in the auth_attr
file as "read."
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
Creating a New Right
From the Solaris Management Console, select the Rights tool and click Action->Add Right. When the Add Right dialog box opens, follow the context-sensitive help.
Modifying an Existing Right
From the Solaris Management Console, select the Rights tool and double-click the right's name in the right pane, to open the right's Property dialog box. Then modify the information in the various tabs.
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.
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.
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.
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.
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
.