Peter Baer Galvin
Content Level: Intermediate
Content Audience: Solaris Administrators and Managers
UNIX administrators have been wanting more fine-grained access control to administrative
features almost since the first administrator accidentally destroyed his first
system. As of Solaris 8, Sun has delivered a solution to that problem. But is
the solution for you?
The Current State
The UNIX concept of a "superuser" who could do all is a good one. It allows
one or more users to gain access to all system facilities, for monitoring and
management. It makes debugging and correcting system problems (relatively) easy.
In short, it doesn't have a lot of security to get in the way of administration.
It has its failings however, including:
- "All or nothing" - Either you are the superuser or a normal user. Once
a superuser, you have infinite access to all system components. This model
allows bugs in /dev/mouse (this is a true story) to allow a user
to become superuser and gain total access to a machine. This model also makes
it difficult to grant some rights to some users. For example, there is no
ability within standard UNIX to grant operators access to backup and restore
programs but to nothing else.
- Lack of activity logging - The superuser activities are no more logged
or monitored than any other user of the system.
- Lack of accountability - Similarly, it is difficult to determine who has
performed what activities. User-ID "0" is root, and anyone with that ID or
who changes to that ID can perform root operations. While you can create several
accounts with ID's of 0 (not recommended) to create separate privileged accounts
with different passwords, all activities take place as User-ID 0, so file
and directory modifications (for example) are undifferentiable.
Given the state of UNIX access controls, how can junior administrators be given
a subset of the system access of senior ones? How can operators be limited to
only backup and restore operations? How can users be empowered to change only
small portions of the system to suit their needs?
The need for superuser management is exacerbated as the number of users of
UNIX systems grows, the number of services and features increases, and the need
for security increases. Other operating systems tend to have better security
models than UNIX. For instance, VMS, MVS, and even Windows 2000 have many more
security options and features than older Solaris releases. (Note that having
a better security model does not automatically make an operating system more
Unfortunately, standard UNIX has never had a standard way to assign different
levels of systems administrator access. Each major UNIX implementation has its
own facility. Sun has tried a few methods, most recently Admintool/Adminsuite.
These have met with limited success, as their feature sets are small and security
sometimes lacking. The largest issue has been a lack of standardization. Each
operating system had its own security methodology, so heterogeneous operation
was impossible. Even if an individual operating system could be made more secure,
communication and interoperation with other operating systems could invalidate
that extra security.
There are other choices available to manage systems administrator access control.
The most commonly used is sudo (http://www.courtesan.com/sudo/index.html). Sudo resolves
many of the issues listed above. It allows a given user to execute a set of
commands as root. It also logs each action performed by each sudo user. Sudo
is available as free software under a BSD-style license. But what is the downside?
There are a couple of problems. Sudo is not standard with most commercial UNIX
releases, so you must download it, build it, and install it on each of your
systems. Also, Sudo is an application, rather than an integrated facility. It
can be bypassed via the use of standard su, for example. As a free
product, it also has the usual support and management issues that can affect
the ability of large companies to use it.
There is a new security offering that is starting to change this landscape.
Role-Based Access Control (RBAC) (http://csrc.nist.gov/rbac/)
is a NIST standard that is starting to appear in several operating
systems. Sun's Solaris 8 is one of its first commercial appearances. Given the
importance of a uniform security model for UNIX systems, I'll delve into RBAC
and its functionality on Solaris 8.
Role-Based Access Control
With RBAC, it is possible for administrators to assign limited administrative
capabilities to users. In essence, it allows implementation of the "least privilege"
security principle, bestowing only enough privilege to accomplish a task. The
RBAC functionality is flexible enough that different sites could use it in various
ways to implement their distinct security policies. Furthermore, by enabling
accounting along with RBAC, a full record of administrative user activities
can be created. RBAC implements several new Solaris concepts:
- Authorizations -- user rights that grant access to restricted function profiles,
- Roles -- for grouping authorizations and commands together as a common set
- Profiles -- (also known as "execution profiles" or "rights profiles") for
performing a set of administrative tasks. The administrator creates a profile
containing authorizations and privileged commands for a specific task or set
of tasks. That profile can be assigned directly to a user or to a role.
Roles are assigned to users. Profiles are assigned to roles to define the functionality
of each role. Each profile can have individual commands or authorizations assigned
to it. Some commands directly use authorizations. These include Sun Management
Console (SMC), batch job-related commands, and device allocation commands. For
a user to enable a role, a user can either use the SMC launcher, or use special
versions of the systems shells, known as "profile shells": pfsh, pfcsh,
and pfksh. There is also pfexec, which is
used to execute a single RBAC-authorized command. Furthermore, separate accounts
for each role are created in the standard way, and all users of that role can
share the same home directory while in that role. Users can then assume a role
by suing to that account.
There generally are no predefined roles on Solaris. There are, however, three
predefined profiles that could be enabled readily: "Primary Administrator",
"System Administrator", and "Operator". To implement this functionality, there
are several new system files.
In short, this is a complicated new facility, with configuration files containing
complex sets of fields. These configuration files can be part of NIS, NIS+, or
LDAP name services, or just kept locally on individual servers. In fact, there
is a separate command, smattrpop, which can merge entries from one
attribute database into a specified naming service. These files can be edited
manually, or several separate commands can be used to manage the information in
- /etc/user_attr stores extended security attributes related
to users and roles.
- /etc/security/auth_attr lists and describes authorizations.
- /etc/security/prof_attr lists execution profiles and associated
- /etc/security/exec_attr associates execution attributes with
- /etc/security/policy.conf provides the security policy configuration
for user-level attributes.
Perhaps the best way to get started with RBAC is via the Sun Management Console.
That will be the topic of next month's column. Meanwhile, the following tour should
help you get acquainted with the RBAC files and RBAC's features and functionality.
By default, the /etc/user_attr file has this content:
- smexec - manage exec_attr
- smmultiuser - manage bulk operations on user accounts
- smuser - manage user entries
- smprofile - manage profiles in prof_attr and exec_attr
- smrole - manage roles and users in role accounts
- rolemod, roledel, roleadd - perform operations on roles
# Copyright (c) 1999 by Sun Microsystems, Inc. All rights reserved.
# user attributes. see user_attr(4)
#pragma ident "@(#)user_attr 1.2 99/07/14 SMI"
The one entry describes user "root", and authorizes access to all Solaris services
("solaris.*,solaris.grant") in all profiles. The authorizations are contained
in /etc/security/auth_attr. On my experimental system (running Solaris
8 release 7/01), this file contains 76 lines. Here are the first few lines:
solaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.html
solaris.admin.logsvc.write:::Manage Log Settings::help=AuthLogsvcWrite.html
solaris.admin.logsvc.purge:::Remove Log Files::help=AuthLogsvcPurge.html
solaris.admin.logsvc.read:::View Log Files::help=AuthLogsvcRead.html
solaris.admin.fsmgr.:::Mounts and Shares::
solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html
solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html
solaris.admin.serialmgr.:::Serial Port Manager::
Thus, root has access to all of the lines that start with "solaris" (i.e., all
of them). Another user could be configured to have access to "solaris.admin.usermgr",
if her only activity was managing users. But what actual commands are available
for that user? For that, we need to refer to two files. First, we look in /etc/security/prof_attr
to determine which profile includes those authorizations:
# grep usermgr prof_attr
Basic Solaris User:::Automatically assigned rights:\
User Management:::Manage users, groups, home directory:\
User Security:::Manage passwords, clearances:\
(Continuation lines added for readability.)
It is relatively clear from this output that "Basic Solaris User" members have
access to a wide variety of authorizations, and that "User Management" profile
users have access to some and "User Security" profile users have access to all
of those authorizations. Now that we know the profile names, we can determine
the commands associated with them, in /etc/security/exec_attr:
# grep "User Management" exec_attr
There are three commands available to the "User Management" policy. The first
checks /etc/group for consistency; the second does the same for
/etc/passwd. The third is actually a system startup script to start
and stop the utmpd daemon, which monitors the utmp
and utmpx files. These files contain information on active system
users. Note that all three of these commands get run as user ID 0 (i.e., root).
You would expect to see many more commands in exec_attr. A real
"user manager" should at least have access to the user* and group*
commands. These provide a command-line method for modifying passwd
and group entries. Without these commands, a "user manager" cannot
do much in the way of user management. I can find no documented reason why the
list in exec_attr is so short. Do these other commands provide
too much functionality, or shell escapes, making them too powerful to put into
small categories like user management?
Of course, that is going to be the problem with the RBAC service, and truly
with any service that relies on current commands to provide their secure functionality.
These commands never thought that they would be run by multiple types of users,
and were not designed with that fine-grain access control model. Perhaps Sun
is planning on creating new command-line equivalents that provide just the functionality
desired. Or perhaps they will modify the current ones. The answer at this point
There is an even more concerning aspect to RBAC. In essence, it allows current
systems administrators to grant access to previously root-only aspects of the
system, in a semi-permanent fashion. Without great care in definition and assignment,
systems administrators might give out more than they expected with RBAC. Determining
just what a user in a role can perform is currently a challenge. Hopefully,
more tools will be provided in the future to diminish these issues.
A perusal of the update manuals that come with each Solaris release reveal
that RBAC is a rapidly evolving service. Presumably, these changes will continue,
with the eventual result of a useful and usable new feature of Solaris 8. Until
that time, RBAC is best left for experimental rather than production use. For
more information, there is an interesting RBAC white paper
(http://www.sun.com/software/whitepapers/wp-rbac/) describing RBAC in the Solaris environment. (There are some oddities
in this paper, however. For example, it says that currently no additions are
allowed to auth_attr. This is a normal text file, however, and
no information is given on how changes are prevented.) For further reading,
you might want to check out a SunManagers Mailing List Posting
(http://www.sunmanagers.org/pipermail/sunmanagers/2000-December/000581.html) by Konstantin Rozinov, which describes the steps he
used to enable the use of snoop by non-root users.
Next month, I'll explore the Sun Management Console facility, an extensive
(and free) management environment that comes with Solaris, but is little used
in the field.
Peter Baer Galvin (http://www.petergalvin.org)
is the Chief Technologist for Corporate
Technologies, a premier systems integrator and VAR. Before that, Peter was
the systems manager for Brown University's Computer Science Department. He has
written articles for Byte and other magazines, and previously wrote Pete's Wicked
World, the security column, and Pete's Super Systems, the systems management
column for Unix Insider (http://www.unixinsider.com).
Peter is coauthor of the Operating Systems Concepts and Applied
Operating Systems Concepts textbooks. As a consultant and trainer, Peter
has taught tutorials and given talks on security and system administration worldwide.