Privileged User Manager provides a number of shells and functions that are installed as part of the Command Control Agent.
The rush and crush 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.
Name of the shells differ in the SLES environment:
Crush is normally used to audit users who do not need any additional privileges. With Novell Privileged User Manager, you can change a user’s login shell to crush (/usr/bin/crush), then configure a Command Control rule to authorize crush and enable session capture. When the users log in, the commands are captured and audited through Novell Privileged User Manager. Auditing is transparent to the users, and the users perceive no change.
Rush 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 rush 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:
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>
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.
Click
on the home page of the console.Add a password command:
Click
, then click in the task pane.Specify a name, then click
.Select your new command, then click
.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 *
Click
.Add an Account User Group for the password command:
Click
> , then click in the task pane.Specify a name, then click
.Select your password user group, then click
.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.
Click
.Add a rule for the password command:
Click
, then click in the task pane.Specify a name, then click
.Select your password command, then drag it to your password rule.
Select your passwd user group, then drag it to your password rule.
Select your password rule, then click
in the task pane.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
.Authorize: Select
, then select .Run User: Specify root.
Click
.Repeat this process for each command you want your users to run with the usrun command.
To use the rush 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 rush for the appropriate users.
Click
on the home page of the console.Add a rush command:
Click
, then click in the task pane.Specify a name, then click
.Select your new command, then click
.Fill in the following fields:
Description: Explain the purpose of this command. Specify something similar to the following:
When a user submits a usrun rush command or a usrun shell command, the command is rewritten to /usr/bin/rush. 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/rush -o audit 1
Commands: Specify the following commands, each on a separate line.
rush shell
Click
.Add an Account User Group for the rush shell:
Click
> , then click in the task pane.Specify a name, then click
.Select your rush user group, then click
.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 rush 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 rush command.
Click
.Add a rule for the rush command:
Click
, then click in the task pane.Specify a name, then click
.Select your rush command, then drag it to your rush rule.
Select your rush user group, then drag it to your rush rule.
Select your rush rule, then click
in the task pane.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 rush 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 5.8.3, Setting the Command Risk.
Session Capture: Select
.Authorize: Select
, then select .Run User: Specify root.
Click
.(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 5.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 5.9, Scripts and rush Illegal Commands Script.
This method of integration provides the most auditing functionality. By changing the user’s shell to the crush client instead of the rush 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 crush client, which executes as a normal Korn shell. A request is sent to the Command Control Manager for authorization. You must define a crush 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.rush. 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/crush
Add a crush command:
Click
> .Specify a name (for example, crush shell), then click .
Select the name of the crush command, then click
.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/crush and the user logs in, a Command Control request is sent with a submitting command of -crush to indicate login. The user’s login shell is rewritten to /usr/bin/rush. 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/rush -o audit 1
Commands: Specify the following:
-crush
Click
.Add a crush Account User Group:
Click
> , then click in the task pane.Specify a name, then click
.Select your crush user group, then click
.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 crush command.
Users: Specify the usernames of the users on your Linux and UNIX hosts that have your permission to use the crush command.
Click
.Add a crush rule:
Click
> .Specify a name, then click
.Select your crush command, then drag it to your crush rule.
Select your crush user group, then drag it to your crush rule.
Select your crush script, then drag it to your crush rule.
Select your crush rule, then click
in the task pane.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/crush 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
.Authorize: Select
, then select 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.Click
.You can change the user’s login shell to the rush 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 rush client executes as a normal Korn shell. Functions and aliases that replace normal system commands are read from /etc/profile.rush. 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
/usr/bin/rush
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.rush 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.rush 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:
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 rush shell cannot run these commands, even if they are root.
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 rush shell and performs remote authorization. For example:
#!/usr/bin/rush set –o remote passwd $*
This script executes the rush client, sets it to use Command Control, and executes the passwd command.