NetIQ Documentation: NetIQ Privileged User Manager 2.5 Administration Guide - Integrating Command Control to User Environments

6.2 Integrating Command Control to User Environments

Privileged User Manager provides a number of shells and functions that are installed as part of the Command Control Agent.

The pcksh and cpcksh shells, which are based on the Korn shell (ksh)
The usrun command, which provides for command execution as a privileged user.

These shells and functions allow you to integrate Command Control into the UNIX and Linux user environments.

cpcksh is normally used to audit users who do not need any additional privileges. With NetIQ Privileged User Manager, you can change a user’s login shell to cpcksh (/usr/bin/cpcksh), then configure a Command Control rule to authorize cpcksh and enable session capture. When the users log in, the commands are captured and audited through NetIQ Privileged User Manager. Auditing is transparent to the users, and the users perceive no change.

pcksh is normally used to grant privileges, such as the ability to run commands as root. A user logs in as a non-privileged user, then issues a usrun pcksh command to access the root ksh shell. Privileged User Manager can be configured to perform a complete session capture of everything the user does as root. In addition, you can configure rules that set up command risks for specific commands. You can also configure rules that prevent the execution of specific commands.

Depending upon the users logging in to your host machines, you can create rules for one or more of the following scenarios:

6.2.1 Using usrun with a Command

Type usrun before any command to pass the command to the Command Control Manager for authorization.

The usrun function can be used with the following options:

usrun [-b] [-p] [-t] [-x] [-u <user>] [-h <host>] <command>

Option	Description
-b	Puts the execution of the command into the background.
-p	Provides a pipe compatibility option for competitive products. It is only used for a competitive swap-out.
-t	Provides a test command option that tests the specified command against the rule structure. A yes or no is printed to the screen, indicating whether the command would be accepted or not.
-x	Enables the X11 forwarding option.
-u <user>	Specifies the user you want the command to run as, although this can be overwritten by the Command Control rules.
-h <host>	Specifies the host you want the command run on, although this can be overwritten by the Command Control rules. For <host> you can use either the hostname of the computer or the agent name specified in the Hosts console.
<command>	Specifies the command to pass to the Command Control Manager.

For example, to provide administrators access to the passwd command so they can change user passwords, you must define a Command Control rule to authorize the passwd command for the appropriate administrators.

On the home page of the console, click Command Control.
Add a password command:
1. Click the Commands icon, then click Add in the details pane.
2. Specify command name, then click Add.
3. Select the new command, then click the edit icon next to it..
4. Fill in the following fields:
  
  Description: Explain the purpose of this command. Specify something similar to the following:
  
  Allows a user to submit a usrun passwd command to change account passwords.
  
  Commands: Specify the following command.
  
  passwd *
5. Click Modify.
Add an Account User Group for the password command:
1. In the navigation pane, click Account Groups > User Group, then in the details pane, click Add..
2. Specify the user group name, then click Add.
3. In the details pane, select the user group, then click the Edit icon.
4. Fill in the following fields:
  
  Description: Explain the purpose of this user group. Specify something similar to the following:
  
  Defines the user accounts that can run the usrun passwd command to change account passwords.
  
  Users: Specify the usernames of the users on the Linux and UNIX hosts that have the permission to use the usrun passwd command.
5. Click Modify.
Add a rule for the password command:
1. In the Command Control pane, Click Rules, then in the details pane, click Add.
2. Specify the rule name, then click Add.
3. Select the password command that you had created in Step 2, then drag and drop it to the password rule that you have created.
4. Select the password user group that you had created in Step 3, then drag and drop it to the password rule.
5. Select the password rule, then in the details pane, click Modify.
6. Fill in the following fields:
  
  Description: Explain the purpose of this rule and the users it matches. Specify something similar to the following:
  
  Matches users who submit a usrun passwd command. It authorizes their session and sets the run user to root.
  
  Session Capture: Select Off.
  
  Authorize: Select Yes, then select Stop from the drop-down menu.
  
  Run User: Specify root.
7. Click Modify.

Repeat this process for each command you want the users to run with the usrun command.

6.2.2 Using pcksh for Privileged Sessions

To use the pcksh shell, the user logs in using a non-privileged account. Then the user uses the usrun command to gain privileged shell access to perform administrative functions. The privileged shell performs complete session capture and can optionally audit the actual commands executed for use with Command Risk.

For this scenario, you must enable session capture and define a Command Control rule to authorize pcksh for the appropriate users.

