System Administrator Rights Profile

The System Administrator rights profile is intended for the System Administrator role. Because the System Administrator does not have the broad powers of the Primary Administrator, no wildcards are used. Instead, discrete administrative rights profiles that do not deal with security are assigned. The commands that are assigned to the supplementary rights profiles are not shown in the following table.

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

Table 7-3 Contents of System Administrator Rights Profile

Operator Rights Profile

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

Table 7-4 Contents of Operator Rights Profile

Basic Solaris User Rights Profile for User

By default, the Basic Solaris User rights profile is assigned automatically to all users through the policy.conf file. This rights profile provides basic authorizations that are useful in normal operations. Note that the convenience that is offered by the Basic Solaris User rights profile must be balanced against site security requirements. Those sites that need stricter security might prefer to remove this rights profile from the policy.conf file.

Table 7-5 Contents of Basic Solaris User Rights Profile

Printer Management Rights Profile

Printer Management is a typical rights profile that is intended for a specific task area. Both authorizations and commands are assigned to the Printer Management rights profile. The following table shows a partial list of commands.

Table 7-6 Contents of Printer Management Rights Profile

Authorizations

An authorization is a discrete right that can be granted to a role or user. Authorizations are checked by RBAC-compliant applications before a user gets access to the application or specific operations within it. This check replaces the tests in conventional UNIX applications for UID=0.

Authorization Naming Convention

An authorization has a name that is used internally and in files (for example, solaris.admin.usermgr.pswd), and a short description, which appears in the graphical user interfaces (for example, Change Passwords).

By convention, authorization names consist of the reverse order of the Internet name of the supplier, the subject area, any subareas, and the function, which are all separated by dots. An example would be com.xyzcorp.device.access. Exceptions to this convention are the authorizations from Sun Microsystems, Inc., which use the prefix solaris instead of an Internet name. Sun's convention enables administrators to apply authorizations in a hierarchical fashion by using a wildcard (*) to represent any strings to the right of a dot.

Example of Authorization Granularity

As an example of how authorizations are used, consider the following. A user in the Operator role might be limited to the solaris.admin.usermgr.read authorization, which provides read but not write access to users' configuration files. The System Administrator role naturally has the solaris.admin.usermgr.read and also the solaris.admin.usermgr.write authorization for making changes to users' files. However, without the solaris.admin.usermgr.pswd authorization, the System Administrator cannot change passwords. 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. This authorization is also required for using the password modification options in the smuser, smmultiuser, and smrole commands.

Delegating Authorizations

An authorization that ends with the suffix grant permits a user or role to delegate to other users any assigned 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.

Databases That Support RBAC

The following four databases store the data for the RBAC elements:

• user_attr (extended user attributes database) - Associates users and roles with authorizations and rights

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

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

• exec_attr (execution attributes database) - Identifies the commands with security attributes that are assigned to specific rights profiles

Note - The commands can also indicate a security policy. Currently, the only security policy that is available for the Solaris operating environment is suser (short for superuser). The suser policy is the default and it accommodates both the ID attributes and authorizations. The Trusted Solaris environment, which can interoperate with the Solaris environment, uses a policy called tsol. Additional policies might be available in future releases.

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

RBAC Database Relationships

The following figure illustrates how the RBAC databases work together.

Figure 7-1 RBAC Database Relations

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

Each database uses a key=value syntax for storing attributes. This method accommodates future expansion of the databases and enables a system to continue if it encounters a key that is unknown to its policy.

The scope of the RBAC databases can apply to individual hosts or to all hosts that are 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 that is specified for the passwd entry in the file /etc/nsswitch.conf. The precedence for the prof_attr and auth_attr databases are individually set in /etc/nsswitch.conf. The exec_attr database 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.

The databases can reside on a local system or can be administered by the NIS, NIS+, or LDAP name service.

You can edit the databases manually or manipulate them with the commands that are described in Command-Line Applications for Managing RBAC.

The user_attr Database

The user_attr database contains user and role information that supplements the passwd and shadow databases. The user_attr database contains extended user attributes such as authorizations, rights profiles, and assigned roles. The fields in the user_attr database are separated by colons, as follows:

user:qualifier:res1:res2:attr

The following table describes these fields.

The following example demonstrates how the Operator role is defined in a typical user_attr database and how it is assigned to user johnDoe. Roles and users are differentiated by the type keyword.

% grep operator /etc/user_attr 
johnDoe::::type=normal;roles=sysadmin,operator
operator::::profiles=Operator;type=role

The auth_attr Database

All authorizations are stored in the auth_attr database. Authorizations can be assigned directly to users (or roles) in the user_attr database. Authorizations can also be assigned to rights profiles, which are assigned to users.

The fields in the auth_attr database are separated by colons, as follows:

authname:res1:res2:short_desc:long_desc:attr

The following table describes these fields.

The following example shows an auth_attr database with some typical values.

% grep printer /etc/security/auth_attr 
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html

Note that solaris.admin.printer. is defined to be a heading, because it ends in a dot (.). Headings are used by the GUIs to organize families of authorizations.