Home > Articles > Operating Systems, Server > Solaris

Role Based Access Control and Secure Shell—A Closer Look At Two Solaris Operating Environment Security Features

📄 Contents

  1. Role Based Access Control (RBAC)
  2. Secure Shell
  3. Summary
  4. References
  5. Acknowledgments
To aid the customer in adopting better security practices, this article introduces and explains two security features in the Solaris operating environment. The first is Role Based Access Control and the second is Secure Shell. The goal is to provide you with enough information to make an effective decision to use or not use these features at your site as well as to address configuration and implementation topics. This article is targeted to the intermediate level of expertise.
Like this article? We recommend

Like this article? We recommend

In the course of supporting customers we often get a chance to become familiar with system configurations and common practices used by many of our customers. Our customers are increasingly becoming more security conscious and are focusing more and more time implementing better security practices. To aid the customer in adopting better security practices, this article introduces and explains two security features in the Solaris™ operating environment. The first is Role Based Access Control and the second is Secure Shell. The goal is to provide you with enough information to make an effective decision to use or not use these features at your site as well as to address configuration and implementation topics.

Role Based Access Control (RBAC)

Role Based Access Control first became a visible feature in Trusted Solaris™ software and was later incorporated into the Solaris 8 operating environment. The Solaris 9 operating environment continues to improve upon the prior implementation. The feature set discussed in this article is that of the Solaris 9 12/02 release. With small differences, most of the information discussed can also be applied to prior Solaris releases.

RBAC takes a step back from the traditional UNIX administration model with an all powerful superuser called root, and augments this with a model that understands the security principle of least privilege. That is, not every person administering a system needs the all powerful root password to do their job, and users should only be given the minimal amount of privilege actually necessary to accomplish their given responsibilities. Their unique responsibilities become known as roles. Within the RBAC model, many roles can be created, each with its own specific capabilities tailored to meet your security policy. This helps to provide a system management policy according to organizational needs rather than a necessity to grant the powerful root password outside the confines of a strict group of users.

A role has all the attributes of a normal user account including a name, unique UID, home directory, password, along with a specific set of unique capabilities. Users first log in as themselves, then assume a role by running the switch user (su) command. The login shell for a role is one of the profile shells: /bin/pfsh, /bin/pfcsh, or /bin/pfksh. These profile shells understand RBAC and implement the role capabilities as defined in the RBAC configuration files. Some common roles are the ability to shut down a host, mount a file system, and start or restart privileged daemons. Examples for implementing capabilities such as these are provided later in the article.

There are three roles that can easily be configured:

  • Primary administrator—A powerful role that is equivalent to root.

  • System administrator—A less strong role for administration that is not related to security. This role does not allow the user to set passwords.

  • Operator—A junior administrator role for operations such as backups, restores, and printer management.

Other roles can be configured as required. Examples are included in the section "RBAC Examples" later in this article.

RBAC Configuration Files

There are several database files important to the configuration of RBAC. They can be located on the specific host or they can be located in the naming services databases via NIS, NIS+, or LDAP. As usual, the source and the search order comes from the file /etc/nsswitch.conf. This article does not attempt to provide all the details available in man pages for these files, but will specify the more useful information to get you started towards a quick understanding of RBAC configuration.


The extended user attributes database defines users and roles, and most importantly, which users can assume which roles. It also specifies the profile used when assuming a particular role. The format of the file is:




The name of the user as specified in the passwd(4) database.


Reserved for future use.


Reserved for future use.


Reserved for future use.


An optional list of semicolon-separated (;) key=value pairs that describe the security attributes to apply to the object upon execution. There are five valid keys: auths, profiles, roles, type, and project. Zero or more keys can be specified depending upon the desired result.