On the home page of the console, click Command Control.
Add a pcksh command:
1. In the navigation pane, click the Commands icon, then in the details pane, click Add.
2. Specify a command name, then click Add.
3. Select the new command, then in the details pane click the editicon.
4. Fill in the following fields:
  
  Description: Explain the purpose of this command. Specify something similar to the following:
  
  When a user submits a usrun pcksh command or a usrun shell command, the command is rewritten to /usr/bin/pcksh. The Command Control Audit level is set to 1, which enables an additional level of audit to use with the Command Risk.
  
  Rewrite: Specify the following:
```
/usr/bin/pcksh -o audit 1
```
  Commands: Specify the following commands, each on a separate line.
```
pcksh
shell
```
5. Click Modify.
Add an Account User Group for the pcksh shell:
1. Click Account Groups > User Groups, then in the details pane, click Add.
2. Specify a user group name, then click Add.
3. In the details pane, select the new user group, then click the edit icon that is next to the user group name.
4. Fill in the following fields:
  
  Description: Explain the purpose of this user group. Specify something similar to the following:
  
  Defines the user accounts that can run the usrun pcksh command to access root privileges.
  
  Users: Specify the usernames of the users on the Linux and UNIX hosts that have the permission to use the usrun pcksh command.
5. Click Modify.
Add a rule for the pcksh command:
1. Click Rules, then in the details pane, click Add.
2. Specify a rule name, then click Add.
3. In the navigation pane, click the Commands icon.
4. Select the pcksh command, then drag and drop it to the pcksh rule.
5. In the navigation pane, click the Account Groups icon.
6. Select the pcksh user group, then drag and drop it to the pcksh rule.
7. Select the pcksh rule, then in the details pane, click Modify.
8. Fill in the following fields:
  
  Description: Explain the purpose of this rule and the users it matches. Specify something similar to the following:
  
  Matches users who submit a usrun pcksh or usrun shell command. It authorizes their session and enables session capture as root. The command assigned to this rule also included a rewrite that enables the additional level of audit to be used in conjunction with the command risk list. For information on this feature, see Section 6.8.3, Setting the Command Risk.
  
  Session Capture: Select On.
  
  Authorize: Select Yes, then select Stop from the drop-down menu.
  
  Run User: Specify root.
9. Click Modify.
(Conditional) If the users need different environment variables to run some of their privileged commands, you can use a script to set up the values.

By default, Command Control uses the environment variables of the executing user. If the users receive a “not found” message for a command, you need add environment variables to the rule. For configuration information, see Section 6.9, Scripts and Modify Environment Script.

You can also define illegal commands, including built-in shell commands, in a script assigned to the rule. For configuration information, see Section 6.9, Scripts and pcksh Illegal Commands Script.

6.2.3 Using cpcksh for Complete Session Capture

This method of integration provides the most auditing functionality. By changing the user’s shell to the cpcksh client instead of the pcksh client, Command Control can be configured to capture the user’s complete session, in addition to all other audit and control features.

When the user logs in to the server, the session is started with the cpcksh client, which executes as a normal Korn shell. A request is sent to the Command Control Manager for authorization. You must define a cpcksh rule that enables session capture, as described in the steps below. Functions and aliases that can replace normal system commands are read from /etc/profile.pcksh. When the user issues a command that needs privileges to run, it is executed through the Command Control system.

Use the tool provided in the UNIX or Linux environment to set the user login shell to
```
/usr/bin/cpcksh
```
Add a cpcksh command:
1. In the navigation pane, click the Commands icon > click Command > Add.
2. Specify a name (for example, cpcksh shell), then click Add.
3. In the details pane, select the name of the cpcksh command, then click the Edit <command name> icon.
4. Fill in the following fields:
  
  Description: Explain the purpose of the rule. Specify something similar to the following:
  
  When a user’s shell is set to /usr/bin/cpcksh and the user logs in, a Command Control request is sent with a submitting command of -cpcksh to indicate login. The user’s login shell is rewritten to /usr/bin/pcksh. The Command Control Audit level is set to 1, which enables an additional level of audit to use with the Command Risk.
  
  Rewrite: Specify the following:
  
  /usr/bin/pcksh -o audit 1
  
  Commands: Specify the following:
