Chapter 19 Role-Based Access Control
This chapter describes Role-Based Access Control, a new security feature in
the Solaris 8 release.
Overview of Role-Based Access Control
Role-based access control (RBAC) is an alternative to the all-or-nothing security
model of traditional superuser-based systems. The problem with the traditional model
is not just that superuser is so powerful but that other users are not powerful enough
to fix their own problems. RBAC provides the ability to package superuser privileges
for assignment to user accounts.
With RBAC, you can give users the ability to solve their own problems by assigning
them packages of the appropriate privileges. Superuser's capabilities can be diminished
by dividing those capabilities into several packages and assigning them separately
to individuals sharing administrative responsibilities.
RBAC thus enables separation of powers, controlled delegation of privileged
operations to other users, and a variable degree of access control.
RBAC includes these features:
-
Authorization - A right that is used to grant access to a restricted
function
-
Execution profile (or simply profile) - A bundling mechanism
for grouping authorizations and commands with special attributes; for example, user
and group IDs
-
Role - A special type of user account intended for performing
a set of administrative tasks
RBAC relies on four databases to provide users access to privileged operations:
-
user_attr (extended user attributes database)
- Associates users and roles with authorizations and execution profiles
-
auth_attr (authorization attributes
database) - Defines authorizations and their attributes and identifies the associated
help file
-
prof_attr (execution profile attributes
database) - Defines profiles, lists the profile's assigned authorizations, and identifies
the associated help file
-
exec_attr (profile execution attributes
database) - Defines the privileged operations assigned to a profile
The following figure illustrates how RBAC works. Databases are shown in boxes
while the arrows indicate relationships between databases. The entities assigned in
the relationships appear next to the arrows.
You can assign authorizations (1) and profiles (2) to users in the user_attr database; this is direct assignment of privileged operations.
You can also assign the user to a role (3), to give the user access to any privileged
operations associated with that role. Profiles are defined in the prof_attr database and can include authorizations (4) defined in auth_attr and commands with attributes (5) defined for that profile in exec_attr.
Commands that are assigned to profiles are run in special shells called profile shells. The profile shells are pfsh, pfcsh, and pfksh, and they correspond to Bourne shell
(sh), C shell (csh), and Korn shell (ksh) respectively.
Extended User Attributes Database (user_attr)
The /etc/user_attr database supplements the passwd and shadow databases. It contains extended
user attributes such as authorizations and execution profiles. It also allows roles
to be assigned to a user.
A role is a special type of user account that is intended for performing a set
of administrative tasks. It is like a normal user account in most respects except
that users can gain access to it only through the su command; it
is not accessible for normal logins, for example, through the CDE login window. From
a role account, a user can access commands with special attributes, typically root
user ID, that are not available to users in normal accounts.
The fields in the user_attr database are separated by colons:
user:qualifier:res1:res2:attr
|
The fields are described in the following table.
|
Field Name
|
Description
|
|
user
|
The name of the user as specified in the passwd(4) database.
|
|
qualifier
|
Reserved
for future use.
|
|
res1
|
Reserved for future
use.
|
|
res2
|
Reserved for future
use.
|
|
attr
|
An optional list of
semicolon-separated (;) key-value pairs that describe the security attributes to be
applied when the user runs commands. There are four valid keys: auths, profiles, roles, and type.
-
auths specifies a comma-separated list of authorization
names chosen from names defined in the auth_attr(4) database. Authorization names may include the asterisk (*)
character as a wildcard. For example, solaris.device.* means all
of the Solaris device authorizations.
-
profiles contains an ordered, comma-separated
list of profile names chosen from prof_attr(4). A profile determines which commands a user can execute and
with which command attributes. At minimum each user in user_attr
should have the All profile, which makes all commands available
but without any attributes. The order of profiles is important; it works similarly
to UNIX search paths. The first profile in the list that contains the command to
be executed defines which (if any) attributes are to be applied to the command.
-
roles can be assigned to the user using
a comma-separated list of role names. Note that roles are defined in the same user_attr database. They are indicated by setting the type value to role. Roles cannot be assigned to other roles.
-
type can be set to normal, if this account
is for a normal user, or to role, if this account is for a role. A role is assumed
by a normal user after the user has logged in.
|
A user_attr database with typical values is shown in the
following example.
A typical role assignment is illustrated in the following user_attr database. In this example, the sysadmin role has been
assigned to the user johndoe. When assuming the sysadmin role, johndoe has access to such profiles as Device
Management, Filesystem Management, and the All profile.
Authorizations
An authorization is a user right that grants access to a restricted function.
It is a unique string that identifies what is being authorized as well as who created
the authorization.
Authorizations are checked by certain privileged programs to determine whether
users can execute restricted functionality. For example, the solaris.jobs.admin authorization is required for one user to edit another user's crontab file.
All authorizations are stored in the auth_attr database.
Authorizations may be assigned directly to users (or roles) in which case they are
entered in the user_attr database. Authorizations can also be
assigned to execution profiles which in turn are assigned to users.
The fields in the auth_attr database are separated by colons:
authname:res1:res2:short_desc:long_desc:attr
|
The fields are described in the following table.
|
Field Name
|
Description
|
|
authname
|
A unique character string used to identify the authorization in the format prefix.[suffix]. Authorizations for the Solaris
operating environment use solaris as a prefix. All other authorizations
should use a prefix that begins with the reverse-order Internet domain name of the
organization that creates the authorization (for example, com.xyzcompany). The suffix indicates what is being authorized, typically the functional
area and operation.
When there is no suffix (that is, the authname consists of a prefix and functional area and ends with a period), the authname serves as a heading for use by applications in their GUIs rather
than as an authorization. The authname solaris.printmgr. is an example of a heading.
When authname
ends with the word grant, the authname serves as a grant authorization
and lets the user delegate related authorizations (that is, authorizations with the
same prefix and functional area) to other users. The authname solaris.printmgr.grant is an example of a grant authorization; it gives
the user the right to delegate such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner to other users.
|
|
res1
|
Reserved for future use.
|
|
res2
|
Reserved for future use.
|
|
short_desc
|
A terse name for the authorization suitable
for displaying in user interfaces, such as in a scrolling list in a GUI.
|
|
long_desc
|
A long description. This field identifies the
purpose of the authorization, the applications in which it is used, and the type of
user interested in using it. The long description can be displayed in the help text
of an application.
|
|
attr
|
An optional list
of semicolon-separated (;) key-value pairs that describe the attributes of an authorization.
Zero or more keys may be specified.
The keyword help identifies a help
file in HTML. Help files can be accessed from the index.html
file in the /usr/lib/help/auths/locale/Cdirectory.
|
An auth_attr database with some typical values is shown
in the following example.
The relationship between the auth_attr and the user_attr databases is illustrated in the following example. The solaris.system.date authorization, which is defined in the auth_attr database, is assigned to the user johndoe in the user_attr database.
Execution Profiles
An execution profile is a bundling mechanism for grouping authorizations and
commands with special attributes, and assigning them to users or roles. The special
attributes include real and effective UIDs and GIDs. The most common attribute is
setting the real or effective UID to root. The definitions of execution profiles are
stored in the prof_attr database.
The fields in the prof_attr database are separated by colons:
profname:res1:res2:desc:attr
|
The fields are described in the following table.
|
Field Name
|
Description
|
|
profname
|
The name of the profile. Profile names are case-sensitive.
|
|
res1
|
Reserved for future use.
|
|
res2
|
Reserved for future use.
|
|
desc
|
A long description. This field should explain the
purpose of the profile, including what type of user would be interested in using it.
The long description should be suitable for displaying in the help text of an application.
|
|
attr
|
An optional list of key-value pairs separated
by semicolons (;) that describe the security attributes to apply to the object upon
execution. Zero or more keys may be specified. There are two valid keys, help and auths.
The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C
directory.
auths specifies a comma-separated list of
authorization names chosen from those names defined in the auth_attr(4) database. Authorization names may
be specified using the asterisk (*) character as a wildcard.
|
A prof_attr database with some typical values is shown
in the following example.
The relationship between the prof_attr and the user_attr databases is illustrated in the following example. The Device
Management profile, which is defined in the prof_attr database,
is assigned to the sysadmin role in the user_attr
database.
The relationship between the prof_attr and the auth_attr databases is illustrated in the following example. The Device
Management profile is defined in the prof_attr database as having
all authorizations beginning with the solaris.device. string assigned
to it. These authorizations are defined in the auth_attr database.
Execution Attributes
An execution attribute associated with a profile is a command (with any special
security attributes) that can be run by those users or roles to whom the profile is
assigned. Special security attributes refer to such attributes as UID, EUID, GID,
EGID that can be added to a process when the command is run.
The definitions of the execution attributes are stored in the exec_attr database.
The fields in the exec_attr database are separated by colons:
name:policy:type:res1:res2:id:attr
|
The fields are described in the following table.
|
Field Name
|
Description
|
|
name
|
The name of the profile. Profile names are case-sensitive.
|
|
policy
|
The security policy associated with this entry. Currently, suser (the superuser policy model) is the only valid policy entry.
|
|
type
|
The type of entity whose attributes are specified.
Currently, the only valid type is cmd (command).
|
|
res1
|
Reserved for future use.
|
|
res2
|
Reserved for future use.
|
|
id
|
A string identifying the entity; the asterisk wild
card can be used. Commands should have the full path or a path with a wild card.
To specify arguments, write a script with the arguments and point the id to the script.
|
|
attr
|
An optional list
of semicolon (;) separated key-value pairs that describe the security attributes to
apply to the entity upon execution. Zero or more keys may be specified. The list of
valid key words depends on the policy being enforced. There are four valid keys: euid, uid, egid, and gid.
euid and uid contain
a single user name or a numeric user ID. Commands designated with euid
run with the effective UID indicated, which is similar to setting the setuid bit on an executable file. Commands designated with uid
run with both the real and effective UIDs.
egid and gid contain a single group name or numeric group ID. Commands designated
with egid run with the effective GID indicated, which is similar
to setting the setgid bit on an executable file. Commands designated
with gid run with both the real and effective GIDs.
|
An exec_attr database with some typical values is shown
in the following example.
The relationship between the exec_attr and the prof_attr databases is illustrated in the following example. The Printer
Management profile is defined in the prof_attr database. It has
13 execution attributes with the appropriate security attributes assigned to it in
the exec_attr database.
How to Assume Role-Based Access Control
To assume a role, use the su command. You cannot log in to
a role. For example:
%su my-role
Password: my-role-password
#
|
To use commands in the profile, simply type into a shell. For example:
# lpadmin -p myprinter options
|
The lpadmin command is executed with any process attributes,
special UIDs or GIDs, that have been assigned to the lpadmin command
in profiles for the role assumed.
Tools for Managing Role-Based Access Control
In addition to editing the databases directly, the following tools are available
for managing with role-based access control.
|
Command
|
Description
|
|
auths(1)
|
Display authorizations for a user.
|
|
makedbm(1M)
|
Make
a dbm file.
|
|
nscd(1M)
|
Name service cache daemon, useful for caching
the user_attr, prof_attr, and exec_attr databases.
|
|
pam_roles(5)
|
Role account management module for PAM. Checks
for the authorization to assume role.
|
|
pfexec(1)
|
Profile shells, used by profile shells to execute
commands with attributes specified in the exec_attr database.
|
|
policy.conf(4)
|
Configuration file for security policy. Lists granted authorizations.
|
|
profiles(1)
|
Display profiles for a specified user.
|
|
roles(1)
|
Display
roles granted to a user.
|
|
roleadd(1M)
|
Add a role account on the system.
|
|
roledel(1M)
|
Delete
a role's account from the system.
|
|
rolemod(1M)
|
Modify a role's account information on the
system.
|
|
useradd(1M)
|
Add a user account on the system. The -P option
assigns a role to a user's account.
|
|
userdel(1M)
|
Delete a user's login from the system.
|
|
usermod(1M)
|
Modify
a user's account information on the system.
|
Descargar este libro en PDF (1611 KB)