As you can see, only the user and attr fields are significant. The user field specifies a valid user in the /etc/password database whether this entry specifies a role or a user. Roles are assigned their own specific UID, and this user must have a valid home directory. Every user assuming this role will use this home directory. However, roles are differentiated from users in this file via the type key=value pair. An example will be provided later to clarify this. The profiles key=value pair relates to an entry by that value in the /etc/security /prof_attr and /etc/security/exec_attr databases. Note that while the auths key=value pair is listed here, the preferred use is in the /etc/security/prof_attr database file. This is because abstracting authorizations via execution profiles rather than the user attributes database can provide for better adaptability to changing security needs. Further, note that although profiles can be assigned directly to users, this practice is discouraged because users could make inadvertent mistakes by misuse of their privileges at an inappropriate time. Refer to the man page user_attr(4) for more details.


The execution profile description database links together the commands and authorizations needed to perform a specific function. If no specific authorizations are required, this file simply defines a profile to be used by a role. The format of this file is:




The name of the profile. Profile names are case-sensitive.


Reserved for future use.


Reserved for future use.


A long description. This field should explain the purpose of the profile, including what type of user would be interested in using it. The long description should be suitable for displaying in the help text of an application.


An optional list of semicolon-separated (;) key=value pairs that describe the security attributes to apply to the object upon execution. There are three valid keys: help, profs, and auths. Zero or more keys can be specified depending upon the desired result.

Again this file looks complicated, but in reality is very simple. profname is a profile name used by the /etc/user_attr database described above. profs simply refers to other profiles described by other lines in this file, and serves as a way to nest the definition of a given profile. The auths key=value pair relates to an entry by that value in the /etc/security/auth_attr database. Refer to the man page prof_attr(4) for more details.


The execution profiles database defines the commands and security attributes that will be executed by a profile shell. Remember it is ideal to assign roles to users, profiles to roles, and specific commands and authorizations to profiles. The format of this file is:




The name of the profile. Profile names are case-sensitive.


The policy that is associated with the profile entry. It is always the text suser.


The type of object defined in the profile. It is always the text cmd.


Reserved for future use.


Reserved for future use.


A string that uniquely identifies the object described by the profile. For a profile of type cmd, the id is either the full path to the command or the asterisk (*) symbol, which is used to allow all commands. An asterisk that replaces the file name component in a path name indicates all files in a particular directory. To specify arguments, the path name should point to a shell script written to execute the command with the desired arguments.


An optional list of semicolon-separated (;) key=value pairs that describe the security attributes to apply to the object upon execution. The list of valid key words depends on the policy enforced. The following key words are valid: euid, uid, egid, and gid. Zero or more keys can be specified depending on the desired result.

The commands euid and uid contain a single user name or a numeric user ID. Commands designated with euid run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands designated with uid run with both the real and effective UIDs. Setting uid might be more appropriate than setting the euid on privileged shell scripts.

The commands egid and gid contain a single group name or a numeric group ID. Commands designated with egid run with the effective GID indicated, which is similar to setting the setgid bit on a file. Commands designated with gid run with both the real and effective GIDs. Setting gid may be more appropriate than setting guid on privileged shell scripts. Refer to the man page exec_attr(4) for more details.


The authorization description database describes authorizations or rights that a user assuming a role will obtain. This is a method used by security aware programs, such that they change their behavior based upon the rights of users. If users have the appropriate rights, they are granted the particular restricted behavior. The Solaris™ Management Console suite of applications utilizes this functionality extensively. Refer to the man page auth_attr(4) for more details.

RBAC Examples

Setting Up a Shutdown Role

The first example shows the setup for allowing a user called user1 to assume a role called shutter with an execution profile called Shut, which allows user1 to perform the /usr/sbin/shutdown command only. This command ordinarily requires a real UID of 0 to perform this operation.

Here is the execution profile definition:

# grep Shut /etc/security/exec_attr

Here is the execution profile description:

# grep Shut /etc/security/prof_attr 
Shut:::System Shutdown: 

Here are the user and role accounts definition:

