7.3 Privileged Access to UNIX and Linux

Using Privileged Account Manager you can provide UNIX and Linux users with controlled access to privileged commands in a secure manner across the enterprise. You can enable complete lockdown of user privilege by providing rules to determine the commands that are authorized to run, and a powerful account delegation feature that removes the need for common access to the root account.

You can provide access to UNIX, Linux, Network devices and Mainframe computers in the following ways:

pcksh and cpcksh: Using these shells, you can provide privileged access to UNIX, Linux, Mainframe and network devices and monitor the actions performed in the target machine in the form of keystrokes. These shells are based on the Korn shell (ksh) and are installed as part of the Command Control Agent.

For information about configuring pcksh and cpcksh, see pcksh and cpcksh respectively.
usrun Command: Using this command, you can provided privileged access to specific UNIX or Linux command. This package is installed as part of the Command Control Agent.
Secure Shell Relay (SSH Relay): Using this method, you can provide access to the target SSH machine through a standard SSH client.
SSH Web Relay: The functionality provides the benefit of achieving SSH relay to target servers without a requirement of installation of a client or an agent as the SSH session can be achieved in the web browser itself. This functionality requires an "Agentless module" to be installed on Privileged Account Manager Linux manager. For more information, see Secure Shell Web Relay.
Application SSO: Using this method, you can allow user to access UNIX, Linux, Mainframe and network device using any protocol, such as SSH, Telnet, and so on.

For information about configuring application SSO, see Application SSO.

Based on the information in the following table, you can choose the method to establish privileged session in Unix or Linux system:

Methods	Audit	Video Capture	Privileged Access	Live Session View	Command Risk & Automatic Session Disconnect	Access Through		Authentication Through
Methods	Audit	Video Capture	Privileged Access	Live Session View	Command Risk & Automatic Session Disconnect	SSH Client	User Console	System Account	Privileged Account Manager Account
pcksh (Agent- based)	_{(Audits all the user actions in the privileged shell)}
cpcksh (Agent- based)
usrun (Agent- based)	_{(Audits only the commands that has usrun as a prefix)}
SSH Relay (Agentless)		_{(Session replay* of SSH session along with video capture of X11 window.)}
SSH Web Relay (Client less)

Session Replay: Session replay is replay of the SSH user’s terminal input and output.

7.3.1 Workflow to Configure UNIX and Linux Privileged Sessions

The generic workflow to configure the UNIX and Linux privileged sessions are as follows:

Register the agent (Conditional)

If you are using cpcksh, pcksh, or usrun methods, you must register the agent to the Framework Manager. For steps to register an agent, refer Installing and Registering a Framework Agent
Add the Privileged Accounts of SSH Resources

If you are using SSH Relay, you must add SSH resource and add its privileged account credentials. For steps to create a SSH resource and its credentials, see the Contextual Help of Credential Vault.
Add a User Group (Optional)

Add a user group with a list of UNIX or Linux system users, who are intended to get privileged access. For steps to add a user group, refer Adding a User Group.
Add and Modify the Command

For steps to add a command, see Adding a Command. For SSH relay, you can also use the preloaded SSH Session command instead of adding a new command.

For steps to modify a command, see Modifying a Command.
Add a Rule

For steps to add a rule, see Adding a Rule.

NOTE:Ensure that you choose the correct value for the Run User. Based on the value of the Run User, the user gets appropriated privileged access.
Add Commands and User Groups to the Rule

After creating the rule, drag and drop the appropriate command and user group to the rule.

After making appropriate configurations in the Privileged Account Manager, you can access the target host using the SSH Client or User console appropriately.

7.3.2 Agent-Based Session Management in Unix and Linux

Privileged session and session capture can be achieved through the following methods:

pcksh

pcksh is used by administrator to grant privileges to a non-privileged system user, such as the ability to run commands as root and to perform a complete session capture of all the user actions. A user logs in as a non-privileged user, then issues a usrun pcksh command to access the root ksh shell and all the user actions in this shell are audited.

In addition, you can also configure rules to set up command risks and disconnect the session when executing specific commands.

Privileged Session Using pcksh

