 SolarisTM
10 Privileges
Peter Baer Galvin
Since the beginning of Unix time, system privileges have been
binary. Either you had the superuser rights by running a setuid-root
program or su'ing to root, or you were nobody (that is, an average
user). This model caused great problems for users and systems administrators
alike. Users had to fight to gain access to system resources and
commands that they would find useful. Systems administrators had
to fight to defend the system from exploitation of bugs that would
give root access to crackers. With Solaris 10 privileges, there
are now 47 different privileges that can be assigned to programs,
to users, and to roles. Welcome to the brave, new, and much more
secure world of Solaris 10.
Overview
There is a long-standing rule of security called "least privilege".
It states that only the minimum privileges needed to perform a task
should be available to someone performing that task. In this way,
collateral damage from performing that task, or attempting to perform
others, is minimized. For example, if an operator needs only to
administer backups, then she should have only the privileges necessary
to perform that task. She should not have the ability to manage
users, administer security, or create new setuid-root programs.
With those limits imposed, the damage from mistakes is minimized.
Also, someone else gaining access to that account is limited in
the same way.
In the traditional superuser model of Unix, the user would need
to run programs that were setuid root or be the superuser to perform
any of these tasks. In fairness to previous versions of Solaris
and Unix in general, there is the group function as well. A program
could be set-group-id sysadmin, for example, if that provided the
access to devices and files that it needed. Still, though, three
levels of privilege are not very many.
With the superuser and setuid basis for Unix, the security problems
are legion. As root, the user is allowed to do anything, so the
risks are obvious. With setuid-root programs, any bug in the program
could potentially be exploited to give broader access. For example,
a root shell might be spawned, eliminating whatever limits the setuid-root
program attempted to put on its functionality. Likewise, network
daemons running as root (as many needed to do before Solaris 10),
can have bugs that are exploited by remote users, with disastrous
security results.
Attempts have been made to provide a more flexible security model
to Unix. The most common and effective one is sudo, a setuid-root
program that users execute to run specifically allowed commands.
It is a very useful program, available from:
http://www.courtesan.com/sudo/
It includes full configuration and logging functionality. Unfortunately,
it also has some security limits. A bug in sudo can once again result
in system exploits, for example. A misconfiguration (e.g., letting
a user run a shell as a privileged user) can have dire consequences.
The pros and cons of downloading and installing a privileged program
over the Internet can also be debated.
The Solaris privilege model creates a new level of management
of rights within a Solaris 10 system. Fundamentally, there are new
fine-grained privileges that can be assigned to entities. The kernel
enforces the new requirement that, to perform a special function,
the entity must have the privilege to do so. Further, it can work
in parallel with traditional superuser functionality for backward
compatibility. In the remainder of this column, I discuss how this
new feature works and how to use it.
RBAC and Privileges
Solaris 10 privileges are integrated with the role-based access
control (RBAC) tools that have been included with Solaris since
release 8. Unfortunately, RBAC in Solaris 8 was limited in its features
in functions. Fortunately, Sun has continued to work on RBAC and
with Solaris 10 it is a welcome and usable tool, if a bit complex.
RBAC has previously appeared in the Solaris Corner (http://www.samag.com/documents/s=1147/sam0108p/0108p.htm),
but a quick review is useful now to set the stage for Solaris 10
privileges.
To understand the RBAC way of doing things, here is some new terminology:
- Administrative Roles (or just "roles") -- Roles are for grouping
authorizations and commands together as a common set of functions.
Think of these as special user accounts to which profiles are
assigned.
- Profiles -- These are also known as "execution profiles" or
"rights profiles". They are a collection of authorizations, commands,
and other profiles that together provide for performing a set
of administrative tasks.
- Authorizations -- Permissions that grant access to restricted
actions that are otherwise prohibited by the security policy.
These are typically assigned in a profile but can also be assigned
to a user or a role. Think of these as tokens that can be checked
by RBAC-aware programs. Rather than checking whether UID=0 to
allow an action, such programs can check whether, for example,
the user has authorization token "solaris.admin.diskmgr.read".
- Privileged program -- A program with security attributes that
enables special functions depending on a check of user-id, group-id,
privileges, or authorizations. These are setuid or setgid programs
or programs with assigned privileges.
When a user assumes a role, the user is placed in a special profile-understanding
shell. The choices are pfcsh, pfksn, and pfsh. These shells know
how to read through the various config files in /etc/security (and
/etc/user_attr) to determine the rights profiles of the role and
the components of those profiles, and to enforce them. For example,
the profile shell would check whether a specific program was allowed
to be executed before executing it. It would also know which user-id
to use while executing that command. For example, if a role had
the Name Service Security rights profile, then the user would be
allowed by the profile shell to run /usr/bin/nischown with the effective
user-id of 0 (from /etc/security/exec_attr).
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 (which is
the preferred method). Without appropriate authorizations, a user
is prevented from executing a privileged application or prevented
from performing operations within a privileged application. The
interactions of RBAC's components are depicted in Figure 1.
Strangely, for Solaris at least, the easiest way to deal with
RBAC is to use the Solaris Management Console (smc). After the slow
initial start, it becomes quite a usable tool. Selecting "This Computer
-> System Configuration -> Users -> Rights" allows the
creation and management of rights, including allowed and disallowed
commands and authorizations.
Selecting "This Computer -> System Configuration -> Users
-> Administrative Roles" allows the creation and management of
roles, including the selection of allowed rights. You can also select
which users are allowed each role. Note that if you do make changes
to roles, authorizations, and so on, you must restart the nscd daemon
for the changes to take effect immediately. The user must also log
out before the per-user changes take effect. That said, the smc
integration of privileges was not complete as of build 60, so I
did not have a chance to test it.
In practice, a user is allowed to assume zero or more roles by
knowing the password of the roles. This is very similar to using
the su command. When the user assumes a role, the capabilities
of the role are available. To assume a role, the user simply logs
in as usual. A list of roles available to that user will be displayed
by the roles command. The user then su's to an available role to
accomplish privileged tasks. There are no default roles, as it is
up to each facility to determine how to assign privileges and to
whom to assign them.
Some typical roles include:
- Primary administrator -- The traditional superuser with all
privileges.
- Systems administrator -- An administrator without security-modification
privileges.
- Operator -- An administrator with a limited, specific set of
privileges.
- Advanced user -- A user with privileges to debug and fix her
own system or programs.
All of the RBAC components so far described can be considered
a very complete (and complicated) way to implement sudo. It is up
to the profile shells to implement RBAC and not to have any bugs
that would allow users to escape from their roles.
Solaris 10 Privileges
To implement a better security model than that provided by sudo,
Solaris 10 adds process rights management in the form of privileges.
Between RBAC and privileges, there is now a full alternative to
the superuser model. The root user can even be made into a role
with full auditing of root's actions.
Privileges are implemented by a new kernel facility in which discrete
privileges can be granted to a program, a user, or an RBAC role.
Without the proper privilege, a process will be denied a privileged
operation by the kernel. These privileges are useful outside of
the profile shells. For example, they can limit the operations of
a daemon to only the kernel features that the daemon needs to use.
Privileges are a great step forward in preventing crackers from
doing what they always want to do -- escalate their access level.
The best way to allow a user to perform a privileged function
is to use RBAC to create a role with that privilege and then allow
the user to assume that role. The list of available privileges is
available in privileges(5), and via the all important ppriv
command (the -lv options). They are divided into categories,
including file, ipc, net, proc, and sys privileges. For example,
to enable users in role "test" to use all of the DTrace features,
the entry for the role in /etc/user_attr can be modified by the
smrole command or manually:
test::::profiles=Process Management;type=role; \
defaultpriv=basic,dtrace_proc,dtrace_user,dtrace_kernel
The user would need to switch to the role "test" to use DTrace.
Alternately, privileges can be directly assigned to users, as
in:
pbg::::type=normal;roles=primary_administrator,test; \
defaultpriv=basic,dtrace_proc,dtrace_user,dtrace_kernel
(Note that user pbg would be able to use DTrace to read all sorts
of interesting things from the kernel, including the I/O performed
by user's shells, so this user must be very trustworthy indeed.)
By default, all non-setuid processes have the "basic" set of privileges
assigned. These privileges allow normal Unix functionality, such
as the creation of files in directories that permit the current
userid to create a file.
The Unix concept of effective user-id is also extended with privileges.
There are four aspects to a process's privilege state:
E -- Effective privilege set. The current set of privileges that
are in effect.
I -- Inheritable privilege set. The set of privileges that a process
can inherit across an exec().
P -- Permitted privilege set. The set of privileges that is available
for use.
L -- Limit privilege set. The outside limit of privileges available
to a process and its children. This is used to shrink the "I" set
when a child is created, for example.
To determine the privilege status of a running process, ppriv
[pid] will return the result. For example, the rpcbind daemon has
been made privilege aware and been assigned a specific, limiting
set of privileges ("!" means "not", as is usual in Unix):
# ppriv 'pgrep rpcbind'
153: /usr/sbin/rpcbind
flags = PRIV_AWARE
E: basic,!file_link_any,net_privaddr,!proc_exec, \
!proc_info,!proc_session,sys_nfs
I: basic,!file_link_any,!proc_exec,!proc_fork, \
!proc_info,!proc_session
P: basic,!file_link_any,net_privaddr,!proc_exec, \
!proc_info,!proc_session,sys_nfs
L: basic,!file_link_any,!proc_exec,!proc_fork, \
!proc_info,!proc_session
To add a privilege to a specific user, carefully, use the usermod
command to add the privilege to the user's default privileges, as
in:
# usermod -K defaultpriv=basic,proc_clock_high_res jdoe
Unfortunately, to be able to assign a specific privilege to a specific
command, the command must be written to be privilege aware. Otherwise,
the privileges are ignored.
Currently, native system programs are becoming privilege aware
and having a limited set of privileges assigned to them. This set
currently includes most setuid-root and network daemons. The net
result of these changes will be the least-privilege principle applied
to the Solaris operating system, which can only help to improve
security. There is an API available with privileges to allow Solaris
programmers to write privilege-aware programs.
The ppriv command can be used on a program that is failing
due to a lack of privilege, to determine exactly which privileges
the program needs to succeed. The appropriate privilege can be assigned
to the program or assigned to a role or user to allow that program
to run properly when the appropriate set of users runs it.
Conclusions
There are many complexities and subtleties involved in RBAC and
privileges. For example, the privilege functionally provides backward
compatibility and has features to avoid privilege escalation. There
is much to explore in the Solaris security model, and in this Solaris
Companion I hope I whet your appetite for exploration of the improved
security model that is coming available over the next few months.
See the Solaris 10 "System Administration Guide: Security Services"
document at http://docs.sun.com for all of the details.
Privileges in Solaris 10 were written by Casper Dik. I thank Casper
for his input in this column. To learn more about the planning and
implementation of privileges, check out his blog at: http://blogs.sun.com/casper/20040722.
In Other News
For those doing battle with network auto-negotiation and Solaris,
there is a new Sun Blueprint available that provides best-practice
information. Check out: http://www.sun.com/blueprints/0704/817-7526.pdf.
Peter Baer Galvin (http://www.petergalvin.info) is the
Chief Technologist for Corporate Technologies (www.cptech.com),
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 systems administration worldwide.
|
