RBAC (7)

Name

rbac, RBAC - role-based access control

Description

Role-based access control allows system administrators to delegate
the administrative control of parts of the system to users. Users
can be given the ability to run commands with additional privileges
in two ways:

by assigning a profile directly to the user, in which
case no additional authentication is required

by creating a role and assigning the profiles to the
role. It can also be used to build restrictive environments for users
by removing their ability to run commands they would normally be allowed
to run.

Profiles

Profiles are named collections of commands and authorizations that are run with additional
privilege and/or a specific real and effective UID and GID. For example, most of the
printer system can be managed by having the lp commands run with
the UID or lp. Some commands need privileges as defined in privileges(7) to run. For example, the “Process
Management” profile allows a user to run the kill command
with the proc_owner privilege so that it can send signals to
processes it does not own.

See exec_attr(5) and prof_attr(5) for information about
how the administrator can extend the system-provided profiles and
create their own. Profile configuration can be stored in any of the
currently supported name services (files, NIS, LDAP).

Profiles can also be used with the Service Management Facility (SMF) to control the privileges
and UID/GID with which a service runs. See smf_security(7) for more information.

Roles

A role is a special shared account that cannot directly login
to the system that can only be accessed by authorized users with the su(8) command
or over the network with ssh(1) when using host-based
authentication or GSS-API authentication. It can not login with rlogin(1), telnet(1), or gdm.

A role has a UID, a password, and a home directory just like
a normal user. Authentication to the role can be either with the user's
own password or with the per-role password (the roleauth keyword
in user_attr(5) controls that behavior on a per-role basis).
Usually a role's login shell is one of the profile shells (pfsh(1), pfksh(1), pfcsh(1)) that are granted one or more Profiles, allowing
the role to always execute commands with privilege.

A role is normally needed only if a shared account environment
is required. Usually assigning profiles directly to the user is sufficient.

The root user can be configured to be a role using the usermod(8) command. This ensures that only authorized
users can become root even when the root password is more widely known.

# usermod -K type=role root

Making root a role does not restrict access to single user mode.
The system console should be protected using other means, such as
setting a security password with eeprom(8).

Authorizations

An authorization is a unique string that represents a user's
right to perform some operation or class of operations. Authorizations
are normally only checked by programs that always run with some privilege,
for example the setuid(2) programs such as cdrw(1) or the system cron(8) daemon.

Authorization definitions are stored in the auth_attr(5) database.
For programming authorization checks, only the authorization name
is significant.

Authorization name strings ending with the grant suffix
are special authorizations that give a user the ability to delegate
authorizations with the same prefix and functional area to other users.

All authorization names starting with solaris are
reserved for allocation by the operating system vendor. Developers
and administrators may create their own top level namespace; use of
a unique identifier such as the company name, DNS domain name, or
application name is suggested.

Authorization Checks

To check authorizations from C code, developers should use the chkauthattr(3C) library function, which verifies whether or
not a user has a given authorization.

Authorizations can be explicitly checked in shell scripts by
checking the output of the auths(1) utility. For example,

Authorizations are also used by the Service Management Facility (SMF) to control which users
can change the state of a service or reconfigure a service. See smf_security(7) for more information.

Comparison with sudo(8)

RBAC in Solaris provides a similar set of functionality to
sudo(8)
that is often provided with UNIX or UNIX-like systems.
It is provided on the Companion CD for Solaris.

One of the most obvious differences between Solaris RBAC and
sudo is the authentication model. In sudo,
users reauthenticate as themselves. In Solaris RBAC, either no additional
authentication is needed (when profiles are assigned directly to the
user) or the user authenticates to a shared account called a role.

Using the NOPASSWD functionality in sudo
is similar to assigning the profile to the user and having
the user execute the command using pfexec(1). For example, if
sudoers(5)
allows the user to run kill(1) as UID 0 but without
authentication (NOPASSWD), the user would run:

$ sudo kill -HUP 1235

In Solaris RBAC, if the user has a normal (that is, no profile)
login shell, the user would execute the equivalent operation by being
assigned the “Process Management” profile and would use
pfexec as follows:

$ pfexec kill -HUP 1235

If the user has a profile shell (such as pfsh)
as the login shell, then kill will always run with
the additional privilege without the need of a “prefix”.
For example,

$ kill -HUP 1235

An RBAC role is similar in concept to the User_Alias in
sudoers(5)
, except that the role password rather than the user
password is required.

Execution profiles exec_attr(5) entries) in RBAC are
similar to the Cmnd_Alias in sudoers.

There is currently no equivalent of the Host_Alias
sudo(8) functionality in Solaris RBAC.