Using pcksh method the administrator can grant privileged session to a non-privileged system user and all the user action in the privileged session are captured.

Configuring pcksh for a Privileged Session

To grant privileged session to a non-privileged system user, the administrator must configure pcksh privileged session in Privileged Account Manager. For steps to configure the pcksh privileged session in Privileged Account Manager, see Work Flow to Configure Privileged Access for Windows

Accessing pcksh for a Privileged Session

To access pcksh privileged session in Linux or UNIX system perform the following,

Log into the UNIX system as a non-privileged user.
Use usrun command to gain privileged shell access to perform administrative functions.

For example, specify usrun pcksh or usrun shell command. The command is rewritten to /usr/bin/pcksh and Command Control Audits set to 1 based on the policy created in Privileged Account Manager.
Execute the commands that require privileged access and perform the required operations in the UNIX or Linux system. These actions that are performed within the pcksh shell are audited based on the Command Control policy and can be viewed in Command Control Reports.

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

You can also define illegal commands, including built-in shell commands, in a script assigned to the rule.

Usage Scenario

Consider a scenario where the administrator has to provide privileged access to a part of the user session and monitor that privileged session.

For this scenario, the administrator must perform the following configuration in the command control:

Register the agent to Privileged Access Manager
Add a pcksh command pcksh_cmd with the following field values:

Description: Explain the purpose of this command. For example, 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: /usr/bin/pcksh -o audit 1

Commands:

pcksh

shell
Create a user group pcksh_usrgrp with the following field values:

Description: Explain the purpose of the user group. For example, 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 thepermission to use the usrun pcksh command.
Add a rule pcksh_rule with the following field values:

Description: Explain the purpose of the rule. For example, 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.

Session Capture: Select On.

Authorize: Select Yes, then select Stop from the drop-down menu.

Run User: Specify root.
Drag and drop the command pcksh_cmd and user group pcksh_usrgrp to the rule pcksh_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

Log into the Linux or UNIX system as a non-privileged user.
Enter the command usrun pcksh to start a privileged session.

All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.

Complete Session Control Using pcksh

You can use pcksh to get complete session capture of the non-privileged UNIX or Linux system user. For complete session capture of the user, the user’s login shell should be modified to pcksh client. The pcksh client executes commands as a normal Korn shell.The functions and the 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.

Configuring pcksh for Complete Session Capture

To get complete session capture using pcksh, the administrator must make appropriate configurations in Privileged Account Manager. For steps to configure the pcksh in Privileged Account Manager, see Work Flow to Configure Privileged Access for Windows

Accessing pcksh for Complete Session Capture

To access pcksh for complete session capture perform the following,

Log into the UNIX or Linux system as a non-privileged user.
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.

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.

cpcksh

cpcksh is used to audit the complete user’s session. With NetIQ Privileged Account 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 Account Manager.

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.

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.

Configuring cpcksh for Complete Session Capture

To get complete session capture using cpcksh, the administrator must make appropriate configurations in Privileged Account Manager.

Accessing cpcksh for Complete Session Capture

To access cpcksh for complete session capture perform the following,

Log into the UNIX or Linux system as a non-privileged user.
Use the tool provided in the UNIX or Linux environment to set the user login shell to
```
/usr/bin/cpcksh
```
Perform the required operation and all these user actions are audited and can be viewed in Command Control Reports.

Usage Scenario

Consider a scenario where the administrator has to provide a privileged session and complete session when a non-privileged user logs in.

For this scenario, the administrator must perform the following configuration in the command control:

Register the agent to Privileged Access Manager
Add a pcksh command cpcksh_cmd with the following field values:

Description: Explain the purpose of this command. For example, 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: /usr/bin/pcksh -o audit 1

Commands:

-cpcksh
Create a user group cpcksh_usrgrp with the following field values:

Description: Explain the purpose of the user group. For example, 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 thepermission to use the usrun pcksh command.
Add a rule cpcksh_rule with the following field values:

Description: Explain the purpose of the rule. For example, 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.
Drag and drop the command cpcksh_cmd and user group cpcksh_usrgrp to the rule cpcksh_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

