Configuring HP-UX RBAC

Configuring Roles

Configuring roles for users is a two-step process:

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:

add

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

delete

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

modify

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

assign

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

revoke

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

list

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:

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

	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:

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

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:

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

The following example demonstrates the most common cmdprivadm arguments:

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:

	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:

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

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:

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:

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

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.