svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
rbac(7)
Standards, Environments, Macros, Character Sets, and miscellany
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:
o by assigning a profile directly to the user, in which case
no additional authentication is required
o 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 hav‐
ing the lp commands run with the UID of lp. Some commands need privi‐
leges 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 admin‐
istrator 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.
Profiles are searched in the order specified in the user's entries in
the user_attr(5) database and policy.conf(5). For each user, there are
two sets of profiles, an authenticated set, and an unauthenticated set.
The user is required to reauthenticate prior to using pfexec(1) to exe‐
cute commands which match an entry in the exec_attr(5) database corre‐
sponding to the authenticated profiles set. If the command is executed
from a terminal, the authentication state is cached for the current
user and tty, subject to the timeout option set for pam_tty_tickets(7)
in the PAM stack /etc/pam.d/pfexec. If there is no current tty, but
there is an active X11 session, the user is prompted to authenticate
through a zenity(1) dialog. This authentication state is cached for the
current user and DISPLAY environment setting.
Processes that have been successfully reauthenticated, including those
that were implicitly authenticated within the timeout value of the
cache, are marked with an additional process flag, PRIV_PFEXEC_AUTH,
which exempts child processes from subsequent reauthentication. Both
the PRIV_PFEXEC and PRIV_PFEXEC_AUTH flags are inherited by child pro‐
cesses unless the real uid is changed.
Commands that match the set of unauthenticated profiles do not require
reauthentication, but have lower precedence than commands in the set of
authenticated profiles. If the same command appears in more than one
profile, the profile shell uses the first matching entry.
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 authenti‐
cation or GSS-API authentication. It can not login with rlogin(1), tel‐
net(1), or gdm(8).
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 (see pfsh(1) for a
list) 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 suffi‐
cient.
The root user can be configured to be a role using the usermod(8) com‐
mand. 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 nor‐
mally only checked by programs that always run with some privilege, for
example setuid(2) programs such as cdrw(1) or the system cron(8) dae‐
mon.
Authorization definitions are stored in the auth_attr(5) database. For
programming authorization checks, only the authorization name is sig‐
nificant.
Some typical values in an auth_attr database are as follows:
solaris.jobs.:::Cron and At Jobs::help=JobHeader.html
solaris.jobs.grant:::Delegate Cron & At \
Administration::help=JobsGrant.html
solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html
solaris.jobs.user:::Cron & At User::help=JobsUser.html
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 alloca‐
tion 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 chkau‐
thattr(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,
for auth in `auths | tr , " "` NOTFOUND ; do
["$auth" = "solaris.date" ] && break # authorization found
done
if [ "$auth" != "solaris.date" ] ; then
echo >&2 "$PROG: ERROR: you are not authorized to set the date"
exit 1
fi
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, including Oracle
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, no additional authentication is needed when unauthen‐
ticated profiles are assigned directly to the user. Authentication may
be needed in Solaris RBAC when executing commands from an authenticated
profile, or when 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 fol‐
lows:
$ 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) functional‐
ity in Solaris RBAC.
SEE ALSO
auths(1), ld.so.1(1), pfexec(1), pfsh(1), profiles(1), roles(1),
auth_attr(5), exec_attr(5), prof_attr(5), sudoers(5), user_attr(5),
pam_tty_tickets(7), smf_security(7), sudo(8)
HISTORY
Support for authenticated profiles was added in Oracle Solaris 11.2.0.
RBAC was added to Solaris in Solaris 8.
Oracle Solaris 11.4 21 Jun 2021 rbac(7)