Log into the Linux or UNIX system as a non-privileged user.
Use the tool provided in the UNIX or Linux environment to set the users’ shell to the following:
```
/usr/bin/cpcksh
```
Perform the required action in the Linux or UNIX system.

All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.

Secure Shell Relay

Secure Shell Relay (SSH Relay) provides the ability to access privileged accounts using a standard SSH client. This feature provides the ability to access Privileged Account Manager functionality without an agent for Privileged Account Manager on the target host. SSH Relay allows users to connect to a remote host by using secure shell without knowing the privileged account credentials such as password or identity certificate of the user.

SSH Relay session videos can be captured only if the Privileged Account Manager is in Linux environment.

Configuring an SSH Relay Session

The packages are:

SSH Relay Agent
SSH Agent

SSH Relay listens on port 2222. You need to verify port 2222 is assigned for hosts running the SSH Relay Agent package.

Accessing an SSH Relay Session

After making appropriate SSH relay configuration, you can access the SSH relay session in the following ways:

Accessing an SSH Relay Session from My access console

Click on home icon on the new Administration console.
Specify the username and password to log in to Privileged Account Manager and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the SSH Relay session as it opens in > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

Accessing an SSH Relay Session from SSH Client

You can initialize an SSH relay session by using the following command:

ssh -t -p 2222 <PUMframeworkuser@sshrelayhost> <root@hostname>

To initialize an SSH relay session with X11 forwarding, use the following command:

ssh -X -t -p 2222 <PUMframeworkuser@sshrelayhost> <root@hostname>
A list of all the available SSH sessions are displayed. Enter the appropriate option to start the respective SSH relay session and provide the credentials of the SSH Relay user.

NOTE:When you exit from the current SSH Relay session, all the available SSH Relay sessions are displayed again enabling you to connect to a different target system.

Usage Scenarios for Agent-Bases Secure Shell Relay

Scenario 1:

Consider a scenario where the administrator has to provide privileged access to a Privileged Account Manager user.

For this scenario, the administrator must perform the following configuration in the command control:

Create an SSH type Credential Vault resource for the Linux or UNIX system and add the respective credentials.
Add the ssh_relay_rule rule with the following field values:

Session Capture: Select On.

Authorize: Select Yes and select Stop if authorized.

Use the drop-down list below to define what happens next:
- Blank: Checks the next rule in the hierarchy.
- Stop: No more rules are checked for the command.
- Return: The next rule to be checked is up one level in the hierarchy.
- Stop if authorized: If Authorize is set to Yes, no more rules are checked for the command.
- Stop if unauthorized: If Authorize is set to No, no more rules are checked for the command.
Account Domain: <Credential Vault SSH Resource Name>

Credentials: Select a credential from the drop-down list. Run User and Run Host are automatically populated based on the selection.
Drag and drop the preloaded SSH Session command to the ssh_relay_rule rule.

After the administrator configures the authorization rule in Privileged Account Manager, the Privileged Account Manager user can gain privileged session as follows:

Click on home icon on the new Administration console.
Specify the username and password to log in to Privileged Account Manager and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the SSH Relay session as it opens in > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

Scenario 2:

Consider a scenario where the administrator has to provide privileged access with X11 application access to a Privileged Account Manager user.

For this scenario, the administrator must perform the following configuration in the command control:

Create a resource for the Linux or UNIX system and add the respective credentials.
Add a rule ssh_relay_rule with the following field values:

Session Capture: Select On.

X11 Enable: Select Yes.

Capture the X11 application videos using the global videos settings.

Authorize: Select Yes and select Stop if authorized.

Use the drop-down list below to define what happens next:
- Blank: Checks the next rule in the hierarchy.
- Stop: No more rules are checked for the command.
- Return: The next rule to be checked is up one level in the hierarchy.
- Stop if authorized: If Authorize is set to Yes, no more rules are checked for the command.
- Stop if unauthorized: If Authorize is set to No, no more rules are checked for the command.
Account Domain: <Credential Vault SSH Resource Name>

Credentials: Select the required resource from the drop-down list. The Run User is automatically populated with the domain user provided in the resource.

