Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Like this article? We recommend

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.


For those familiar with other RBAC models, the Solaris RBAC implementation has a flat structure for roles, and hierarchical structures for authorizations and rights profiles. A user can assume only one role at a time, and it must be assumed from the user's normal account. Authorizations are made hierarchical through the use of wildcards and a left-to-right naming convention. Rights profiles are made hierarchical through the ability to assign supplementary profiles to other profiles in a tree structure.

For those familiar with sudo, see Chapter 7, "Appendix 2--Comparison of the RBAC Implementation with Sudo."

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.


The preferred approach is to assign effective IDs, rather than real IDs, as security attributes to commands. Effective IDs are equivalent to the setuid functionality in the file permission bits and identify the user's ID for auditing. However, since shell scripts and other programs may require a real UID of root, real IDs must be available as well. For example, the pkgadd command requires a real, rather than effective, UID.

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.


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.


It is also possible to set up root as a role using a manual process. This prevents users from logging in directly as root, forcing them to log in as themselves first, and overrides the console setting in the /etc/default/login file. To make root a role, the root entry in the user_attr(4) file must be changed from type=normal to type=role. After this change is made, users can be assigned the root role through the Solaris Management Console launcher, the rolemod(1M) command, or by editing the user_attr database. See "Databases Supporting RBAC" and "User Accounts Tool" for more information.


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


Authorization Requirements

at(1), batch(1)

solaris.jobs.user required for all options (when at.allow and at.deny files do not exist)


solaris.jobs.admin required for all options


solaris.jobs.user required for the option to submit a job (when crontab.allow and crontab.deny files do not exist); solaris.jobs.admin required for the options to list or modify other user files

allocate(1M) [if Basic Security Module (BSM) enabled only]

solaris.device.allocate (or other authorization as specified in device_allocate file) required to allocate device; solaris.device.revoke (or other authorization as specified in device_allocate file) required to allocate device to another user (-F option)

deallocate(1M) [if BSM-enabled only]

solaris.device.allocate (or other authorization as specified in device_allocate file) required to deallocate another user's device; solaris.device.revoke (or other authorization as specified in device_allocate file) required to force deallocation of the specified device (-F option) or all devices (-I option)

list_devices(1M) [if BSM-enabled only]

solaris.device.revoke required to list another user's devices (-U option)


The authorizations currently available from Sun are stored in the /etc/ security/auth_attr file. At this time, it is not possible to add new authorizations.

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 Profile

Purpose / Contents


Purpose: Execute any command as the user or role.

Commands: *

Help File: RtAll.html

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

Rights Profile

Purpose / Contents

Primary Administrator

Purpose: Can perform all administrative tasks.

Authorizations: solaris.*, solaris.grant

Commands: *:uid=0;gid=0

Help File: RtPriAdmin.html

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

Rights Profile

Purpose / Contents

System Administrator

Purpose: Can 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 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

Rights Profile

Purpose / Contents


Purpose: Can perform simple administrative tasks.

Supplementary rights profiles: Printer Management, Media Backup, All

Help File: RtOperator.html

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

Rights Profile

Purpose / Contents

Basic Solaris User

Purpose: Provides automatically assigned rights to all users.

Authorizations: solaris.profmgr.read, solaris.jobs.user, 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 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

Rights Profile

Purpose / Contents

Printer Management

Purpose: 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, etc.

Help File: RtPrntMngmnt.html

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 commands may also indicate a security policy. Currently, the only security policy available for the Solaris Operating Environment is suser (for superuser). The suser policy is the default; 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 may be available in future releases.

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

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020