rbac(5)rbac(5)NAME
rbac: RBAC - role-based access control
DESCRIPTION
RBAC (Role-Based Access Control) is an alternative to the all-or-noth‐
ing security model of traditional root user-based systems. With RBAC,
an administrator can assign roles to non-root users or UNIX groups.
Each role has authorizations composed of an operation and object, where
the operation is an action that can be performed on an object, and the
object is an object the user can access with a given operation. HP-UX
RBAC database files are installed in the directory.
The following is a list of the HP-UX RBAC commands, presented in the
sequence they are typically used:
Creates and manages role-related information in the
and databases.
Creates and manages authorization information in the
and databases.
Creates and manages a command's authorization and privilege information
in the
database.
Verifies the syntax and cross references between of all the HP-UX RBAC
databases and performs cross reference checks between
all the RBAC databases.
Executes privileged commands for users with proper authorizations.
Allows users with the proper authorization to invoke an editor for
editing restricted files.
The following are the main steps in configuring roles and authoriza‐
tions are:
1. Create roles using the command. The roles are added to the data‐
base.
2. Add authorizations using the command. The authorizations are added
to the database.
3. Assign authorizations or subroles to the roles using the command.
The roles, subroles and authorizations are added to the database.
4. Associate users or UNIX groups to roles using the command. The
users or groups and their corresponding roles are added to the data‐
base.
5. Define the commands or files to edit that will be associated with
authorizations using the command. The commands are added to the
database.
6. Check the databases using the command.
7. The authorized user can then either run privileged commands using
the wrapper command or edit restricted files using the wrapper com‐
mand.
The wrapper command determines what authorization is required for a
given command. This authorization-command information is defined in
the database file. consults the and database files to decide whether
the user calling privrun has the necessary authorization based on the
roles assigned to the user directly or indirectly via a UNIX group.
See privrun(1M) for details on the command, and refer to the section in
privrun(1M) for information about the database file.
The wrapper command works similarly to the command by determining the
required authorization needed to edit a given file. This authoriza‐
tion-file information is defined in the database file. consults the
and database files and decides whether the user calling privedit has
the necessary authorization to edit the file based on the roles
assigned to the user directly or indirectly via UNIX group.
See privedit(1M) for details on the command, and refer to the section
in privedit(1M) for information about the database file.
DATABASES
In each of the HP-UX RBAC databases, white space is ignored within an
entry. (This excludes the newline (\n) character, which is used as a
record separator.)
All of the fields in the HP-UX RBAC databases are case sensitive.
The following is a list of the HP-UX RBAC databases are currently pro‐
vided:
·
·
·
·
·
There are two HP-UX RBAC database files which define valid roles and
authorizations. The database defines valid roles, and the database
defines valid authorizations. The authorizations are specified in the
form of (operation, object) pairs.
Two additional database files assign roles to users or UNIX groups and
authorizations to roles. maps users or UNIX groups to their assigned
role(s). defines a set of authorizations or subroles for each role.
The database associates commands or files with authorizations.
The database associates commands or files with authorizations.
/etc/rbac/cmd_priv
The file contains the required authorizations needed to execute certain
commands or edit certain files. It also has the resulting privileges
(real and effective UID and GID, Fine grained privileges, and compart‐
ment) associated with the command. If the user is required to re-
authenticate prior to successful authorization, a PAM service name is
specified in this file indicating how or should identify itself to PAM.
The file contains any number of entries, where each entry is specified
on a single line and in the following format:
command | file: arguments : (operation, object) : egid : compartment :
privs : pam service : flags
These fields are explained in privrun(1M) and privedit(1M).
There may be multiple entries with the same command line (with differ‐
ent authorizations required and resulting privileges.) and evaluate
each entry sequentially in the order specified in the file, continuing
on to the next entry only if the user does not have the required autho‐
rization.
If the user desires a particular entry, they can use command-line
options with or to specify the set of privileges or authorization for a
particular entry. Note that only authorizations can be specified to
privedit.
See privrun(1M) or privedit(1M) for more information on database.
/etc/rbac/roles
The database contains definitions of all valid roles in the system. An
administrator must define new roles in this file before the roles can
be assigned to a user.
The roles are added and removed from the file by authorized users using
the command (see roleadm(1M)).
The database contains any number of entries, where each entry is
defined on a single line in the following format:
These fields are defined as follows:
Field Description
rolename The name of a role. For example, administrator,
accountant, engineer, manager, etc.
(Optional) Either an optional simple comment or an optional uri
to a
detailed description of the role.
For example:
The following example has just the role name, no comment or optional
uri:
/etc/rbac/auths
The database contains definitions of all valid authorizations in the
form of (operation, object) pairs in the system. An administrator must
define new (operation, object) pairs in this file before the (opera‐
tion, object) pairs can be assigned to a role.
The authorizations are added and removed from the file by authorized
users using the command (see authadm(1M)).
The database contains any number of entries, where each entry is
defined on a single line in the following format:
These fields are defined as follows:
Field Description
operation Denotes an action that can be performed on an
object. For example, is the operation of adding a
printer. is the operation of deleting a printer.
object The object the user can access with a given opera‐
tion. If is specified, all objects can be accessed
by the operation.
(Optional) Either an optional simple comment or an optional uri
to a detailed
description of the role.
For example:
Note: The operations specified in file must be fully-qualified and
cannot use wildcards; however, the objects can be be specified with a
wildcard using the asterisk character Authorizations that contain wild‐
card operations are validated using a match operation. At least one
operation must match the wildcard to assign the authorization to the
role.
/etc/rbac/user_role
The database defines the roles allowed for each specified user or UNIX
group.
The user to role definitions are added and removed in the file by
authorized users using the command (see roleadm(1M)).
The database contains any number of entries, where each entry is
defined on a single line in the following format:
These fields are used as follows:
Field Description
A valid user name or UNIX group name.
Group names must begin with the ampersand
role A valid role name defined in More than one role may
be specified for a user or group, if they separated
by commas.
The example below shows that user has roles of an administrator and a
programmer. Also, it shows user has the role assigned. Lastly, it
shows that the UNIX group has the role assigned:
/etc/rbac/role_auth
The file defines the authorizations and/or subroles for each specified
role. Each authorization is specified in the form of (opera‐
tion, object) pairs. The authorization pairs are defined in the data‐
base file.
A subrole is just another role with authorizations. When a subrole is
assigned to a role, the role inherits all the authorizations of the
subrole. The subrole name must be defined in the database file. No
recursive role definition is permitted. For example, if "role1" has a
subrole of "role2", and if users "role1" to "role2", this will cause a
recursive definition of both "role1" and "role2", and the command will
fail.
Authorized users can use the command to specify the authorizations
and/or subroles for each role in (Refer to authadm(1M) for more infor‐
mation).
All authorizations and/or subroles associated with a role must be spec‐
ified in a single entry. This entry can be more than one line; how‐
ever, each individual authorization pair must not exceed one line.
Lines that begin with alphanumeric characters followed by semicolons
(:) are considered new entries. The entries are in the following for‐
mat:
(operation, object) subrole...
(operation, object)...
(operation, object)...
subrole...
These fields are defined as follows:
Field Description
role A valid role, as defined in
operation A specific operation that can be performed on an
object. For example, is the operation of adding a
printer. Or, is the operation of either adding or
deleting a printer.
object The object the user can access. If is specified,
all objects can be accessed by the operation.
More than one (operation, object) pair may be speci‐
fied for a role.
subrole A valid role, as defined in It is assigned to
another role.
The following line states that the role of has authorization of which
means that the operation, can access the object, also has the ability
to add and delete system users.
SecurityOfficer: (hpux.passwd, /etc/passwd)
(hpux.user.add, *)
(hpux.user.del, *)
The has authorization to perform on all objects.
PrinterAdm: (hpux.printer.add, *)
The Administrator has subroles SecurityOfficer and PrinterAdm, and
therefore, has all the authorizations of both subroles as shown in the
preceding examples.
Administrator: SecurityOfficer PrinterAdm
/etc/rbac/aud_filter
The file defines role and authorization audit filtering. Audit records
will be generated for users whose role and associated authorization is
found in this file. If a user's role and associated authorization is
not found in the file, then no audit records specific to role and
authorization will be generated. Each authorization is specified in
the form of operation, object pairs.
Authorized users (as specified in database file) can edit to specify
the role and authorization to be audited.
All authorizations associated with a role must be specified in a single
entry. Only one authorization may be specified per role. The entries
are of the following format:
object
These fields are defined as follows:
Field Description
role A valid role, as defined in
operation A specific operation that can be performed on an
object. For example, is the operation of adding a
printer. Or, is the operation of either adding or
deleting a printer.
object The object the user can access. If is specified,
all objects can be accessed by the operation.
The following line specifies auditing the role of with authorization of
The role with authorization to perform on all objects is also specified
for auditing.
SecurityOfficer, hpux.passwd, /etc/passwd
PrinterAdm, hpux.printer.add, *
EXAMPLES
The following example shows how a root user uses the RBAC administra‐
tive commands to allow non-root user John to execute the command.
1. Add a role named UserAdmin to the roles database:
The above command adds the UserAdmin role to the database.
2. List defined authorizations in the system to determine what
authorizations are available.
3. Add an authorization named to the auths database. The operation
is and the object is
In the above example, the object is not specified and therefore
defaults to which means that the operation applies to ALL
objects. The is added to the database.
4. Assign the authorization, to the role.
The above command adds the following entry to the database:
5. Assign the role to user
The above command adds the following entry in the database:
"John: UserAdmin"
6. Add the command to the database:
The above command adds the following entry to the database:
7. Check to see if syntax and entries in the RBAC database are
valid:
8. Now non-root user John has been associated with the UserAdmin
role. The UserAdmin role has been assigned an authorization
named which is the needed authorization for executing as per the
entry added in the database. Non-root user John can now run
using to add regular users to the system as follows:
AUDITING
These commands, privrun(1M), roleadm(1M), authadm(1M) and cmdpri‐
vadm(1M) all generate audit records. The audit records include a call‐
er's username, UID, role, authorizations, object, time of the event,
success or failure of the event, etc.
You can provide an audit filter database file which allows a user to
specify the role and the authorization (operation, object) to be
audited. Role-to-authorization audit records will be generated only if
the caller's role and authorization matches one of the entries in the
database.
If the audit filter database file does not exist, or is not accessible,
then the audit records will still be generated. However, if the audit
filter database file exists, but is empty, then no audit records will
be generated.
The following is an example of how to generate and display the audit
records for
See audit(5), audevent(1M), audsys(1M), and audisp(1M) to learn more
about generating and displaying audit records.
FILES
Database containing definitions of all valid authorizations.
Database containing the authorization to execute specified commands or
edit specific files, and the privileges to alter UID and GID for
command execution.
Database containing all valid definitions of all roles.
Database defining the authorizations and/or subroles for each role.
Database specifying the roles for each specified user or UNIX group.
Database containing a list of roles and associated authorizations to be
audited.
SEE ALSOauthadm(1M), cmdprivadm(1M), privrun(1M), privedit(1M), rbacdbchk(1M),
roleadm(1M), privileges(5), compartments(5).
rbac(5)