Run Host: <Resource Name>
Drag and drop the preloaded command SSH Session to the rule ssh_relay_rule.

After the administrator configures the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as follows:

Log in using the Privileged Account Manager user credentials and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the SSH Relay session as it opens in Home > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

Scenario 3:

Consider a scenario where the administrator has to provide access to multiple Privileged Account Manager users with a single command control rule. The framework user gets access to the target resource with the same user account name only if this user account is also available in the target resource.

NOTE:In this case, the user accounts need not be added to the Credential Vault SSH Resource. If there are credentials created in the Credential Vault with the same name as the Privileged Account Manager login user name, login to the target server using these passwords.

For this scenario, the administrator must perform the following configuration in the command control:

Create a resource for the Linux or UNIX system.
Add a rule ssh_relay_rule with the following field values:

Session Capture: Select On.

Authorize: Select Yes and select Stop if authorized.

Use the drop-down list below to define what happens next:
- Blank: The next rule in the hierarchy is checked.
- Stop: No more rules are checked for the command.
- Return: The next rule to be checked is up one level in the hierarchy.
- Stop if authorized: If Authorize is set to Yes, no more rules are checked for the command.
- Stop if unauthorized: If Authorize is set to No, no more rules are checked for the command.
Run User: Submit User

Run Host: <Credential Vault SSH Resource Name>
Drag and drop the preloaded command SSH Session to the rule ssh_relay_rule.

After the administrator configures the authorization rule in Privileged Account Manager, the Privileged Account Manager user can gain access to the session as follows:

Log in using the Privileged Account Manager user credentials and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the SSH Relay session as it opens in > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

Scenario 4:

Consider a scenario where the administrator has to provide access of a specific user to a Privileged Account Manager user.

NOTE:You can specify the Run User as an account name or a Command Control user group containing the list of account names. The Run Host can be a specific target host name or a Command Control Host Group containing the list of target names. The target host names are the SSH type Credential Vault resource names.

For this scenario, the administrator must perform the following configuration in the command control:

Create a resource for the Linux or UNIX system.
Add a rule ssh_relay_rule with the following field values:

Session Capture: Select On.

Authorize: Select Yes and select Stop if authorized.

Use the drop-down list below to define what happens next:
- Blank: The next rule in the hierarchy is checked.
- Stop: No more rules are checked for the command.
- Return: The next rule to be checked is up one level in the hierarchy.
- Stop if authorized: If Authorize is set to Yes, no more rules are checked for the command.
- Stop if unauthorized: If Authorize is set to No, no more rules are checked for the command.
Run User: <Credential name from SSH Resource>/<Command Control User Group containing list of credential name>

Run Host: <Credential Vault SSH Resource Name/Host Groups>
Drag and drop the preloaded command SSH Session to the rule ssh_relay_rule.

After the administrator configures the authorization rule, the Privileged Account Manager user can gain access to the session as follows:

Log in using the Privileged Account Manager user credentials and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the active Remote Desktop Protocol Web Relay session as it opens in > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

7.3.3 Agentless Session Management in Unix and Linux

Infrastructure and application monitoring is shifting from an agent-based approach to an agentless one. Agentless monitoring holds the promise of cheaper and easier-to-maintain monitoring technology. Non-Windows systems is to use Virtual Agents to collect state and performance data from those resources. When using Virtual Agents, there is no necessity to deploy any software on the managed systems. Instead, REST API calls are made to the systems to capture data or invoke an action are made using common interfaces supported by the managed systems.

Secure Shell Web Relay

The functionality provides the benefit of achieving SSH relay to target servers without a requirement of installation of a client or an agent as the SSH session can be achieved in the web browser. This functionality requires an Agentless module to be installed on Privileged Account Manager Linux manager.

NOTE:You cannot add scripts when you are using SSH Web Relay.

Prerequisite

Ensure that the agentless module is installed.

The agentless component of Privileged Account Manager (agentless) is supported only on Windows, SLES 12 (64-bit), SLES 15 (64-bit), Oracle Linux 8 (64-bit), or RHEL 8 (64-bit).
NOTE:
- For Oracle Linux 8 (64-bit) and RHEL 8 (64 bit), install the redhat-lsb-core package.
- For SLES 12 (64-bit) and SLES 15 (64-bit), install the lsb-release package.
- You must install libpango and libcairo, and the dependent packages for both SLES and RHEL. Additionally for RHEL alone install dejavu-sans-fonts.

