Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 9 HP-UX Role-Based Access Control

Configuring HP-UX RBAC


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Configuring HP-UX RBAC is a three-step process:

  1. Configure the roles.

  2. Configure the authorizations.

  3. Configure any additional commands.

IMPORTANT: Authorizations are built-in (hard-coded) to the HP-UX RBAC administration commands and cannot be configured. However, you can configure which roles and users have the required HP-UX RBAC administration command authorizations.

HP-UX RBAC administration commands do not need to be wrapped with the privrun command because they are setuid=0. The HP-UX RBAC administration commands run with privileges equal to root regardless of who invokes them. Access control checks limit who can use the HP-UX RBAC administrative commands.

See the Authorization section in each of the HP-UX RBAC administrative commands manpages for more information about their authorizations.

This Section  uses the example planning results and users in Table 9-6 to demonstrate the HP-UX RBAC administrative commands and configuration process.

Table 9-6 Example Planning Results




(Note: Objects Assumed to Be *)

Typical Commands

chandrika, rwang






bdurant, prajessh










Configuring Roles

Configuring roles for users is a two-step process:

  1. Create roles.

  2. Assign roles to users or groups.

Creating Roles

Use the roleadm command to create roles and assign them to users or groups. You must first add roles that do not already exist, and then assign users to those roles. The following shows the roleadm command syntax:

roleadm add role [comments] | delete role | modify oldrolename newrolename | assign user role | assign "&group" role | revoke user [role] | revoke "&group" [role] | list [user=username][role=rolename][sys]

Following is a list and brief description of the roleadm command arguments:


Adds the role to the system list of roles in /etc/rbac/roles.


Deletes the role from the system list of roles in /etc/rbac/roles.


Changes role names in all three role-related database files: /etc/rbac/roles, /etc/rbac/user_role, and /etc/rbac/role_auth.


Assigns a role to a user or group, and updates the /etc/rbac/user_role.


Revokes a role from a user or group, and removes the entry from /etc/rbac/user_role.


Lists the valid system roles (sys), or the user-to-role mappings.

NOTE: See the roleadm(1m) manpage for more information.

Following are two examples of the roleadm command adding new roles:

# roleadm add UserOperator roleadm: added role UserOperator
# roleadm add NetworkOperator roleadm: added role NetworkOperator
NOTE: The default configuration files delivered with HP-UX RBAC contain a single preconfigured role: Administrator. By default, the Administrator role is assigned all HP-UX system authorizations (hpux.*, *) and is associated with the root user.

After defining valid roles, you can assign them to one or more users or groups. Attempting to assign a role that has not been created to users will display an error message indicating that the role does not exist.

Assigning Roles to Users

Separating role creation from role assignment offers the following advantages:

  • Requiring that roles be created before they are assigned ensures that any typographical errors are caught when specifying role names during role assignment.

  • Allows different users to perform each task. For example, the same user is not required to both create the roles and assign the roles.

After creating valid roles, use the roleadm command to assign them to the appropriate users, as shown in the following examples:

# roleadm assign luman Administrator roleadm assign done in /etc/rbac/user_role # roleadm assign rwang UserOperator roleadm assign done in /etc/rbac/user_role

After using the roleadm assign command to assign roles to users, you can use the roleadm list command to verify that the roles were assigned correctly, for example:

# roleadm list root: Administrator luman: Administrator rwang: UserOperator
NOTE: HP-UX RBAC offers the ability to add a special user named DEFAULT to the /etc/rbac/user_role database. Assigning a role to the DEFAULT user means any user that does not exist on the system is assigned that role.

Assigning Roles to Groups

HP-UX RBAC also enables you to assign roles to groups. You can use the roleadm command options that use the user value, such as roleadm assign user role and roleadm revoke user role to administer groups and roles.

