Endpoint Privilege Management for Unix and Linux Overview

To write effective Endpoint Privilege Management for Unix and Linux security policy files, it is helpful to understand how Endpoint Privilege Management for Unix and Linux works. A typical Endpoint Privilege Management for Unix and Linux configuration consists of the following primary components: pbrun, pbmasterd, pblocald, and pblogd. Each of these components is described below. It is possible to install all of these components on a single machine or distribute them among different machines. For optimal security, the Policy Server host and log hosts should be separate machines that are isolated from normal activity.

Endpoint Privilege Management for Unix and Linux Components

As shown in the figure below, the machine from which a task is submitted is referred to as the submit host. The machine on which security policy file processing takes place is referred to as the policy server host. The machine on which a task actually executes is referred to as the run host. The machine on which event log records and I/O logs are written is referred to as the log host. (Although we highly recommend the use of pblogd, it is an optional component.)

How Endpoint Privilege Management for Unix and Linux Works

Endpoint Privilege Management for Unix and Linux Task Processing

In the context of Endpoint Privilege Management for Unix and Linux, there are two types of task requests: secured and unsecured.

Secured task requests must undergo security validation processing before they can be run. Endpoint Privilege Management for Unix and Linux must process these tasks.

Unsecured tasks do not undergo security validation processing. These tasks do not represent a potential threat to the system and so do not fall under a company’s security policy implementation. The operating system handles unsecured tasks. Endpoint Privilege Management for Unix and Linux is not involved in the processing of unsecured tasks.

Secured Task Submission to SSH-Managed Devices - pbssh

Secured tasks can also be submitted through pbssh. pbssh is the Endpoint Privilege Management component used to access SSHmanaged devices where Endpoint Privilege Management is not installed (routers, firewalls, Windows devices, or Unix/Linux devices where Endpoint Privilege Management is not installed). pbssh connects to the target device using the SSH configuration.

Task Submission - pbrun

All secured tasks must be submitted through pbrun, the Endpoint Privilege Management for Unix and Linux component that receives task requests. A separate pbrun process starts for each submitted secured task request. Any task that needs to undergo Endpoint Privilege Management for Unix and Linux security processing (that is, a secured task) must be submitted through pbrun. A company’s security policy implementation may be compromised if the use of pbrun for secured tasks is not enforced.

pbrun must be installed on any machine from which a user can submit a secured task request.

Security Policy File Processing - pbmasterd

pbmasterd is responsible for applying the security rules as defined in the Endpoint Privilege Management for Unix and Linux security policy files that make up a company’s network security policy. In other words, it is pbmasterd that performs security verification processing to determine if a request is accepted (that is, allowed to execute) or rejected (that is, not allowed to execute), based on the logic in the Endpoint Privilege Management for Unix and Linux security policy files. If a request is rejected, then the result is logged and processing terminates. If a request is accepted, then it is immediately passed to pblocald for execution.

If the pblogd component (below) is not used, then pbmasterd waits for the pblocald process to complete. If pblogd is used, then pbmasterd terminates after the request is passed to pblocald. A separate pbmasterd process starts for each secured task request that is submitted.

During security verification processing, the first "accept" or "reject" condition that is encountered causes security policy file processing to terminate immediately. No further security verification processing is performed.

Task Execution - pblocald

pblocald is normally responsible for executing task requests that have passed security verification processing and have been accepted by pbmasterd on the run host (when the run host is a different host than the submit host). After a task request is accepted, it is immediately passed from pbmasterd to pblocald. By default, pblocald executes the task request as the user that is specified in the policy variable runuser. This is typically a privileged user such as root, a database administrator, or a web server adminstrator. All task input and output information is piped back to pbrun. In addition, pblocald logs pertinent task information to the Endpoint Privilege Management for Unix and Linux Event Log using pbmasterd or pblogd. This depends on how Endpoint Privilege Management for Unix and Linux has been deployed. The run host can also record task keystroke information to an Endpoint Privilege Management for Unix and Linux I/O log and again through pbmasterd or pblogd. Again, this depends on how Endpoint Privilege Management for Unix and Linux has been deployed.

Task Execution - pbrun

When the run host and submit host are on the same machine, pbrun can directly execute a secured task. This optimizes out the extra network connections to pblocald.

Logging - pblogd

pblogd is responsible for writing event and I/O log records. pblogd is an optional Endpoint Privilege Management for Unix and Linux component. If pblogd is not installed, then pbmasterd writes log records directly to the appropriate log files rather than passing them off to pblogd. In addition, without pblogd installed, pbmasterd must wait for the pblocald process to complete. If the pblogd component is used, then pbmasterd normally terminates when task execution starts and pblocald sends its log records directly to pblogd.

Using pblogd optimizes Endpoint Privilege Management for Unix and Linux processing by:

• Centralizing the writing of log records in a single, dedicated component
• Eliminating the need for the pbmasterd process to wait for task execution to complete