Cover V11, I13


Using SolarisTM RBAC

Ross Oliver

The UNIX administration model of a single, all-powerful superuser is a troublesome limitation in many network computing environments. Sys admins often need to delegate selected administration tasks without granting unrestricted superuser powers. The sudo utility ( is a longtime favorite for fulfilling this function. However, some organizations prohibit the use of "freeware" software tools, especially for such a critical security function. For Solaris sys admins who find themselves in this situation, there is now an alternative.

Role-Based Access Control (RBAC) was introduced in Solaris 8. Adopted from Sun's Trusted Solaris offering, RBAC has its roots in military and government computing systems where operations are more tightly controlled than in a typical commercial UNIX environment. Like sudo, RBAC allows sys admins the flexibility to grant users superuser privileges on a per-command basis.

To show how RBAC can be used as a substitute for sudo, I will begin with an example sudoers file, then replicate the same configuration using RBAC. Here is the example sudoers file:

User_Alias    SENIORADMIN = reo, tmiller, jbuffet
User_Alias    ADMIN = jkim, sfox, dmarch
User_Alias    OPERATOR = agrove, bgates, smcnealy
User_Alias    WEBMASTER = crobin, elim
User_Alias    DBMASTER = lellison,

Runas_Alias   OP = root, bin
Runas_Alias   DB = dbadmin, db
Runas_Alias   WEB = webadmin, web

Cmnd_Alias     DUMPS = /usr/bin/mt, /usr/sbin/ufsdump, /usr/sbin/ufsrestore
Cmnd_Alias    KILL = /usr/bin/kill
Cmnd_Alias    PRINT = /usr/sbin/lpadmin, /usr/bin/lpsched,\
Cmnd_Alias    SHUTDOWN = /usr/sbin/shutdown, /usr/sbin/halt,\
Cmnd_Alias    SU = /usr/bin/su
Cmnd_Alias    SHELL = /usr/bin/su
Cmnd_Alias    WEBADMIN = /usr/local/bin/httpd
Cmnd_Alias    DBADMIN = /usr/local/bin/dbstart, /usr/local/bin/dbstop,\
                    /usr/local/bin/dbdump, /usr/local/bin/dbload
Cmnd_Alias    USERADMIN = /usr/sbin/useradd, /usr/sbin/userdel,\

Note that there are no Host_alias entries or references to specific hosts. The Solaris implementation of RBAC is very mainframe-centric in that it does not provide for limiting actions based on host name. In this sense, the current implementation is not well suited to network computing environments.

The Solaris implementation of RBAC is controlled by four configuration files:

Sun apparently intended the Solaris Management Console GUI to be the primary method of managing RBAC. Several fields and attributes in the configuration files exist solely to provide information to the SMC. There are also command-line tools for manipulating the RBAC config files, but neither the GUI nor the command-line tools provide a method for adding, removing, or modifying the actual OS-level commands that users are allowed to execute. Therefore, configuring RBAC for anything but the most trivial applications requires editing the configuration files directly.

The first step in replicating the sample sudo configuration is populating the /etc/security/exec_attr file with the desired commands. Similar to Cmnd_alias entries in sudoers file, entries in the exec_attr file link individual Solaris commands with symbolic names, called "profiles":








Note that fields 2 and 3 must contain suser and cmd, respectively. Fields 4 and 5 are reserved and must be empty. Profile names are case-sensitive, and may contain spaces. The euid and egid parameters are optional, specifying the effective user and group IDs to use when executing the command.

Neither the profile attributes file, /etc/security/prof_attr, nor the authorization attributes file, /etc/security/auth_attr, affects the actual operation of RBAC. These files contain information used by the Solaris Management Console, such as help file names and longer descriptions of the profiles and authorization attributes. If you do not plan to use the GUI, you do not need to modify either of these files.

After defining the profiles and associated commands, the next step is to define the roles. A role consists of two elements: an actual Solaris user account, and a role entry in the /etc/user_attr file. Use the roleadd utility to create both elements in a single step:

# roleadd -m -P "DUMPS,KILL,SHUTDOWN" oper
# roleadd -m -P "WEBADMIN" webmastr
# roleadd -m -P "DBADMIN" dbmastr
Role accounts must have home directories that exist (hence the -m option, having the same meaning as useradd). You can assign separate passwords to role accounts.

Finally, use the -R option of useradd to associate the roles with specific user accounts:

# usermod -R "sadmin" reo
# usermod -R "oper" bgates
# usermod -R "dbmastr" lellison
After all the RBAC elements have been configured, holders of real user accounts can access their roles using the su utility. For example:

[reo@mydesk]$ su sadmin -c shutdown -y -g 0 -i 0
Password: [enter password for sadmin role]
    [shutdown begins]
Even if the password for the role account is null, you will still be prompted for one. If you need to run multiple commands, omit the -c option to get a shell prompt:

[reo@mydesk]$ su sadmin
Password: [enter password for sadmin role]
The pfsh shell used for role accounts checks each command against those listed in /etc/security/exec_attr for the current role. Matching commands are executed under the user and group ID given in that file. Commands that are not found in exec_attr or that do not have a user or group ID specified are executed under the user and group ID of the role account.

If you plan to use RBAC, you should become familiar with the new Solaris 8 utilities related to RBAC:

roleadd, rolemod, roledel: Create, modify, and delete roles and role accounts. Since roles are implemented as user accounts, these utilities share many options in common with useradd, usermod, and userdel.

roles: List roles associated with a user account.

profiles: List profiles and individual commands associated with a role or user account.

There are online manual entries for each new utility, as well as for the RBAC configuration files.

Solaris RBAC can be an adequate substitute for sudo in situations where sudo is not permitted or available. However, sudo is simpler to configure, does not require the creation of role accounts and role passwords, and includes a syntax checker for its configuration file. One advantage of RBAC over sudo is RBAC's ability to be centrally managed via NIS or NIS+.

Sun's implementation of RBAC will no doubt continue to evolve. Some specific enhancements I would like to see are:

  • Add syntax and semantics checkers for configuration files, especially /etc/security/exec_attr.
  • Eliminate the requirement for roles to be separate user accounts.
  • Add the ability to use the user's own password to sign into roles.
  • Add the ability to limit commands by host name.
  • Provide a sudoers file import/export utility.

For more information about RBAC, see the following:

RBAC in the Solaris Operating Environment --

Role-Based Access Control --

The Solaris Companion: "Role-Based Access Control" by Peter Baer Galvin. Sys Admin, August 2001. --

Ross Oliver is Chief Maven of the consulting firm Tech Mavens, Inc. ( His 15 years of UNIX industry experience includes systems adminstration, software development, and security. He can be reached by email at: