RBAC in the Solaris™ Operating Environment

Like this article? We recommend

Solaris 8 Essential Reference

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Solaris 8 Essential Reference

Learn More Buy

Chapter 2: Solaris RBAC Implementation

The RBAC model in the Solaris Operating Environment is based on users logging in as themselves and assuming special identities that enable them to run restricted administration tools and utilities.

RBAC is fully compatible with Solaris auditing; the actions of a role are attributable to the user who assumed the role, and the audit records include the identity of the user, role, and effective ID used for policy overrides. The audit event mask of the user is augmented by that of the role.

The RBAC model introduces three elements to the Solaris Operating Environment:

• Role—A special identity that can be assumed by assigned users only.

• Authorization—A permission that can be assigned to a role or user to perform a class of actions otherwise prohibited by security policy.

• Rights Profile—A package that can be assigned to a role or user. It may consist of:

• Authorizations

• Commands with security attributes. The Solaris security attributes are the setuid functions for setting real or effective user IDs (UIDs) and group IDs (GIDs) on commands. Other systems, such as the Trusted Solaris environment, may use additional override mechanisms as security attributes.

• Supplementary (nested) rights profiles

Figure 2 shows how the RBAC elements fit in with the Solaris useradministration. The arrows point from an attribute element to the element it canbe assigned to. Solid arrows indicate preferred assignments. Dashed arrowsindicate assignments that are possible but not considered secure.

Figure 2 Solaris RBAC Element Assignments.

Roles are assigned to users, enabling a user to assume a role. Rightsprofiles are assigned to roles, providing the root-like capabilities.Authorizations and commands with security attributes are components of rightsprofiles. Authorizations and rights profiles can be assigned directly to users,but this is not considered a secure practice.

Privileged Applications

Applications that override system controls by checking for authorizations or for specific UIDs or GIDs are considered to be privileged applications. These applications are not separate RBAC elements, but rather make use of authorizations and commands with security attributes.

The Solaris 8 environment, version 1/01, provides applications that check for authorizations:

• The entire Solaris Management Console suite of tools

• The batch job-related commands (at (1), atq (1), batch (1), and crontab (1))

• The device allocation commands (allocate (1M), deallocate (1M), and list_devices (1M))

By default, superuser is assigned all authorizations and thus can still execute these commands. The framework is now in place for sites that wish to delegate authorizations for using these applications.

Commands that must run with special IDs can be packaged with the needed security attributes in a rights profile for assignment to users or roles.

Authorized users can access privileged applications from the Solaris Management Console launcher or from the command line of a special shell called a profile shell. The profile shell is a Bourne, Korn, or C shell that has been modified to grant roles (and users) access to privileged commands assigned to their rights profiles.

Roles

A role is created in the same general manner as a user account, with a home directory, groups, password, and so on. Role information is stored in the passwd, shadow, user_attr (described later in this article), and audit_user databases. All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users can assume roles from the command line by using su and supplying the role password. A user can also assume a role when opening a Solaris Management Console tool.

Users cannot login directly to a role; they must login to their user account first. There is no inheritance with roles; that is, when a user assumes a role, the role's attributes replace all of that user's attributes. The user's real UID is used for auditing purposes only. A user cannot assume a role directly while in a different role; roles are not hierarchical. A role's action can always be audited for the role ID and the user's real ID.

There are no predefined roles shipped with the Solaris 8 software, version 1/01. It is up to the customer site to decide what types of roles should be set up. However, there are three roles that can be readily configured by assigning one of the predefined rights profiles:

• Primary Administrator—For creating a role that can perform all administrative tasks, grant rights to others, and edit rights associated with administrative roles. It may also assign to others the Primary Administrator role and the ability to grant rights.

• System Administrator—For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts but cannot set passwords or grant rights to other users.

• Operator—For creating a role that can perform simple administrative tasks, such as backup, restore, and printer maintenance.

These rights profiles enable administrators to configure the suggested roles using a single profile, instead of having to mix and match rights profiles.

Sites that customize roles should pay close attention to the order of the rights profiles assigned to the role. The system does not prevent someone from entering multiple occurrences of the same command. The attributes assigned to the first occurrence of a command in a profile take precedence, and all subsequent occurrences are ignored.

Authorizations

An authorization is a discrete right granted to a user or role. RBAC-compliant applications can check a user's authorizations prior to granting access to the application or specific operations within it. This is analogous to conventional UNIX applications checking for UID=0.