Assign, revoke, or list group and role information using the roleadm command by inserting an ampersand (&) at the beginning of the user value and enclosing the user value in quotations. The group name value and ampersand (&) must be shell escaped or enclosed in quotations to be interpreted by roleadm. For example:

# roleadm assign "&groupname" role

Configuring Authorizations

Configuring authorizations is similar to creating and assigning roles. However, authorizations contain two elements: an operation and an object. The * wildcard—the most commonly used object—is the implicit object used if you do not specify an object while invoking the authadm command. In many cases, the object is purposely left unspecified, so that the operation applies to all objects. Leaving the object unspecified is often used for authorizations that apply to wrapped commands because it can be difficult to determine the target of an action from the command name.

An example of this object ambiguity is the /usr/sbin/passwd command. The passwd command can operate on a number of repositories, for example, the /etc/passwd file, an NIS table, and an LDAP entry. You cannot determine the actual object by looking at the command line, so it is typically easiest to require that the user have the operation on all objects, for example: (hpux.security.passwd.change, *).

NOTE: You can configure a value for the default object. By default, if you do not specify an object, HP-UX RBAC will use the * wildcard as the object. However, if you have configured a value for the RBAC_DEFAULT_OBJECT= parameter in /etc/default/security, HP-UX RBAC will use this value instead of the * wildcard as the default object.

Use the authadm command to edit authorization information in the HP-UX RBAC databases. The authadm syntax is similar to the roleadm syntax. Following is the authadm command syntax:

authadm add operation[object[comments]] | delete operation[object] | assign role operation[object] | revoke [role=name][operation=name[object=name]] | list [role=name][operation=name[object=name][sys]

The following is a list and brief description of the authadm command arguments:


Adds an authorization to the system list of valid authorizations in /etc/rbac/auths.


Deletes an authorization from the system list of valid authorizations in /etc/rbac/auths.


Assigns an authorization to a role and adds an entry to /etc/rbac/role_auth.


Revokes an authorization from a role and updates /etc/rbac/role_auth.


Lists valid authorizations per system or role, and lists roles associated with the specified operation.

IMPORTANT: Be aware that when you assign an authorization that contains the asterisk * character, you must surround the wildcard character with quotation marks to prevent shell interpretation, as shown in the following examples.

The following are examples of authorization creation and assignment based on Table 9-6:

# authadm add 'company.customauth.*' authadm added auth: (company.customauth.*,*) # authadm assign Administrator 'company.customauth.*' authadm added auth for role Administrator

Use the list argument with the authadm command to verify the authorization assignment, for example:

# authadm list Administrator: (hpux.*, *) (company.customauth.*, *)

Configuring Additional Command Authorizations and Privileges

You must define any additional commands that are not provided in the default configuration. The authorizations needed to run the commands must already exist and must be assigned to a role. If you have not done this, the command will be configured, but no user will be appropriately authorized to use the command.

Use the cmdprivadm command to edit a command's authorization and privilege information. The cmdprivadm command works in a similar fashion to roleadm and authadm, but only allows addition and removal of a command privilege and authorization in the privrun database.

The following shows the cmdprivadm command syntax:

cmdprivadm add cmd=full_path_name_of_a_command | full_path_name_of_a_file |[op=operation]|[object=object] |[ruid=ruid]|[euid=euid] |[rgid=rgid]|[egid=egid] |[compartment=compartment_label] |[privs=comma_separated_privilege_list] |[re-auth=pam_service_name] |[flags=comma_separated_flags_list]
cmdprivadm delete cmd=full_path_name_of_a_command | full_path_name_of_a_file |[op=operation]|[object=object] |[ruid=ruid]|[euid=euid] |[rgid=rgid]|[egid=egid] |[compartment=compartment_label] |[privs=comma_separated_privilege_list] |[re-auth=pam_service_name] |[flags=comma_separated_flags_list]

The following is a list and brief description of the two main cmdprivadm command arguments:


Adds command (or file) authorization information to the /etc/rbac/cmd_priv database.


Deletes command (or file) authorization information in the /etc/rbac/cmd_priv database.

The following example demonstrates the most common cmdprivadm arguments:

# cmdprivadm add cmd=/opt/customcmd \ op=companyname.customcommand ruid=0 euid=0 flags=edit \ /opt/customcmd::(companyname.customcommand,*):0/0/-1/-1::::edit
cmdprivadm added the entry to /etc/rbac/cmd_priv

As shown in the previous example, the cmd_priv file database file contains a field for flag values. Be sure to consider the value of the cmdprivadm flags when configuring command or file authorization and privilege information.

The privrun command recognizes one defined flag, KEEPENV. If the KEEPENV flag is set in the cmd_priv file for a particular command, none of the environment variables will be scrubbed when privrun wraps that particular command.

For privedit, you can specify flag values to indicate whether or not privedit can edit a file. Additional flag values can be specified to indicate whether privrun can execute a command. The following are the supported flag values:

flag=empty or any other token

Indicates the file can only be executed and cannot be edited.


Indicates the file can be both edited and executed. This flag is mainly intended for scripts.


Indicates the file cannot be executed and can only be edited with privedit.

NOTE: See cmdprivadm(1M) for information on all of the cmdprivadm arguments. Most arguments are optional and are filled in with reasonable defaults if nothing is specified.To modify an existing entry in the /etc/rbac/cmd_priv file, you must first delete the entry and then add the updated version back in. When you use cmdprivadm to delete entries, arguments act as filters. For example, specifying the cmdprivadm delete op=foo command removes all entries where the operation is foo. As a result of this, when you use cmdprivadm to delete entries, be careful to ensure that you specify sufficient arguments to uniquely identify the entries to be removed.

Configuring HP-UX RBAC with Fine-Grained Privileges

Applications communicate with the system's resources using system calls, allowing the operating system access to system resources. Certain system calls require special, elevated privileges for the application to access the operating system and system hardware.

Before fine-grained privileges were available, UID=0 would satisfy as a special, elevated privilege for certain system calls. If the UID was not 0, the system call was denied and an application error returned.

HP-UX RBAC and specifically the privrun wrapper command allows non-root users to acquire the level of special privileges or UID=0 required for running certain applications. In addition to providing UID=0 to a non-root user in certain circumstances to run a particular application, HP-UX RBAC can also use the fine-grained privileges to run applications with additional privileges, but without UID=0.

You can use HP-UX RBAC to configure commands to run with only a select set of privileges and with different sets of privileges for different users, all without UID=0. For example, an administrator might need to run the foobar command with several privileges, and a normal user might need far fewer privileges to run foobar.

Think of fine-grained privileges as "system call access control check keys." Rather than checking for UID=0, the system call checks for a particular privilege. These fine-grained privileges provide the ability to "lock" system calls and to control application access to the operating system and hardware resources. Also, by splitting privileges into finely-grained privileges, applications do not require all privileges to run—only a specific privilege or set or privileges. Should an application process running with a particular set of privileges be compromised, the potential damage is far less than it would be if the process was running with UID=0.

NOTE: See privileges(5) for more information fine-grained privileges.

Use the cmdprivadm command and the privs option to configure commands for privrun to wrap and run only with the specified privileges. The following is an example cmdprivadm command that configures the /usr/bin/ksh command to run with the BASICROOT compound privilege and that requires the (hpux.adm.mount, *) authorization:

# cmdprivadm add cmd=/etc/mount op=hpux.adm.mount object='*' privs=BASICROOT

The preceding cmdprivadm command creates an entry in the /etc/rbac/cmd_priv file as follows:

#-------------------------------------------------------------------------------------------------------- # Command : Args :Authorizations :U/GID :Cmpt :Privs :Auth :Flags #----------------:--------:---------------------:------:-------:----------:------:------------------- /etc/mount :dflt :(hpux.adm.mount,*) :/// :dflt :BASICROOT :dflt :

After you create the entry using cmdprivadm and using privrun to wrap the command,/etc/mount will run with the elevated privilege of the BASICROOT compound fine-grained privilege and without UID=0 if the user has the (hpux.adm.mount, *) authorization.

As described in Section , the privrun -p command option matches only the entries in the /etc/rbac/cmd_priv database file that have the privileges specified by the -p option. Be aware when you specify a privilege using the privrun -p option that privrun will match all entries that contain the specified privilege—including groups of privileges and compound privileges that include the -p specified privilege. The privrun command will execute according to the first match in /etc/rbac/cmd_priv. For example, the following is an example privrun -p command and a list of entries the command will match in /etc/rbac/cmd_priv:

The command:

# privrun -p MOUNT /etc/mount

matches the following /etc/rbac/cmd_priv entries:

# Command        : Args   :Authorizations     :U/GID :Cmpt  :Privs                                  :Auth :Flags
/etc/mount       :dflt    :(hpux.adm.mount,*) :///   :dflt  :PRIV_CHOWN, MOUNT                      :dflt :
/etc/mount       :dflt    :(hpux.*,nfs)       :///   :dflt  :MOUNT, PRIV_RTPRIO, PRIV_MLOCK         :dflt :
/etc/mount       :dflt    :(hpux.adm.*,*)     :///   :dflt  :BASICROOT                              :dflt :
NOTE: The privrun -p MOUNT /etc/mount command matches the BASICROOT privilege because the MOUNT simple privilege is part of the predefined BASICROOT compound privilege. See the privileges(5) manpage for more information about simple and compound privileges.
IMPORTANT: The sequence of the entries in /etc/rbac/cmd_priv is important because privrun will execute according to the first explicit match it finds. In the preceding example, while all three entries are considered matches to the privrun command, privrun would execute the first entry. Keep the sequence of the entries in mind when configuring commands and authorizations. The cmdprivadm tool adds entries to the bottom of the /etc/rbac/cmd_priv file.

Configuring HP-UX RBAC with Compartments

HP-UX RBAC can also use compartments to configure applications to run in a particular compartment. With compartments, you can logically partition a system into compartments so that a process cannot communicate or access resources outside of its compartment (unless a compartment rule is set up to allow this).

The following is an example cmdprivadm command that configures the /sbin/init.d/hpws_apache command to run only in the apache compartment, which is defined by the /etc/cmpt/apache.rules compartment rule:

# cmdprivadm add cmd='/sbin/init.d/hpws_apache -a start' \ op=hpux.network.service.start object=apache compartment=apache

The preceding cmdprivadm command creates an entry in the /etc/rbac/cmd_priv file, as follows:

#--------------------------------------------------------------------------------------------------------------- # Command : Args :Authorizations :U/GID :Cmpt :Privs :Auth :Flags #-------------------------:--------:------------------------------------:--------------:--------:-------:------- /sbin/init.d/hpws_apache :start :(hpux.network.service.start,apache) :/// :apache :dflt :dflt :

After you create the entry using cmdprivadm and using privrun to wrap the command, authorized users can execute the /sbin/init.d/hpws_apache -start command, and it will run only in the apache compartment. The compartment tag for the process is changed to apache, and properties of the process will follow the defined apache compartment rules.

NOTE: Use only the cmdprivadm command to configure compartments for commands. Do not edit the /etc/rbac/cmd_priv database file without using cmdprivadm.

To modify an existing entry in the /etc/rbac/cmd_priv file, you must first delete the entry and then add the updated version back in. When you use cmdprivadm to delete entries, arguments act as filters. For example, specifying the cmdprivadm delete op=foo command removes all entries in which the operation is foo. As a result of this, when you use cmdprivadm to delete entries, be careful to ensure that you specify sufficient arguments to uniquely identify the entries to be removed.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.