```
-cpcksh
```
5. Click Modify.
Add a cpcksh Account User Group:
1. In the navigation pane, click the Account Groups icon > User Group, then in the details pane, click Add.
2. Specify a name, then click Add.
3. In the details pane, select the cpcksh user group, then click the Edit <user group name> icon.
4. Fill in the following fields:
  
  Description: Explain the purpose of this user group. Specify something similar to the following:
  
  Defines the user accounts that can use the cpcksh command.
  
  Users: Specify the usernames of the users on the Linux and UNIX hosts that have the permission to use the cpcksh command.
5. Click Modify.
Add a cpcksh rule:
1. In the Command Control pane, click Rules, then in the details pane click Add.
2. Specify a name for the rule, then click Add.
3. In the navigation pane, click the Commands icon.
4. Select the cpcksh command, then drag and drop it to the cpcksh rule.
5. In the navigation pane, click the Account Groups icon.
6. Select the cpcksh user group, then drag and drop it to the cpcksh rule.
7. In the Command Control pane, select the cpcksh rule, then in the details pane click Modify.
8. Fill in the following fields:
  
  Description: Explain the purpose of this rule. Specify something similar to the following:
  
  Authorizes the matching of submit users who have /usr/bin/cpcksh as their defined login shell. It authorizes their session and enables session capture, when they are still running as their original login ID.
  
  Session Capture: Select On.
  
  Authorize: Select Yes, then select Stop if authorized from the drop-down menu. These settings allow subsequent commands to be executed without authorization checks whenever the user has had one command authorized.
9. Click Modify.

6.2.4 Using pcksh for Complete Session Control

You can change the user’s login shell to the pcksh client so that no authorization request is sent when the user logs on. This provides a method of integration that is invisible to the user.

The pcksh client executes as a normal Korn shell. Functions and aliases that replace normal system commands that are read from /etc/profile.pcksh. When the user issues a command that needs privileges to run, it is authorized through the Framework.

Use the tool provided in the UNIX or Linux environment to set the users’ shell to the following:
```
/usr/bin/pcksh
```
To ensure that configured commands are authorized at the Framework, add the following line to either the user’s profile file or to the central profile.pcksh file in the /etc directory on the appropriate UNIX or Linux servers:
```
set -o remote
```
IMPORTANT:The set -o remote option forces all commands that are not built in to the user’s shell to be authorized at the Framework. Commands for which a defined rule does not exist are not permitted to execute. To prevent all commands in the profile.pcksh file or .profile file from being passed to the Framework for authorization, add the set -o remote command at the end of the file.

(Optional) Set the following additional options in the profile file:

Option	Description
set -o host <hostname>	Specifies that all authorized commands are executed on the defined host, if permitted.
set -o user <username>	Specifies that all authorized commands are executed as the defined user if permitted.
set -o audit <n>	Enables auditing, Set <n> to one of the following values: 1: Enables auditing of all commands that are not built into the user's shell. 2: Enables auditing of all commands including commands that are built into the user's shell. This level of auditing can affect login times. After the audit value has been set, it cannot be changed. If it is turned on in the profile, the user cannot turn it off later.
set -o ignoreperm	Enables commands that have not been successfully authorized at the Framework to execute according to the local permissions in effect on the server where the command was issued.
set -o test	Allows typed commands to be checked to see if they would be accepted by the rule structure. A yes or no output to screen indicates the result. The set -o test option is normally used in conjunction with the set -o remote option.
set -o test '${}$'	Returns the complete metadata result that is generated by the Command Control manager.

Rule definitions override the settings for user and host. If a successfully matched rule specifies a run user or a run host, this user or host is used to execute the command, and not those specified in the set -o commands.

You can use rule conditions to match the run user or run host to the username or hostname defined by using these commands (see Setting Conditions for a Rule), but if a run user or run host is defined in the rule configuration, these are the ones that are used.

You can define a list of illegal commands, including built-in shell commands, in a script assigned to a rule. Users using the pcksh shell cannot run these commands, even if they are root.

6.2.5 Using Shell Scripts

You can hide some of the complexities of the privileged command syntax from the users by using scripts and aliases to wrap privileged tasks. Using this technique, the end user can log in with their non-privileged account and use what appear to be standard commands to perform privileged tasks. Alternatively, you could create a script that provides a menu system to access a set of administrative tasks. With this method, the user would simply select options from the menu to perform their privileged tasks.

Either method requires a shell script that executes under the pcksh shell and performs remote authorization. For example:

#!/usr/bin/pcksh
set –o remote 
passwd $*

This script executes the pcksh client, sets it to use Command Control, and executes the passwd command.