An authorization has a name that is used internally and in files (for example, solaris.admin.usermgr.pswd), and a short description that appears in the graphical interfaces (for example, Change Passwords). By convention, authorization names begin with the reverse order of the Internet name of the supplier followed by the subject area, any sub-area, and the function, all separated by dots (for example, com.xyzcorp.device.access). The exceptions to this convention are authorizations from Sun, which use the prefix solaris instead of an Internet name. This convention enables administrators to apply authorizations in a hierarchical fashion using a wildcard (*) to represent any strings to the right of a dot.

As an example of how authorizations are used, consider the following example of users in roles created using the predefined rights profiles. A user in the Operator role might be limited to the solaris.admin.usermgr.read authorization, which provides read but not write access to user configuration files. The System Administrator role naturally has both the solaris.admin.usermgr.read and the solaris.admin.usermgr.write authorizations for making changes to user files; but without the solaris.admin.usermgr.pswd authorization, the System Administrator cannot change a user's password. The Primary Administrator has all three of these authorizations. The solaris.admin.usermgr.pswd authorization is required to make password changes in the Solaris Management Console User Tool. It is also required for using the password modification options in the smuser(1M), smmultiuser(1M), and smrole(1M) commands.

An authorization that ends with the suffix grant permits a user or role to delegate any of their authorizations that begin with the same prefix. For example, a role with the authorizations solaris.admin.usermgr.grant and solaris.admin.usermgr.read can delegate the solaris.admin.usermgr.read authorization to another user. A role with the solaris.admin.usermgr.grant and solaris.admin.usermgr.* can delegate any of the authorizations with the solaris.admin.usermgr prefix to other users.

Table 1 provides examples of how authorizations are used to limit command options in the Solaris environment.

Table 1

Rights Profiles

This section describes some typical rights profiles to demonstrate:

• The All rights profile provides a role access to commands without security attributes.

• The Primary Administrator, System Administrator, and Operator rights profiles are designed for specific roles. The Primary Administrator profile demonstrates the use of wildcards. The System Administrator profile uses discrete supplementary profiles to create a powerful role. The Operator profile uses a few discrete supplementary profiles to create a simple role.

• The Basic Solaris User rights profile shows how the policy.conf file can be used to assign tasks not related to security.

• The Printer Management rights profile is an example of a profile dedicated to a single area of administration.

The contents of the rights profiles are displayed in tables which label the purpose, authorizations, commands, supplementary rights profiles, and help files assigned. The help files are in HTML. They are stored in the directory /usr/lib/help/profiles/locale/C and can be readily customized if required. The Solaris Management Console Rights tool can also be used to inspect the contents of rights profiles.

All Rights Profile

The All rights profile uses the wildcard to include all commands with no security attributes. It is intended to provide a role access to all commands not explicitly assigned in other rights profiles. Without the All rights profile or some other rights profile that uses wildcards, a role has access only to explicitly assigned commands, which is not very practical.

Since commands in rights profiles are interpreted in the order in which they occur, any wildcard settings should be positioned last so that explicit attribute assignments are not inadvertently overridden. The All profile (if used) should be the final profile assigned.

Table 2

Rights Profiles for Specific Roles

The Primary Administrator, System Administrator, and Operator rights profiles are designed for specific roles. The Primary Administrator rights profile demonstrates the use of wildcards. The System Administrator rights profile demonstrates the use of supplementary rights profiles for a more powerful role. The Operator Role is an example of a rights profile with a more limited role.

Primary Administrator

The Primary Administrator rights profile is intended to be assigned to the most powerful role on the system, effectively providing that role with superuser capabilities. The solaris.* authorization effectively assigns all of the authorizations provided by the Solaris software. The solaris.grant authorization lets a role assign any authorization to any rights profile, role, or user. The command assignment *:uid=0;gid=0 provides the ability to run any command with UID=0 and GID=0. The help file RtPriAdmin.html is identified, so that a site can modify it if needed.

If the Primary Administrator rights profile is too powerful for a site's security policy, it can be modified or not assigned at all, provided that the security capabilities are handled in a different rights profile.

Table 3

System Administrator

The System Administrator rights profile is intended for the system administrator role. Since the system administrator does not have the broad powers of the primary administrator, no wildcards are used. Instead, discrete administrative rights profiles dealing with general administration are assigned. The rights profiles contain no authorizations associated with passwords, roles, or rights profiles. (The commands assigned to the supplementary rights profiles are not shown in this example.)

