Follow these planning steps before deploying HP-UX
roles for users.
authorizations for the roles.
the authorization-to-command mappings.
The following sections describe these steps in more detail.
Planning the Roles
Planning an appropriate set of roles for the users
of a system is a critical first step in deploying HP-UX RBAC. In some
enterprises, this set of roles already exists, and you can reuse it
when configuring HP-UX RBAC. More commonly, you must design the roles
based on the existing tasks associated with administrative users on
Consider the following guidelines when designing
There should be considerably
fewer roles than the total number of users of the system. If each
user requires a special role, then all of the simplified management
associated with the use of roles is no longer in place.
Roles should have some relation
to the actual business roles of the users.
Users can have multiple
roles, and therefore you can design some roles simply to group authorizations
common to multiple business roles. Using this approach, you can design
roles hierarchically to include different roles by including their
Planning Authorizations for the Roles
After defining roles, you can plan the authorizations
associated with each role. If the roles align with the pre-existing
operation hierarchy, then assigning the authorizations is straightforward.
Enter the following command to list all the system-defined authorizations:
If the existing authorization hierarchy does not
align with your roles, defining the authorizations associated with
each role is more complex. You can use the following steps to help:
the system commands commonly used by each role.
these commands to the commands in the /etc/rbac/cmd_priv database.
find matching entries after performing the previous steps, use those
entries as a guide for assigning authorizations.
For example, assume one of the desired roles is
UserOperator, which commonly runs such commands as useradd, usermod, userdel, and so
on. To determine what authorizations might be appropriate for this
role, enter the following command:
# grep useradd /etc/rbac/cmd_priv
In this example, the /usr/sbin/useradd command requires the hpux.user.add authorization.
You could assign this authorization directly, or assign hpux.user.* as the authorization.
Be careful using wildcards when assigning authorizations.
Assigning this authorization actually assigns multiple authorizations:
# grep hpux.user. /etc/rbac/cmd_priv
/usr/sbin/pwgrd:dflt:(hpux.user.cache.admin,*):0/0// :dflt :dflt :dflt :
/usr/sbin/userdel:dflt:(hpux.user.delete,*):0/0// :dflt :dflt :dflt :
/usr/sbin/groupdel:dflt:(hpux.user.group.delete,*):0/0// :dflt :dflt :dflt :
/usr/sbin/usermod:dflt:(hpux.user.modify,*):0/0// :dflt :dflt :dflt :
/usr/sbin/groupadd:dflt:(hpux.user.group.add,*):0/0// :dflt :dflt :dflt :
/usr/sbin/groupmod:dflt:(hpux.user.group.modify,*):0/0// :dflt :dflt :dflt :
/usr/sbin/vipw:dflt:(hpux.user.modify,*):0/0// :dflt :dflt :dflt :
Planning Command Mappings
Define any commands that are commonly used by any
of the defined roles but do not exist in the predefined /etc/rbac/cmd_priv file that is provided. The /etc/rbac/cmd_priv file defines the mapping between authorizations and commands. Determine
the following for each command:
The full path of the command
The necessary authorization
to check before running the command
Any special privileges needed
by the command, for example, euid=0
The strings of text that constitute the operation
and object entries in the /etc/rbac/cmd_priv file
are arbitrary, but they should correspond logically to a command or
set of commands. Consider the following guidelines when planning the
authorization to command mappings in /etc/rbac/cmd_priv:
Define operations into logical
groups to easily assign the operations to roles.
Do not create operation
branches with too many (more than 10) or too few (1) child elements.
The overall tree should not be overly wide, making it difficult to
assign groups of operations, or overly tall, with individual operation
names that are long and hard to use.
End the last element of
an operation name with an action (verb).
Define operations so that
new commands can be clearly placed when added.
See “Configuring Additional Command Authorizations and Privileges” for the procedure
to configure additional commands.
HP-UX RBAC Limitations and Restrictions
Following is a list of items to consider before
deploying HP-UX RBAC:
HP-UX RBAC does not support
single user mode, therefore the root account should be available during
situations when single user mode is needed.
Serviceguard does not support
the use of HP-UX RBAC and privrun to grant access
to Serviceguard commands. See Section for more information about HP-UX RBAC and Serviceguard
As with all applications,
HP-UX RBAC is subject to the rules that govern compartments (see Chapter 7). Remember the following
when using HP-UX RBAC with Compartments:
You cannot run privedit on a file
that is restricted by a compartment definition.
To provide a different application with fine-grained
privileges, the privrun command must be running
with those same privileges it wants to provide to the application.
By default, privrun is configured to run with all
privileges (see getfilexsec(1M) for more information). However, sometimes
this default privilege set may be restricted. For example, if a compartment
is configured to disallow privileges, this specification prevents privrun from providing the privileges to the application
in that compartment because privrun does not have
the privileges itself. Note that by default, sealed compartments are
configured to disallow the POLICY compound privilege.
For privrun to invoke another application
in a compartment, privrun must assert the CHANGECMPT privilege. If privrun cannot assert the CHANGECMPT privilege,
for example, if the compartment is configured to disallow privileges, privrun will fail. This behavior is intentional and designed
to reinforce the concept of a sealed compartment.