Role-Based Access Control (Overview)
Role-based access control (RBAC) is a security feature for controlling user access to
tasks that would normally be restricted to superuser. By applying security attributes to
processes and to users, RBAC can divide up superuser capabilities among several administrators.
Process rights management is implemented through privileges. User rights management is implemented through RBAC.
RBAC: An Alternative to the Superuser Model
In conventional UNIX systems, the root user, also referred to as superuser, is
all-powerful. Programs that run as root, or setuid programs, are all-powerful. The root
user has the ability to read and write to any file, run all
programs, and send kill signals to any process. Effectively, anyone who can become
superuser can modify a site's firewall, alter the audit trail, read confidential records, and
shut down the entire network. A setuid program that is hijacked can do
anything on the system.
Role-based access control (RBAC) provides a more secure alternative to the all-or-nothing superuser
model. With RBAC, you can enforce security policy at a more fine-grained level.
RBAC uses the security principle of least privilege. Least privilege means that a
user has precisely the amount of privilege that is necessary to perform a
job. Ordinary users have enough privilege to use their applications, check the status
of their jobs, print files, create new files, and so on. Capabilities beyond
ordinary user capabilities are grouped into rights profiles. Users who are expected to do
jobs that require some of the capabilities of superuser assume a role that
includes the appropriate rights profile.
RBAC collects superuser capabilities into rights profiles. These rights profiles are assigned to special
user accounts that are called roles. A user can then assume a
role to do a job that requires some of superuser's capabilities. Predefined rights
profiles are supplied with Solaris software. You create the roles and assign the
profiles.
Rights profiles can provide broad capabilities. For example, the Primary Administrator rights profile
is equivalent to superuser. Rights profiles can also be narrowly defined. For example,
the Cron Management rights profile manages at and cron jobs. When you create roles,
you can decide to create roles with broad capabilities, or roles with narrow
capabilities, or both.
In the RBAC model, superuser creates one or more roles. The roles
are based on rights profiles. Superuser then assigns the roles to users who
are trusted to perform the tasks of the role. Users log in with
their user name. After login, users assume roles that can run restricted administrative
commands and graphical user interface (GUI) tools.
The flexibility in setting up roles enables a variety of security policies. Although
no roles are shipped with the Solaris Operating System (Solaris OS), three
recommended roles can easily be configured. The roles are based on rights profiles
of the same name:
Primary Administrator – A powerful role that is equivalent to the root user, or superuser.
System Administrator – A less powerful role for administration that is not related to security. This role can manage file systems, mail, and software installation. However, this role cannot set passwords.
Operator – A junior administrator role for operations such as backups and printer management.
These three roles do not have to be implemented. Roles are a
function of an organization's security needs. Roles can be set up for special-purpose administrators
in areas such as security, networking, or firewall administration. Another strategy is to
create a single powerful administrator role along with an advanced user role. The
advanced user role would be for users who are permitted to fix portions
of their own systems.
The superuser model and the RBAC model can co-exist. The following table summarizes
the gradations from superuser to restricted ordinary user that are possible in the
RBAC model. The table includes the administrative actions that can be tracked in
both models. For a summary of the effect of privileges alone on a
system, see Table 8-2.
Table 8-1 Superuser Model Versus RBAC With Privileges Model
User Capabilities on a System |
Superuser Model |
RBAC Model |
|---|
Can become superuser with
full superuser capability |
Yes |
Yes |
Can log in as a user with full user capabilities |
Yes |
Yes |
Can
become superuser with limited capabilities |
No |
Yes |
Can log in as a user, and have
superuser capabilities, sporadically |
Yes, with setuid programs only |
Yes, with setuid programs and with
RBAC |
Can log in as a user with administrative capabilities, but without full superuser
capability |
No |
Yes, with RBAC and with directly-assigned privileges and authorizations |
Can log in as
a user with fewer capabilities than an ordinary user |
No |
Yes, with RBAC and
with removed privileges |
Can track superuser actions |
Yes, by auditing the su command |
Yes, by
auditing profile shell commands Also, if root user is disabled, the name of
the user who has assumed the root role is in the audit trail |
Solaris RBAC Elements and Basic Concepts
The RBAC model in the Solaris OS introduces the following elements:
Authorization – A permission that enables a user or role to perform a class of actions that could affect security. For example, security policy at installation gives ordinary users the solaris.device.cdrw authorization. This authorization enables users to read and write to a CD-ROM device. For a list of authorizations, see the /etc/security/auth_attr file.
Privilege – A discrete right that can be granted to a command, a user, a role, or a system. Privileges enable a process to succeed. For example, the proc_exec privilege allows a process to call execve(). Ordinary users have basic privileges. To see your basic privileges, run the ppriv -vl basic command.
Security attributes – An attribute that enables a process to perform an operation. In a typical UNIX environment, a security attribute enables a process to perform an operation that is otherwise forbidden to ordinary users. For example, setuid and setgid programs have security attributes. In the RBAC model, operations that ordinary users perform might require security attributes. In addition to setuid and setgid programs, authorizations and privileges are also security attributes in the RBAC model. For example, a user with the solaris.device.allocate authorization can allocate a device for exclusive use. A process with the sys_time privilege can manipulate system time.
Privileged application – An application or command that can override system controls by checking for security attributes. In a typical UNIX environment and in the RBAC model, programs that use setuid and setgid are privileged applications. In the RBAC model, programs that require privileges or authorizations to succeed are also privileged applications. For more information, see Privileged Applications and RBAC.
Rights profile – A collection of administrative capabilities that can be assigned to a role or to a user. A rights profile can consist of authorizations, of commands with security attributes, and of other rights profiles. Rights profiles offer a convenient way to group security attributes.
Role – A special identity for running privileged applications. The special identity can be assumed by assigned users only. In a system that is run by roles, superuser is unnecessary. Superuser capabilities are distributed to different roles. For example, in a two-role system, security tasks would be handled by a security role. The second role would handle system administration tasks that are not security-related. Roles can be more fine-grained. For example, a system could include separate administrative roles for handling the cryptographic framework, printers, system time, file systems, and auditing.
The following figure shows how the RBAC elements work together.
Figure 8-1 Solaris RBAC Element Relationships
In RBAC, roles are assigned to users. When a user assumes a
role, the capabilities of the role are available. Roles get their capabilities from rights
profiles. Rights profiles can contain authorizations, privileged commands, and other supplementary rights profiles.
Privileged commands are commands that execute with security attributes.
The following figure uses the Operator role, the Operator rights profile, and the
Printer Management rights profile to demonstrate RBAC relationships.
Figure 8-2 Example of Solaris RBAC Element Relationships
The Operator role is used to maintain printers and to perform media backup.
The role is assigned to the user jdoe. jdoe can assume the role
by switching to the role, and then supplying the role password.
The Operator rights profile has been assigned to the Operator role. The Operator
rights profile contains two supplementary profiles, Printer Management and Media Backup. The supplementary
profiles reflect the role's primary tasks.
The Printer Management rights profile is for managing printers, print daemons, and spoolers.
Three authorizations are included in the Printer Management rights profile: solaris.admin.printer.read, solaris.admin.printer.delete, and
solaris.admin.printer.modify. These authorizations enable roles and users to manipulate information in the printer
queue. The Printer Management rights profile also includes a number of commands with
security attributes, such as /usr/sbin/lpshut with euid=lp and /usr/ucb/lpq with euid=0.
RBAC Authorizations
An authorization is a discrete right that can be granted to a role
or to a user. Authorizations enforce policy at the user application level. Authorizations
can be assigned directly to a role or to a user. Typically, authorizations
are included in a rights profile. The rights profile is then included in
a role, and the role is assigned to a user. For an example,
see Figure 8-2.
RBAC-compliant applications can check a user's authorizations prior to granting access to the
application or specific operations within the application. This check replaces the check in
conventional UNIX applications for UID=0. For more information on authorizations, see the
following sections:
Authorizations and Privileges
Privileges enforce security policy in the kernel. The difference between authorizations and privileges
concerns the level at which the security policy is enforced. Without the proper
privilege, a process can be prevented from performing privileged operations by the kernel.
Without the proper authorizations, a user might be prevented from using a privileged
application or from performing security-sensitive operations within a privileged application. For a fuller discussion
of privileges, see Privileges (Overview).
Privileged Applications and RBAC
Applications and commands that can override system controls are considered privileged applications. Security
attributes such as UID=0, privileges, and authorizations make an application privileged.
Applications That Check UIDs and GIDs
Privileged applications that check for root (UID=0) or some other special UID
or GID have long existed in the UNIX environment. The rights profile
mechanism enables you to isolate commands that require a specific ID. Instead of
changing the ID on a command that anyone can access, you can place
the command with execution security attributes in a rights profile. A user or
role with that rights profile can then run the program without having to
become superuser.
IDs can be specified as real or effective. Assigning effective IDs is preferred
over assigning real IDs. Effective IDs are equivalent to the setuid feature in
the file permission bits. Effective IDs also identify the UID for auditing. However,
because some shell scripts and programs require a real UID of root, real UIDs
can be set as well. For example, the pkgadd command requires a real
rather than an effective UID. If an effective ID is not sufficient to
run a command, you need to change the ID to a real
ID. For the procedure, see How to Create or Change a Rights Profile.
Applications That Check for Privileges
Privileged applications can check for the use of privileges. The RBAC rights profile mechanism
enables you to specify the privileges for specific commands. Instead of requiring superuser
capabilities to use an application or command, you can isolate the command with
execution security attributes in a rights profile. A user or role with that
rights profile can then run the command with just the privileges that the
command requires to succeed.
Commands that check for privileges include the following:
Kerberos commands, such as kadmin, kprop, and kdb5_util
Network commands, such as ifconfig, routeadm, and snoop
File and file system commands, such as chmod, chgrp, and mount
Commands that control processes, such as kill, pcred, and rcapadm
To add commands with privileges to a rights profile, see How to Create or Change a Rights Profile. To determine
what commands check for privileges in a particular profile, see Determining Your Assigned Privileges.
Applications That Check Authorizations
The Solaris OS additionally provides commands that check authorizations. By definition, the root
user has all authorizations. Therefore, the root user can run any application. Applications that
check for authorizations include the following:
The entire Solaris Management Console suite of tools
Audit administration commands, such as auditconfig and auditreduce
Printer administration commands, such as lpadmin and lpfilter
The batch job-related commands, such as at, atq, batch, and crontab
Device-oriented commands, such as allocate, deallocate, list_devices, and cdrw.
To test a script or program for authorizations, see Example 9-25. To write
a program that requires authorizations, see About Authorizations in Solaris Security for Developers Guide.
RBAC Rights Profiles
A rights profile is a collection of system overrides that can be assigned to
a role or user. A rights profile can include authorizations, commands with assigned
security attributes, and other rights profiles. Rights profile information is split between the
prof_attr and exec_attr databases. The rights profile name and authorizations are in the
prof_attr database. The rights profile name and the commands with assigned security attributes
are in the exec_attr database.
For more information on rights profiles, see the following sections:
RBAC Roles
A role is a special type of user account from which you can
run privileged applications. Roles are created in the same general manner as user
accounts. Roles have a home directory, a group assignment, a password, and so
on. Rights profiles and authorizations give the role administrative capabilities. Roles cannot inherit
capabilities from other roles or other users. Discrete roles parcel out superuser capabilities,
and thus enable more secure administrative practices.
When a user assumes a role, the role's attributes replace all user
attributes. Role information is stored in the passwd, shadow, and user_attr databases. Role information
can be added to the audit_user database. For detailed information on setting up roles,
see the following sections:
A role can be assigned to more than one user. All users
who can assume the same role have the same role home directory, operate
in the same environment, and have access to the same files. Users can
assume roles from the command line by running the su command and supplying
the role name and password. Users can also assume a role in the
Solaris Management Console tool.
A role cannot log in directly. A user logs in, and then assumes
a role. Having assumed a role, the user cannot assume another role without
first exiting their current role. Having exited the role, the user can then
assume another role.
You can prevent anonymous root login by changing the root user into a
role, as shown in How to Make root User Into a Role. If the profile shell command, pfexec,
is being audited, the audit trail contains the login user's real UID, the
roles that the user has assumed, and the actions that the role performed.
To audit the system or a particular user for role operations, see How to Audit Roles.
No predefined roles are shipped with Solaris software. However, the rights profiles that
ship with the software are designed to map to roles. For example, the
Primary Administrator rights profile can be used to create the Primary Administrator role.
Profile Shell in RBAC
Roles can run privileged applications from the Solaris Management Console launcher or from
a profile shell. A profile shell is a special shell that recognizes the security
attributes that are included in a rights profile. Profile shells are launched when
the user runs the su command to assume a role. The profile
shells are pfsh, pfcsh, and pfksh. The shells correspond to Bourne shell
(sh), C shell (csh), and Korn shell (ksh), respectively.
Users who have been directly assigned a rights profile must invoke a profile
shell to run the commands with security attributes. For usability and security considerations,
see Security Considerations When Directly Assigning Security Attributes.
All commands that are executed in a profile shell can be audited.
For more information, see How to Audit Roles.
Name Service Scope and RBAC
Name service scope is an important concept for understanding RBAC. The scope of
a role might be limited to an individual host. Alternatively, the scope might
include all hosts that are served by a name service such as NIS,
NIS+, or LDAP. The name service scope for a system is specified
in the file /etc/nsswitch.conf. A lookup stops at the first match. For example, if
a rights profile exists in two name service scopes, only the entries in
the first name service scope are used. If files is the first match,
then the scope of the role is limited to the local host.
Security Considerations When Directly Assigning Security Attributes
Typically, a user obtains administrative capabilities through a role. Authorizations and privileged commands
are grouped into a rights profile. The rights profile is included in a
role, and the role is assigned to a user.
Direct assignment of rights profiles and security attributes is also possible:
Rights profiles, privileges, and authorizations can be assigned directly to users.
Privileges and authorizations can be assigned directly to roles.
However, direct assignment is not a secure practice. Users and roles with a
directly assigned privilege could override security policy wherever this privilege is required by
the kernel. When a privilege is a security attribute of a command in
a rights profile, that privilege is available only for that command by
someone who has that rights profile. The privilege is not available for other
commands that the user or role might run.
Since authorizations act at the user level, direct assignment of authorizations can be
less dangerous than direct assignment of privileges. However, authorizations can enable a user
to perform highly secure tasks, such as delegate device administration.
A rights profile that is assigned directly to a user presents usability problems
more than security problems. The commands with security attributes in the rights profile
can only succeed in a profile shell. The user must open a profile
shell, then type the commands. A role that is assigned a rights profile
gets a profile shell automatically. Therefore, the commands succeed in the role's shell.
Rights profiles provide an extensible, clean way to group security characteristics for particular
administrative tasks.
