HP UX 11i Role-based Access Control (RBAC) Software manual Planning the HP-UX Rbac Deployment

1.A process, specifically a shell, associated with the user executes privrun with the goal of executing a target command with elevated privilege.

2.The target command line (command and arguments) is explicitly passed to privrun, and the UID of the invoking user is implicitly passed via the process context.

3.privrun attempts to find a match (or set of matches) within the /etc/rbac/cmd_priv database for the specified command line. Each matching entry also specifies a required authorization (operation, object pair) and the resulting privileges if the user has the specified authorization.

4.privrun makes a call (for each matching /etc/rbac/cmd_priv entry) to the ACPS. The HP-UX RBAC back end of the ACPS consults the /etc/rbac/user_role and /etc/rbac/role_auth databases to determine whether the user has the specified authorization, and passes this result back to privrun.

5.Assuming that the user associated with the process has the required authorization specified in the /etc/rbac/cmd_priv database for the requested command, privrun will drop all privileges except those specified in the /etc/rbac/cmd_priv entry and execute the requested command. The privrun command is set to UID=0 and starts with all necessary privileges.

Planning the HP-UX RBAC Deployment

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.

Step 1: 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.

Step 2: 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. Use 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:

Planning the HP-UX RBAC Deployment 33