Rights Profiles and Roles

System Security, Roles, and Rights Profiles

Rights Profiles

Authorizations

Roles

Profile Shells

Trusted Path

Solaris Management Console in Trusted Solaris

Available Rights Profiles

Customizing RightsProfiles

Real vs Effective UID and GID

Hierarchies of Rights Profiles

System Security, Roles, and Rights Profiles

Trusted Solaris and Solaris provide role-based access control (RBAC) as an alternative to the traditional all-or-nothing system administration model. On traditional systems, even the simplest tasks (such as setting the system date) must be done by a highly trusted user, because root login gives access to all aspects of the system. Anyone who learns the root password can log in and do just about anything anonymously.

In contrast, a system with RBAC enabled is administered by multiple administrators with separate responsibilities, none of whom have total control of the system. With RBAC, root access is no longer required for administration.

No one can do administrative work anonymously because a user must log in first and identify himself or herself before assuming a role. Actions performed while in the role are identified with the role's id instead of the id of the logged-in user, but to allow the actions performed in a role to be traced back to the responsible user, the user's id is maintained as an audit id.

RBAC divides administrative tasks among three recommended roles, and a site using RBAC can reconfigure the role responsibilities to any desired degree of granularity.

Another advantage in Trusted Solaris is that administrative work is performed through the trusted path, which provides a means to perform security-relevant operations with assurance that you are not being spoofed and that keystrokes and windows cannot be viewed by untrusted processes. A role is assumed through the Trusted Path menu, and once the role is assumed, the role's work is performed in an administrative role workspace with the trusted path

A role can only do tasks that are defined for that role, because each role is restricted to using only the minimum set of tools required to do those tasks. The needed tools (commands, CDE actions, and authorizations) are collected in rights profiles. Rights profiles control not only what roles are able to do but also what any user is allowed to do on the system.

Top ^

Rights Profiles

A rights profile is a named collection of one or more authorizations, commands, and CDE actions and optional security attributes that may be assigned to the commands and actions. Rights profiles can be nested within other rights profiles.

The Rights tool in the User Manager displays existing rights profiles and can be used by an authorized role or user to modify rights profiles or create new ones. The definitions of rights profiles are stored in entries in the prof_attr(4) and exec_attr(4) databases.

A rights profile can be assigned to a user or role account in the following ways:

To see which profiles are available to the account entering the command or to another account, users and roles can use the profiles(1) command. To see all profiles on the system, use the list option of the smprofile(1M) command.

Top ^

Authorizations

An authorization allows a user to perform some operation or class of operations that check for the presence of an authorization and fail if the authorization is not available. For example, viewing of information and making modifications using the Solaris Management Console (SMC) are controlled by authorizations.

Authorizations are one of the means used to divide administrative responsibilities among roles. For example, the authorizations to specify security-sensitive information is assigned to the Security Administrator profile, while the authorizations to specify the same types of information that a traditional system administrator can specify is assigned to the System Administrator profile.

Authorizations are defined in the auth_attr(4) database. Authorizations can be assigned system-wide to all user and role accounts in the policy.conf(4) file. For example, at a site where all users are allowed to use media devices to save and restore data at a single label, the Security Administrator role could assign the Allocate Device authorization to all users with the following entry in the policy.conf file:
          AUTHS_GRANTED=Allocate Device

Top ^

Roles

A role has all the attributes of a user account--including a name, user identification number (UID), password, home directory, membership in a primary group and optional secondary groups, a mailbox, a login shell, and one or more rights profiles assigned. (Also see Attributes of User and Role Accounts.)

A role account, however, has several differences from normal user accounts that allow roles to perform their set of administrative tasks:

Users who are allowed to assume roles first log in with their own user names and passwords. The Trusted Path menu in the Front Panel displays the roles a user can assume. After choosing the Assume <rolename> Role option, the user is prompted for the role password. After role authentication is complete, an administrative workspace becomes active in which administrative work can be performed that requires the trusted path.

Top ^

Profile Shells

The profile shells execute only commands listed in the rights profile in effect for the user or role. A command is executed with any security attributes specified for the command. The profile shells, pfsh, pfcsh, and pfksh (also called "administrator's shells"), are described on the pfexec(1M) man page.

For normal users, the profile shells are optional. A user can either be assigned a profile shell as the account's login shell, or if a user has another login shell and access to a terminal, the user can type the name of the profile shell on the command line of a terminal.

Trusted Path

The "trusted path" provides a means to perform security-relevant operations with assurance that you are not being spoofed and that keystrokes and windows cannot be viewed by untrusted processes. In Trusted Solaris, roles are assumed from the trusted path, and roles perform system management from the trusted path.