Advantages of configuring the secure shell web relay are:

You can configure SSH Web Relay for Linux and Unix machines to allow users to remotely access these machines without the privileged account credentials.
This method is beneficial if you do not want any operating system installed software or client.
Removes the requirement of JMobaXterm to help application to be launched on a client desktop by using resources that are hosted a remotely.
You can administer the active SSH Web Relay session in real time as it opens in the My Access page.

Configuring the Secure Shell Web Relay

You can configure a SSH Web Relay for Unix and Linux machines to allow users to remotely access these machine without the privileged account credentials. After a SSH Web relay is configured by an administrator, the user gets an elevated access to target Linux and Unix machines over SSH using a web console and can access the privileged session as follows:

Log in using the Privileged Account Manager user credentials and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the active SSH Web Relay session as it opens in Home > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

Usage Scenario for Agentless Secure Shell Web Relay

Scenario 1

Consider a scenario where the administrator has to provide privileged access to Linux or UNIX system and the Privileged Account Manager user can access the session from the same browser itself. For this scenario, the administrator must perform the following configuration in the Access Control.

Create an SSH type Credential Vault resource for the Linux or UNIX system and add the respective credentials.
Click Users, add the users (LDAP or Local) which will be using the resource.
Click Access Control > User Roles and create a user group and all the users which will use the resource.
Click Access Control > Resource Pools and create a resource group. Add the SSH Vault for Agentless SSH Servers.
Click Access Control > Assignment and create SSH Web and add the user group and resource pool you created in the 2 and 3 step to it.
Select the permissions you want to give.
Click Finish.

After the administrator configures the authorization rule in Privileged Account Manager, the user can gain privileged session as follows:

Log in using the Privileged Account Manager user credentials and click Login.
Click > My Access and click the launch icon before the appropriate resource name.
You can administer the active SSH Web Relay session as it opens in Home > Active Sessions. The administrator audits the user actions in this privileged session and views these reports in the administration console.

The administrator audits the user actions in this privileged session and views these reports in the administration console.

7.3.4 Command Management

You can gain privileged access to a specific command using the following method:

usrun

The usrun command is a function provided by Privileged Account Manager for executing specific commands in the UNIX and Linux system with privileges.

By using the usrun command, you can elevate the access privilege of a specific command based on the policies defined in Privileged Account Manager. You must specify usrun before any command in the Linux or UNIX system to elevate the access rights of that command.

When you use usrun command, Privileged Account Manager audits only the commands that are appended with the usrun and other operations in the session are not audited.

usrun Command Syntax

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 server or the agent name specified in the Hosts console.
<command>	Specifies the command to pass to the Command Control Manager.

Configuring usrun Command for Privileged Access

To provide privileged access to a specific set of command, you must make appropriate configurations in Privileged Account Manager.

Accessing usrun for Privileged Access

To use usrun to get privileged access,

Log into the target system as a non-privileged user
Execute the commands with prefix usrun to get privileged access to the command. For example, usrun passwd.

Privileged access is provided only to the specific set of commands that you have defined in the usrun Command Control policy.
All the privileged actions that is the commands executed with the prefix usrun are audited and can be viewed in the Command Control Reports.

Usage Scenario

Consider a scenario where the administrator has to provide a privileged access to a specific command such as passwd.

For this scenario, the administrator must perform the following configuration in the command control:

Register the agent to Privileged Access Manager.
Add a command and name it usrun_pwd_cmd with the following field values:

Description: Explain the purpose of this command. For example:

Allows a user to submit a usrun passwd command to change account passwords.

Commands: passwd *
Create a user group usrun_pwd_usrgrp with the following field values:

Description: Explain the purpose of the user group. For example:

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 thepermission to use the usrun passwd command.
Add a rule usrun_pwd_rule with the following field values:

Description: Explain the purpose of the rule. For example:

