6.2 Integrating Command Control into 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.

  1. Click Command Control on the home page of the console.

  2. Add a password command:

    1. Click Commands, then click Add Command in the task pane.

    2. Specify a name, then click Finish.

    3. Select your new command, then click Modify Command.

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

  3. Add an Account User Group for the password command:

    1. Click Account Groups > User Groups, then click Add User Group in the task pane.

    2. Specify a name, then click Finish.

    3. Select your password user group, then click Modify User Group.

    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 your Linux and UNIX hosts that have your permission to use the usrun passwd command.

    5. Click Finish.

  4. Add a rule for the password command:

    1. Click Rules, then click Add Rule in the task pane.

    2. Specify a name, then click Finish.

    3. Select your password command, then drag it to your password rule.

    4. Select your passwd user group, then drag it to your password rule.

    5. Select your password rule, then click Modify Rule in the task pane.

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

Repeat this process for each command you want your 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.

  1. Click Command Control on the home page of the console.

  2. Add a pcksh command:

    1. Click Commands, then click Add Command in the task pane.

    2. Specify a name, then click Finish.

    3. Select your new command, then click Modify Command.

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

  3. Add an Account User Group for the pcksh shell:

    1. Click Account Groups > User Groups, then click Add User Group in the task pane.

    2. Specify a name, then click Finish.

    3. Select your pcksh user group, then click Modify User Group.

    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 your Linux and UNIX hosts that have your permission to use the usrun pcksh command.

    5. Click Finish.

  4. Add a rule for the pcksh command:

    1. Click Rules, then click Add Rule in the task pane.

    2. Specify a name, then click Finish.

    3. Select your pcksh command, then drag it to your pcksh rule.

    4. Select your pcksh user group, then drag it to your pcksh rule.

    5. Select your pcksh rule, then click Modify Rule in the task pane.

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

    7. Click Finish.

  5. (Conditional) If your 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 your 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.

  1. Use the tool provided in the UNIX or Linux environment to set the user login shell to

    /usr/bin/cpcksh
    
  2. Add a cpcksh command:

    1. Click Commands > Add Command.

    2. Specify a name (for example, cpcksh shell), then click Finish.

    3. Select the name of the cpcksh command, then click Modify Command.

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

  3. Add a cpcksh Account User Group:

    1. Click Account Groups > User Groups, then click Add User Group in the task pane.

    2. Specify a name, then click Finish.

    3. Select your cpcksh user group, then click Modify User Group.

    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 your Linux and UNIX hosts that have your permission to use the cpcksh command.

    5. Click Finish.

  4. Add a cpcksh rule:

    1. Click Rules > Add Rule.

    2. Specify a name, then click Finish.

    3. Select your cpcksh command, then drag it to your cpcksh rule.

    4. Select your cpcksh user group, then drag it to your cpcksh rule.

    5. Select your cpcksh script, then drag it to your cpcksh rule.

    6. Select your cpcksh rule, then click Modify Rule in the task pane.

    7. 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 and from the drop-down menu. These settings allow subsequent commands to be executed without authorization checks whenever the user has had one command authorized.

    8. Click Finish.

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 are read from /etc/profile.pcksh. When the user issues a command that needs privileges to run, it is authorized through the Framework.

  1. Use the tool provided in the UNIX or Linux environment to set the users’ shell to

    /usr/bin/pcksh
    
  2. 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.

  3. (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 your 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.