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
(http://www.courtesan.com/sudo/) 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,\
Cmnd_Alias USERADMIN = /usr/sbin/useradd, /usr/sbin/userdel,\
OPERATOR DUMPS, KILL, SHUTDOWN
ADMIN DUMPS, KILL, SHUTDOWN, USERADMIN, PRINT
WEBMASTER (DB) WEBADMIN
DBMASTER (WEB) DBADMIN
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
The Solaris implementation of RBAC is controlled by four configuration
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
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 "DUMPS,KILL,SHUTDOWN,USERADMIN,PRINT" admin
# roleadd -m -P "DUMPS,KILL,SHUTDOWN,USERADMIN,PRINT,SU,SHELL" sadmin
# 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.
[reo@mydesk]$ su sadmin -c shutdown -y -g 0 -i 0
Password: [enter password for sadmin role]
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,
- Eliminate the requirement for roles to be separate user accounts.
- Add the ability to use the user's own password to sign
- 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 -- http://www.sun.com/software/whitepapers/wp-rbac/
Role-Based Access Control -- http://csrc.nist.gov/rbac/
The Solaris Companion: "Role-Based Access Control" by
Peter Baer Galvin. Sys Admin, August 2001. -- http://www.samag.com/documents/s=1147/sam0108p/0108p.htm
Ross Oliver is Chief Maven of the consulting firm Tech Mavens,
Inc. (http://www.tech-mavens.com). His 15 years of UNIX industry
experience includes systems adminstration, software development,
and security. He can be reached by email at: firstname.lastname@example.org.