The administrator assumes an administrative role after first logging in with a normal username and entering the password assigned to the user account. To assume the role, the administrator selects the Assume Role option from the Trusted Path menu in the front panel and then enters the role password. An administrative role workspace becomes active for the role, and all activities performed in the role workspace are part of the trusted path.

Top ^

Solaris Management Console in Trusted Solaris

In the Trusted Solaris environment, most administration is performed by roles using either the Solaris Management Console (SMC) or equivalent command line interfaces. Normal users by default do not have the needed authorizations to use the SMC tools.

The SMC or equivalent command line interfaces require the trusted path when invoked by a role. Therefore, they can be successfully invoked by roles only in an administrative role workspace. Both the SMC and commands display the username of the logged-in user and prompt for the role password.

If the SMC or equivalent command line interface is invoked by a normal user in a normal user workspace, the user is prompted for the user password. In Trusted Solaris, users cannot assume roles through the SMC. It is possible to assign to a normal user the authorizations that are required for managing the system using the SMC. In Trusted Solaris, a user with the relevant authorizations could launch the SMC and use it in a normal user workspace without the trusted path.

Top ^

Available Rights Profiles

The names of the rights profiles indicate the kinds of tasks each rights profile allows--such as, Mail Management, Name Service Administration, User Management, and so forth. Each rights profile includes one or more authorizations, commands, or actions, and optional security attributes for commands and actions, which are needed for performing management tasks.

One or more rights can be assigned to a user or to a role.

Top ^

Customizing Rights Profiles

After becoming familiar with the predefined rights profiles, the Security Administrator may want to refine them, for example, by setting up more narrowly-defined rights profiles for specific administrators, or by creating new rights profiles. Customizing rights profiles is done through the Rights Tool in the Solaris Management Console.

Top ^

Real vs Effective UID and GID

Similar to assigning the setuid and setgid to UNIX commands, you can assign a real or effective uid or gid to a command or action in a rights profile. This can enable a command or action to succeed when it requires a real or effective uid or gid that is different from the uid or gid of the account that launches the command or action.

A common use of the traditional setuid is to allow programs to run with the uid of one of the system accounts such as bin, sys, and lp to update files owned by the system account. These system accounts do not have passwords so that no one can log into these accounts and compromise the filesystem.

The following differences exist between real and effective uids in filesystem operations.

If you are not sure whether to use effective or real uids or gids, try effective first, to be consistent with the principle of least privilege. (According to the principle of least privilege, you grant only whatever extended powers are necessary and sufficient to perform a task.) If the command or action does not perform as expected, then the real ids are probably necessary.

Specify a user name in the Rights tool and the corresponding uid is used when the command or action is running. Specify a group name and the corresponding gid is used.

UID Tips and Examples

The real uid most often required is 0, the uid of root (or superuser). For example, most installation programs check that they are being run by root with real uid of 0. After assigning a real uid of root to an installation program in a rights profile, the Security Administrator can assign the rights profile to a role that has another uid, such as the System Administrator role, which usually has uid 100. When run by the role with the command in one of its rights profiles, the installation program has a uid of 0.

GID Tips and Examples

Say, for example, that your site has created a group called enghelp to allow sharing of files among the members of the enghelp group, and you want to set up a role so that new directories created by the role are given the enghelp group. Because the group of a directory is obtained by mkdir from the effective gid, you then need to assign enghelp as the effective gid to mkdir.

  1. Select mkdir in the Commands Permitted column.
  2. Select Effective.
  3. Type enghelp in the Group field.
  4. Grant the rights profile containing mkdir with the enghelp group id to the desired role.
  5. Make sure that the new rights profile is in the role's list of rights profiles above any other profile that may assign other attributes to mkdir.

Any directories created by the role then have the group of enghelp.

Top ^

Hierarchies of Rights Profiles

Rights profiles can be nested within other rights profiles, and more than one rights profile can be assigned to the same user or role account. The same command or action can occur more than once in the rights profiles assigned to a single account and can have different security attributes assigned. For example, the command /usr/bin/date may be specified in one rights profile with an effective user ID of root, but in another rights profile the command is specified to run with privileges. The order of the rights profiles is important because the first occurrence of a command or action is used with the attributes defined for it, much the same as how the first occurrence of a command in a user's command search path is used. Rights profiles that assign all commands or all actions use a wildcard (*), and because they assign no privileges or other attributes to the commands or actions, the rights profiles that use a wildcard should be last in the list.