This chapter provides additional information that supplements Chapter 5, Role-Based Access Control (Overview).
The following is a list of the reference information in this chapter:
For information on RBAC tasks, see Chapter 6, Role-Based Access Control (Tasks).
This section describes the role-based access control (RBAC) elements in detail.
No predefined roles are shipped with the Solaris 9 software. Management at a customer site must decide what types of roles should be set up. However, three recommended roles can be readily configured by assigning the appropriate predefined rights profile to the corresponding roles:
Primary Administrator rights profile – For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.
System Administrator rights profile – 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 rights profile – For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.
These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.
Those sites that customize roles should closely check the order of the rights profiles that are assigned to the role. The system does not prevent someone from typing multiple occurrences of the same command. The attributes that are assigned to the first occurrence of a command in a rights profile take precedence and all subsequent occurrences are ignored.
You can also set up root as a role through a manual process. This method prevents users from logging in directly as root, forcing them to log in as themselves first. See Making Root a Role.
This section describes some typical rights profiles.
The All rights profile provides role access to commands without security attributes.
The Primary Administrator rights profile is designed specifically for the Primary Administrator role. The Primary Administrator rights profile allows the use of wildcards.
The System Administrator rights profile is designed specifically for the System Administrator role. The System Administrator rights profile uses discrete supplementary profiles to create a powerful role.
The Operator rights profile is designed specifically for the Operator role. The Operator rights 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 to users that are not related to security.
The Printer Management rights profile exemplifies a profile that is dedicated to a single area of administration.
The tables in the following sections show the purpose and the contents of these rights profiles, including the commands, authorizations, supplementary rights, rights profiles, and associated help files.
Help files are in HTML and can be readily customized, if required. These files reside in the /usr/lib/help/auths/locale/C directory.
The Solaris Management Console Rights tool provides another way of inspecting the contents of the rights profiles.
The All rights profile uses the wildcard to include all commands, except for those commands without security attributes. This rights profile provides a role with access to all commands that are not explicitly assigned in other rights profiles. Without the All rights profile or some other rights profiles that use wildcards, a role has access to explicitly assigned commands only, which is not very practical.
Because 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 rights profile, if used, should be the final rights profile that is assigned.
Table 7–1 Contents of All Rights Profile
Purpose |
Contents |
---|---|
To execute any command as the user or role |
Commands: * Help File: RtAll.html |
The Primary Administrator rights profile is assigned the most powerful role on the system, effectively providing that role with superuser capabilities.
The solaris.* authorization effectively assigns all of the authorizations that are 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 necessary. Help files are stored in the /usr/lib/help/auths/locale/C directory.
Note also that if the Primary Administrator rights profile is not consistent with a site's security policy, it can be modified or not assigned at all. However, the security capabilities in the Primary Administrator rights profile would need to be handled in one or more other rights profiles.
Table 7–2 Contents of Primary Administrator Rights Profile
Purpose |
Contents |
---|---|
To perform all administrative tasks |
Commands: * Authorizations: solaris.*, solaris.grant Help File: RtPriAdmin.html |
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
Purpose |
Contents |
---|---|
To perform most nonsecurity administrative tasks |
Supplementary rights profiles: Audit Review, Printer Management, Cron Management, Device Management, File System Management, Mail Management, Maintenance and Repair, Media Backup, Media Restore, Name Service Management, Network Management, Object Access Management, Process Management, Software Installation, User Management, All Help File: RtSysAdmin.html |
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
Purpose |
Contents |
---|---|
To perform simple administrative tasks |
Supplementary rights profiles: Printer Management, Media Backup, All Help File: RtOperator.html |
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
Purpose |
Contents |
---|---|
To automatically assign rights to all users |
Authorizations: solaris.profmgr.read, solaris.admin.usermgr.read, solaris.admin.logsvc.read, solaris.admin.fsmgr.read, solaris.admin.serialmgr.read, solaris.admin.diskmgr.read, solaris.admin.procmgr.user, solaris.compsys.read, solaris.admin.printer.read, solaris.admin.prodreg.read, solaris.admin.dcmgr.read Supplementary rights profiles: All Help File: RtDefault.html |
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
Purpose |
Contents |
---|---|
To manage printers, daemons, and spooling |
Authorizations: solaris.admin.printer.delete, solaris.admin.printer.modify, solaris.admin.printer.read Commands: /usr/sbin/accept:euid=lp, /usr/ucb/lpq:euid=0, /etc/init.d/lp:euid=0, /usr/bin/lpstat:euid=0, /usr/lib/lp/lpsched:uid=0, /usr/sbin/lpfilter:euid=lp Help File: RtPrntMngmnt.html |
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.
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.
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.
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.
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
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.
The following figure illustrates how the RBAC databases work together.
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 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 |
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.
Field Name |
Description |
---|---|
authname |
A unique character string that is used to identify the authorization in the format prefix.[suffix]. Authorizations for the Solaris operating environment use solaris as a prefix. All other authorizations should use a prefix that begins with the reverse-order Internet domain name of the organization that creates the authorization (for example, com.xyzcompany). The suffix indicates what is being authorized, which is typically the functional area and operation. When the authname consists of a prefix and functional area and ends with a period, the authname serves as a heading to be used by applications in their GUIs, rather than as an actual authorization. The authname of solaris.printmgr. is an example of a heading. When authname ends with the word “grant,” the authname serves as a grant authorization and lets the user delegate authorizations with the same prefix and functional area to other users. The authname of solaris.printmgr.grant is an example of a grant authorization. solaris.printmgr.grant gives the user the right to delegate such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner to other users. |
res1 |
Reserved for future use. |
res2 |
Reserved for future use. |
short_desc |
A terse name for the authorization that is suitable for display in user interfaces, such as in a scrolling list in a GUI. |
long_desc |
A long description. This field identifies the purpose of the authorization, the applications in which it is used, and the type of user who might be interested in using it. The long description can be displayed in the help text of an application. |
attr |
An optional list of semicolon-separated (;) key-value pairs that describe the attributes of an authorization. Zero or more keys can be specified. The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C directory. |
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.
The prof_attr database stores the name, description, help file location, and authorizations that are assigned to rights profiles. The commands and security attributes that are assigned to rights profiles are stored in the exec_attr database (see The exec_attr Database). The fields in the prof_attr database are separated by colons:
profname:res1:res2:desc:attr |
The following table describes these fields.
Field Name |
Description |
---|---|
profname |
The name of the rights profile. Rights profile names are case-sensitive. This name is also used by the user_attr database to indicate rights profiles that are assigned to roles and users. |
res1 |
Reserved for future use. |
res2 |
Reserved for future use. |
desc |
A long description. This field should explain the purpose of the rights profile, including what type of user would be interested in using it. The long description should be suitable for display in the help text of an application. |
attr |
An optional list of key-value pairs that are separated by semicolons (;) that describes the security attributes to apply to the object on execution. Zero or more keys can be specified. The two valid keys are help and auths. The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C directory. The keyword auths specifies a comma-separated list of authorization names that are chosen from those names that are defined in the auth_attr database. Authorization names can be specified with the asterisk (*) character as a wildcard. |
The following example shows a typical prof_attr database. Note that the Printer Management rights profile is a supplementary rights profile that is assigned to the Operator rights profile.
% grep 'Printer Management' /etc/security/prof_attr Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html; \ auths=solaris.admin.printer.read,solaris.admin.printer.modify,solaris.admin.printer.delete \ Operator:::Can perform simple administrative tasks:profiles=Printer Management,\ Media Backup,All;help=RtOperator.html ... |
An execution attribute is a command that is associated with a specific UID or GID and that is assigned to a rights profile. The command with its security attributes can be run by users or roles to whom the rights profile is assigned.
The exec_attr database stores the definitions of the execution attributes.
The fields in the exec_attr database are separated by colons:
name:policy:type:res1:res2:id:attr |
The following table describes these fields.
Field Name |
Description |
---|---|
name |
The name of the rights profile. Rights profile names are case-sensitive. The name refers to a rights profile in the prof_attr database. |
policy |
The security policy that is associated with this entry. Currently, suser (the superuser policy model) is the only valid entry. |
type |
The type of entity that is specified. Currently, the only valid entity type is cmd (command). |
res1 |
Reserved for future use. |
res2 |
Reserved for future use. |
id |
A string that identifies the entity. Commands should have the full path or a path with a wildcard. To specify arguments, write a script with the arguments and point the id to the script. |
attr |
An optional list of semicolon (;) separated key-value pairs that describes the security attributes to apply to the entity on execution. Zero or more keys can be specified. The list of valid keywords depends on the policy that is enforced. The four valid keys are euid, uid, egid, and gid. The euid and uid keywords contain a single user name or a numeric user ID (UID). Commands that are designated with euid run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands that are designated with uid run with both the real and effective UIDs. The egid and gid keywords contain a single group name or numeric group ID (GID). Commands that are designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on an executable file. Commands that are designated with gid run with both the real and effective GIDs. |
The following example shows some typical values from an exec_attr database.
% grep 'Printer Management' /etc/security/exec_attr Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0 Printer Management:suser:cmd:::/etc/init.d/lp:euid=0 . . . |
The policy.conf file provides a way of granting specific rights profiles and authorizations to all users. The two types of entries in the file consist of key-value pairs. They are the following:
AUTHS_GRANTED=authorizations – Refers to one or more authorizations
PROFS_GRANTED=right profiles – Refers to one or more rights profiles
The following example shows some typical values from a policy.conf database.
# grep AUTHS /etc/security/policy AUTHS_GRANTED=solaris.device.cdrw # grep PROFS /etc/security/policy PROFS_GRANTED=Basic Solaris User |
This section lists commands that are used to administer RBAC. Also provided is a table of commands whose access can be controlled by authorizations.
In addition to editing the RBAC databases directly, the following commands are available for managing access to tasks with RBAC.
Table 7–7 RBAC Administration Commands
The following table provides examples of how authorizations are used to limit command options in the Solaris environment. See also Authorizations.
Table 7–8 Commands and Associated Authorizations
Commands |
Authorization Requirements |
---|---|
solaris.jobs.user required for all options (when neither at.allow nor at.deny files exist) |
|
solaris.jobs.user required for the option to submit a job (when neither crontab.allow nor crontab.deny files exist) solaris.jobs.admin required for the options to list or modify other users' crontab files |
|
allocate(1) (with BSM enabled only) |
solaris.device.allocate (or other authorization as specified in device_allocate(4)) required to allocate a device. solaris.device.revoke (or other authorization as specified in device_allocate file) required to allocate a device to another user (-F option) |
deallocate(1) (with BSM enabled only) |
solaris.device.allocate (or other authorization as specified in device_allocate(4)) required to deallocate another user's device. solaris.device.revoke (or other authorization as specified in device_allocate) required to force deallocation of the specified device (-F option) or all devices (-I option) |
list_devices(1) (with BSM enabled only) |
solaris.device.revoke required to list another user's devices (-U option) |