Matches users who submit a usrun passwd command. It authorizes their session and sets the run user to root.

Session Capture: Select On.

Authorize: Select Yes, then select Stop from the drop-down menu.

Run User: Specify root.
Drag and drop the command usrun_pwd_cmd and user group usrun_pwd_usrgrp to the rule usrun_pwd_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged access as following:

Log into the Linux or UNIX system as a non-privileged user.
Execute the command usrun passwd.

You can access the passwd command with elevated access and this user action is recorded and the administrator can view these reports in the admin console.

7.3.5 Enhanced Access Control

Command Control policies give you additional options to control the execution of commands. For example, you can use a policy to restrict the rights and roles of a command so that the command works only for one particular directory, file, network address, or system call.

Prerequisite

For using Enhanced Access control, you must install 32bit glibc library in 64 bit RHEL agent and manager.

Configuring a Command Control Policy

A command control policy is defined by using the policy script arguments. A policy script argument specifies the access rights of the applications based on the path, network, and capability.

On the home page of the console, click Command Control.
From the Command Control Sample Scripts, add the Enhanced Access Control Policy script.
Drag and drop the Enhanced Access Control Policy script from Scripts to Authorizing Rule.
Click the Authorizing Rule and access the Script Arguments.
Create a script argument with a name policy and add that policy to the Value field.

Configuring a Path Policy

A Path policy is a type of command control policy that restricts an application from accessing a specific directory based on the path.

The syntax of a Path policy is as follows:

path [owner] <path> <capability:capability:!capability>

owner specifies the file or directory ownership that should match with the current user ID.

path specifies a particular directory based on the path. Replace path with any of the following options:

Table 7-1 Path Options

Option	Description
/dir/file	Specifies the file that the application can access in the /dir/directory.
/dir/	Specifies the directory that the application can access.
/dir/f*	Specifies a file that begins with f in the /dir/directory that the application can access.
/dir/*	Specifies that the application can access all the files in the /dir/ directory.
/dir/**	Specifies that the application can access all the files and the subdirectories within the /dir/directory.
/dir/**/	Specifies that the application can access all subdirectories that are recursively searched for in the /dir/directory.
/dir/*/	Specifies that the application can access all the files that are recursively searched for in any subdirectory within the /dir/directory.

capability specifies the rights of the application. You can use the ! symbol in the syntax to denote a logical not. For example, all:!write grants all the rights except the write role.

Replace capability with any of the following options:

Table 7-2 Capability Options

Option	Description
privperms	Enables the application with the read, write, and ownership permissions for the specified directory or file. The privperms command limits two areas of functionality: Using the chmod command to set a file to setuid or setgid. Using the chown or chgrp command to change the ownership of a file.
perms	Enables the application to assign the permissions of a specified directory or file.
read	Enables the application to assign the read permission for a specified directory or file.
write	Gives the application the create and write permissions for the specified directory or file.
unlink	Gives the application the deletion rights for the specified directory or file.
mknod	Enables the application to create system files in the specified directory.
exec	Enables the application to execute the shared files and files for which the application does not have read and write permission.
unsafe	Enables the application to execute any file that does not inherit the policy.
link	Enables the application to create a symbolic link or hard link to another file.
log[=<0-9>]	Enables the application to audit system calls, with an optional risk value of 0-9.
all	Enables the application to have all permissions.

You can use wildcards, regular expressions, and strings in the Path policy. For example, using the word default in the following example specifies the default policy.

path default all:log 
path /opt/oracle/private/** !all:log=9

When administering EAC policy, do not restrict the following permissions to the listed folders:

Read / Write Permission	Read Permission
/tmp/	/etc/resolv.conf
/dev/zero	/etc/hosts
/dev/null	/etc/passwd
/dev/tty	/etc/groups
/devices/**	/dev/random
/proc/<pid>/**	/dev/urandom
/tmp/**	/etc/utmp
/var/tmp/**	/etc/utmpx
	/usr/share/**
	/usr/lib/**
	/lib/**
	/usr/lib64/**
	/lib64/**

NOTE:Solaris 9/sbin/sh is a static binary and therefore cannot enforce EAC.