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

Planning the HP-UX RBAC Deployment

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Follow these planning steps before deploying HP-UX RBAC:

  1. Plan roles for users.

  2. Plan authorizations for the roles.

  3. Plan 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 the system.

Consider the following guidelines when designing roles:

  • 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 authorizations.

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:

# authadm list sys

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:

  1. List the system commands commonly used by each role.

  2. Compare these commands to the commands in the /etc/rbac/cmd_priv database.

  3. If you 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 /usr/sbin/useradd:dflt:(hpux.user.add,*):0/0//:dflt:dflt:dflt:

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/useradd:dfl:(hpux.user.add,*):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 clusters.

  • 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.

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