Notice that the All rights profile is assigned at the end of the list of supplementary rights profiles assigned to the System Administrator.

Table 4

Operator

The Operator profile is a less powerful administrative rights profile and provides the ability to do backups and printer maintenance. The ability to restore files has more security consequences, so the default is to not assign it to this rights profile.

Table 5

Basic Solaris User Rights Profile

By default, the Basic Solaris User rights profile is assigned to all users through the policy.conf(4) file. It provides basic authorizations useful in normal operation, typically read-only access to general resources and read-write access to the user's personal resources. Note that there is a trade off between the convenience offered by the Basic Solaris User rights profile and security. Those sites that need stricter security may prefer to remove this profile from the policy.conf file.

Table 6

Printer Management Rights Profile

Printer Management is a typical rights profile intended for a specific task area. Both authorizations and commands are assigned to the Printer Management rights profile. (Note that only a partial list of commands is shown in the table).

Table 7

RBAC Example

Figure 3 illustrates how the elements interoperate to support the RBAC model.

Figure 3 Solaris RBAC Element Assignment Example.

The example has an Operator role for maintaining printers and performing media backup. The Operator role is assigned to user johnDoe, who can assume it by supplying the Operator password.

The Operator rights profile has been assigned to the Operator role. The profile has three supplementary profiles assigned to it. Printer Management and Media Backup reflect the role's chief tasks, and All is included for access to all other commands, but without any security attributes.

The Printer Management rights profile is for managing printers, print daemons, and spoolers. It has three authorizations: solaris.admin.printer.read, solaris.admin.printer.modify, and solaris.admin.printer.delete for manipulating information in the printer queue. The Printer Management profile also has a number of commands with security attributes assigned to it, /usr/sbin/accept with euid=0, and /usr/ucb/lpq with euid=lp, for example.

Databases Supporting RBAC

Data for the RBAC elements is stored in these four databases:

• user_attr (extended user attributes database)—Associates users and roles with authorizations and rights profiles.

• auth_attr (authorization attributes database)—Defines authorizations and their attributes, and identifies the associated help file.

• prof_attr (rights profile attributes database)—Defines profiles, lists the profile's assigned authorizations, and identifies the associated help file.

• exec_attr (profile execution attributes database)—Identifies the commands with security attributes assigned to specific rights profiles.

The policy.conf database is also important to the RBAC implementation. It can contain authorizations and rights profiles to be applied to all users by default.

The user_attr database stores the basic definitions for both users and roles (they are differentiated by the type field). It contains the attributes shown in Figure 4, which includes a comma-separated list of profile names. The definitions of the rights profiles are split between the prof_attr database, which contains profile identification information, authorizations assigned to the profile, and supplementary profiles, and the exec_attr database, which identifies the policy and contains commands with associated security attributes. The auth_attr database supplies authorization information to the Solaris Management Console tools. The policy.conf database supplies default authorizations and rights profiles to be applied to all users.

Each of these databases uses a key=value syntax for storing attributes. This approach accommodates future expansion of the databases, and allows a system to continue if it encounters a key unknown to its policy.

The scope of the RBAC databases can apply to individual hosts, or to all hosts served by a name service such as NIS, NIS+, or LDAP. The precedence of local configuration files versus distributed databases for the user_attr database is set by the precedence specified for the passwd entry in the file /etc/nsswitch.conf. The precedence for prof_attr and auth_attr are individually set in /etc/nsswitch.conf. The exec_attr file uses the same precedence as prof_attr. For example, if a command with security attributes is assigned to a profile that exists in two scopes, only the entry in the first scope is used.

These databases can be created manually or by using the smattrpop(1M) command. The databases can reside on a local system or they can be administered by the NIS, NIS+, or LDAP name service.

Figure 4 illustrates how the RBAC databases work together.

Figure 4 RBAC Database Relations.

The databases can be edited manually or manipulated with the following commands:

• smexec(1M)—manage entries in the exec_attr database

• smmultiuser(1M)—manage bulk operations on user accounts

• smuser(1M)—manage user entries

• smprofile(1M)—manage profiles in the prof_attr and exec_attr databases

• smrole(1M)—manage roles and users in role accounts

• useradd(1M)—add new users

• usermod(1M)—change user files

• rolemod(1M)—change role files

• roledel(1M)—remove roles

• roleadd(1M)—add new role