# egrep "shutter|user1" /etc/passwd 
# egrep "shutter|user1" /etc/shadow 

Here is the assignment of role shutter to user user1:

# grep shutter /etc/user_attr 


Note: you may have to stop and restart name service cache daemon (nscd) to have this new role take effect.

# /etc/init.d/nscd stop 
# /etc/init.d/nscd start 

Log in to the system as user user1

$ ssh home1 -l user1 
user1@home1's password: 
Last login: Thu Mar 27 20:57:29 2003 from 
Sun Microsystems Inc. SunOS 5.9 Generic May 2002 
$ id 
uid=5555(user1) gid=10(staff) 
$ cat /etc/shadow 
cat: cannot open /etc/shadow 

User user1 does not have sufficient permissions to view the contents of /etc/shadow.

$ /usr/sbin/shutdown 
/usr/sbin/shutdown: Only root can run /usr/sbin/shutdown 

Equally, user1 does not have sufficient permissions to run /usr/bin/shutdown. So try the new role!

$ su - shutter 
$ id 
uid=9999(shutter) gid=10(staff) 
$ cat /etc/shadow 
cat: cannot open /etc/shadow 

Role shutter still does not have permissions to view /etc/shadow even though it was assigned a real and effective UID of 0. Note, however, this permission was granted only for running the /usr/sbin/shutdown command. This is exactly as defined in the configuration files, honoring the concept of least privilege. Now let's try the shut down and see if it is successful under the new role.

$ /usr/sbin/shutdown 
Shutdown started. Mon Mar 31 23:05:38 EST 2003 
Broadcast Message from root (pts/6) on home1 Mon Mar 31 23:05:39... 
The system home1 will be shut down in 1 minute 

The shutdown continues.

With this simple example you can see how RBAC can provide very specific enhanced capabilities to a role without giving away anything over and above that specific granted permission.

Making root a Role

The next example shows how to set up root to be a role. This eliminates all direct root logins, and forces all users to first log in as themselves before assuming the role of root.

Find the root role in the /etc/user_attr file. By default it will look like the following:

$ grep root /etc/user_attr root::::type=normal;auths=solaris.

Edit the file and change the type from normal to role. Also locate or add the user who should be able to assume the role of root. You should end up with the following:

$ grep root /etc/user_att 

As user user1:

$ roles 

Editing RBAC Databases

The following commands can be used to edit the RBAC databases.


Manage entries in the exec_attr database


Manage bulk operations on user entries


Manage user entries


Manage profiles in the prof_attr and exec_attr databases


Manage roles and users in role accounts


Add new users


Change user files


Change role files


Remove roles


Add new roles


Start the Solaris Management Console

With the knowledge already gained regarding the format of the underlying files used by RBAC, along with some basic system administration skills, these commands can be quickly put to use in scripts, etc., to avoid manual editing of the RBAC databases. Note that smc provides a very nice graphical user interface covering the functionality of RBAC configuration. Also, smc provides a method to invoke many system management tools that adhere to RBAC authorizations.

RBAC and Logging

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


Other methods to achieve the same goal as RBAC have achieved popularity. One such method is a program called Sudo, which is available on the Solaris Software Companion CD. So, the question to answer is why use RBAC if Sudo is so popular and made easily available by Sun Microsystems™? There are several reasons, actually, the first of which is support. Sun Microsystems supports RBAC, but only provides Sudo for your convenience on an AS IS, unsupported basis. This is a distinction worth noting. See the Sudo Freeware Legal Disclaimer in the "References" section of this document for more information. Another reason to prefer RBAC is that it is an integrated part of the OS. Further, RBAC configuration files can be included in the site's naming service such as NIS, NIS+, or LDAP, allowing for simple global management of RBAC roles within an enterprise. Finally, RBAC allows a finer grain control over the real and effective UIDs and GIDs for which a command executes under a role, specifically supporting the least privilege concept.

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