EPM-UL installation

This guide provides the information to perform a basic installation of the Endpoint Privilege Management for Unix and Linux software.

📘

Note

• Endpoint Privilege Management for Unix and Linux or EPM-UL, refers to the product formerly known as PowerBroker for Unix and Linux. Endpoint Privilege Management for Linux or EPM-L, refers to the SaaS (cloud) product.
• Specific font and line spacing conventions are used to ensure readability and to highlight important information, such as commands, syntax, and examples.

Sample policy files

When you receive the EPM-UL install media, there are sample EPM-UL policy files in the /examples folder. These sample policy files include detailed explanations of what they do. You can use these files to learn how policy files are typically written for various scenarios. A readme_samples text file in that directory includes a brief description of each sample file.

Installation considerations

Endpoint Privilege Management for Unix and Linux is a non-intrusive software program that does not require kernel reconfiguration, a system reboot, or the replacement of system executable files. The items in this section contain information you should consider when planning your implementation.

⚠️

Important

The BeyondInsight integration is no longer supported. Instead, EPM-UL uses BeyondInsight for Unix & Linux and ElasticSearch.

ℹ️

Note

For information on the platforms and operating systems that are supported by Endpoint Privilege Management for Unix and Linux, see Supported platforms.

Flavor and release definitions

Flavor is a BeyondTrust term that defines a build of a BeyondTrust product, such as Endpoint Privilege Management for Unix and Linux, that is compiled and tested for a certain range of operating system versions and underlying hardware. For instance, when this guide was written, Endpoint Privilege Management for Unix and Linux was available for several flavors of Linux operating systems. The included README file describes which flavor is the right match for specific combinations of hardware and operating systems in the Release Identifier column. The release identifier is the flavor plus the version of the Endpoint Privilege Management for Unix and Linux distribution.

BeyondTrust product releases are uniquely identified by a string that indicates their hardware and software characteristics. This string contains the following information:

• BeyondTrust product
• Hardware architecture
• Flavor
• Major version number
• Minor version number
• Release number
• Build number
• Service pack number

An example version number in the extracted tarball directory path is: pmul_linux.x86-64_10.3.0-15

• pmul is the BeyondTrust product Endpoint Privilege Management for Unix and Linux.
• linux is the flavor.
• x86-64 is the hardware architecture.
• 10 is the major version number 3 is the minor version number 0 is the release number.
• 15 is the build number.

Functionality is identical for all releases with the same version number. Releases within a version denote a maintenance release and include new ports and resolved issues. Release notes describe the issues that are addressed by the release.

⚠️

Important

If you believe you are using the correct Endpoint Privilege Management for Unix and Linux version for the system but the installer is returning a flavor mismatch error, contact BeyondTrust Technical Support.

Interactive Versus Packaged Installation

All Endpoint Privilege Management for Unix and Linux flavors can be installed by using an interactive program that presents you with a series of options. Your choices determine the details of the Endpoint Privilege Management for Unix and Linux installation for a particular host.

The client registration facility can be used to automate the installation of new clients by downloading the default configuration from the primary license server. Options are defaulted within the interactive installation, and shared encryption keys are copied over.

For certain flavors, Endpoint Privilege Management for Unix and Linux can be installed by using package installers. Package installers enable you to choose the options once, and then install that configuration of Endpoint Privilege Management for Unix and Linux non-interactively on multiple identical hosts. Using package installers also takes advantage of the operating system’s installation management system, which tracks the source of installed files and enables their safe removal.

ℹ️

Note

For more information, see Supported platforms.

Interactive and packaged installations on the same computer

Although it is possible to combine interactive and packaged Endpoint Privilege Management for Unix and Linux installations on the same computer, we do not recommend this practice. If both interactive and packaged installations are present, and you remove the packaged installation, the shared libraries are removed even though they are needed by the interactive installation. This behavior is inherent in all package installations and is not specific to Endpoint Privilege Management for Unix and Linux.

In the case of SELinux, if you attempt to perform a package installation on a computer that already has an interactive installation present, the package installation is not allowed. The reason for this limitation is that the SELinux Endpoint Privilege Management for Unix and Linux packages can fail to install because RPM does not have the permissions to change SELinux file types that are already installed.

If you must combine interactive and packaged Endpoint Privilege Management for Unix and Linux installations on the same computer, follow these recommendations:

• For the interactive installation, use a prefix and suffix installation.
• Install the shared libraries for the interactive and packaged installations in separate directories, by doing one of the following:
  • In the interactive installation, specify an alternative shared library directory with the BeyondTrust built-in third-party library directory menu item.
  • Use the relocatable base directory feature of the package installer.

ℹ️

Note

Endpoint Privilege Management for Unix and Linux SELinux policies are no longer provided. When installing Endpoint Privilege Management for Unix and Linux on Red Hat Enterprise Linux (RHEL) 5 with SELinux enabled and using the targeted policy, Endpoint Privilege Management binaries run unconfined.

Prefix and suffix installations

Endpoint Privilege Management for Unix and Linux can be installed with prefixes or suffixes to create unique installations for multiple installs or for ease of identification.

ℹ️

Note

Prefixes and suffixes cannot be used with any of the package installers.

ℹ️

Note

For instructions about using prefixes and suffixes for an installation, see Prefix and suffix installation instructions.

Resource overhead

There are not any startup or shutdown programs associated with Endpoint Privilege Management for Unix and Linux. From a system resource perspective, a basic Endpoint Privilege Management for Unix and Linux session uses about the same overhead as a telnet session with additional front-end work for processing the policy security file. I/O logging can add the equivalent of another telnet session.

Instances of the Endpoint Privilege Management for Unix and Linux daemons, pbmasterd and pblocald, are requested by pbrun and are actually started by the superdaemon when a monitored task request is submitted to pbrun. Instances of the Endpoint Privilege Management for Unix and Linux log server daemon, pblogd, are actually started by the superdaemon. The superdaemon is inetd, xinetd, launchd, or SMF depending on the platform.

ℹ️

Note

In this guide, references to inetd, xinetd, launchd, and SMF are used interchangeably unless otherwise denoted.

For systems based on RedHat version 7+, xinetd is no longer installed by default, since it has been superceded by systemd, which is an init system. The installation program of Endpoint Privilege Management for Unix and Linux performs a check to see if systemd exists and is functional.

• If it exists, it configures Endpoint Privilege Management for Unix and Linux daemons to be managed by systemd.
• If systemd is not present, the installation program checks if xinetd is installed and running and displays a warning message if it is not.

Having the superdaemon start pblogd, pbmasterd, and pblocald when requested by pbrun is the normal way to initiate the Endpoint Privilege Management for Unix and Linux daemons. It is also possible to explicitly start the daemon as a persistent daemon.

ℹ️

Note

The terms monitored task and secured task are interchangeable.

SSL adds some startup overhead for certificate exchange and verification. The encryption overhead is slightly larger than self-contained encryption technologies (such as DES) because of the use of packet checksums by SSL.

ℹ️

Note

Endpoint Privilege Management for Unix and Linux requires 10 to 50MB of disk space, depending on the installation options selected.

Required utilities for EPM-UL

The Endpoint Privilege Management for Unix and Linux installer requires the following Unix and Linux utilities and built-in commands:

Installation directories

Endpoint Privilege Management for Unix and Linux is not sensitive about the location of its binary files; you can place them in any convenient directory. However, there are a few points to consider when you are selecting installation directories:

• It is important to install the Endpoint Privilege Management for Unix and Linux pbrun and pbssh programs in a directory that is in the user’s path.
• Online manuals (such as user man pages and Endpoint Privilege Management for Unix and Linux documentation) should be accessible from every computer to enable users to get online help for Endpoint Privilege Management for Unix and Linux programs.

Default directories

The following table lists various Endpoint Privilege Management for Unix and Linux components and their locations. The installation script uses these locations by default, but you can change them during installation. Usually /usr/local/bin is used for user programs and /usr/sbin for administrator and daemon programs (depending on the platform).

Default directories for Endpoint Privilege Management for Unix and Linux components

The default log directory varies by platform to match that platform’s conventions. The directories /usr/adm, /var/adm, and /var/log are used interchangeably throughout as the default location of the Endpoint Privilege Management for Unix and Linux log files.

Change /opt/pbul base directory

As seen in the previous table, files that Endpoint Privilege Management for Unix and Linux generates at runtime are created under /opt/pbul. To change this default location, use pbinstall's basedir menu to specify a directory location.

If there is no previous settings file, or if you are running pbinstall -i to ignore previous settings, changing basedir causes the following settings to be updated with the new location and enabled to ensure that runtime files do not end up in the old default location:

System file modifications

Endpoint Privilege Management for Unix and Linux does not replace any Unix and Linux files or binaries during installation, but it does modify the following system files:

• /etc/inetd.conf (or xinetd.conf, launchd, systemd or SMF configuration file)
• /etc/services

These files are automatically backed up as files with the same name and the extension .sybak.####.

The changes made to these files depend on whether a policy server host, run host, GUI host, log synchronization host, or log host is being installed. Depending on the selected installation options, each file has lines removed, added, or both.

For /etc/inetd.conf (or your xinetd.conf, launchd, or SMF configuration), the installer tries to determine the superdaemon configuration file that is used on the active system. Most systems use the superdaemon’s default configuration file name while the rest of the systems use a switch or command line format. This makes it possible to determine the superdaemon's configuration files that need to be configured. xinetd uses /etc/xinetd.conf and any specified includedir file directories.

ℹ️

Note

Removal of earlier releases of Endpoint Privilege Management for Unix and Linux with version 6.0 checks for and removes its xinetd configuration.

SMF is used on Solaris 10+ and uses a configuration database.

Starting with version 7.1.0, if the system Endpoint Privilege Management for Unix and Linux is being installed on is IPv6-capable and the configuration of inetd, xinetd, SMF (Solaris), is being performed, the super daemon configuration is set for IPv6 rather than IPv4.

Policy Files

/opt/pbul/policies/pb.conf (from v9.4.3+ and /etc/pb.conf prior to v9.4.3) is usually the root or entry point to the Endpoint Privilege Management for Unix and Linux policy tree. Although pb.conf can contain actual policy code, we recommend that you use it strictly as a list of include statements that reference other policy modules. Referencing other policy modules in the pb.conf file keeps a large policy tree manageable.

ℹ️

Note

For more information about policy files, see Create policy files.

Role-based policy database

With the introduction Endpoint Privilege Management for Unix and Linux version 9, there is a role-based policy database. Role-based policy simplifies creating policy.

• Policies are kept in structured records in a database, simplifying maintenance, decreasing system load, increasing throughput, and providing a comprehensive REST API to integrate policy management with existing customer systems and procedures.
• Simplifies bulk import and bulk export of data. After the data is in the database, it is much easier to provide management information, such as user entitlement reports. This can be used instead of policy script configuration to quickly and succinctly define, retrieve, and report on role based policy.

Default policies

A default policy is installed by default if an existing policy does not exist. The files pbul_policy.conf and pbul_functions.conf are created in the /opt/pbul/policies directory by default.

pbul_policy.conf is included in the main policy by default /opt/pbul/policies/pb.conf from v9.4.3+ and /etc/pb.conf prior to v9.4.3.

The default policy contains the following roles.

Helpdesk role

• Enabled by default. When invoking pbrun helpdesk, the role allows any user in HelpdeskUsers (default root) to initiate a Helpdesk Menu as root on any host in HelpdeskHosts (default submithost only). The actions include
  • Obtaining a list of processes (ps -ef)
  • Checking if a machine is available (ping )
  • Obtaining a list or current users on this host (who -H)
  • Displaying the Host's IP settings (ifconfig -a)

PBTest

• Enabled by default for all users on all hosts. The role allows pbrun pbtest to be used to check connectivity and the policy.

Controlled shells

• Enabled by default. The role allows users in ControlledShellUsers (by default the submituser) for runhosts in ControlledShellHosts (by default only submithost) to enable I/O logging for pbksh/pbsh. I/O logs are created by default in /tmp/pb....[pbksh|pbsh].XXXXXX. This role has a list of commands (empty by default) to elevate privileges for as well as a list of commands (empty by default) to reject.

Admin role

• Enabled by default. The role allows users in AdminUsers (by default root) to run any command on runhosts in AdminHosts (by default only submithost).

Demo role

• Disabled by default. The role allows users in DemoUsers (default all users) to run commands in DemoCommands (default id and whoami) as root on any host in DemoHosts (default all hosts).

Splunk role

Disabled by default. If enabled, only when pbrun is invoked, enables iologging (creating iologs in /pbiologs), sets default ACA rule, enables aca session history and sets iologcloseaction to a script sending records to Splunk.

Sudo role

Disabled by default, allows users in SudoUsers (only root, by default) to run any command on runhosts defined in SudoHosts (default submithosts).

This serves as a demo policy for the sudo wrapper which requires policy modification before it is installed. It illustrates what changes to start with to make all the sudo wrapper options available.

The policy ends by allowing all users to run any command as themselves without any privilege escalation.

Network and file encryption

Endpoint Privilege Management for Unix and Linux can encrypt data to help guard against attacks. Several encryption modes are supported. The installation script uses the pbkey program to create an encryption key in the key file, /etc/pb.key. This file must then be placed on all Endpoint Privilege Management for Unix and Linux systems in an Endpoint Privilege Management for Unix and Linux installation.

Because the pb.settings file is required to be in the /etc directory, the key file used to encrypt pb.settings must also be in the /etc directory.

Configure Third-Party Libraries

When Endpoint Privilege Management for Unix and Linux is configured with Kerberos, SSL, LDAP, or CURL, it requires the appropriate third-party libraries.

The installation provides Kerberos, SSL, LDAP, or CURL libraries that are designed to work with Endpoint Privilege Management for Unix and Linux. It is recommended that you install the third-party libraries. However, you can use your own third-party libraries.

⚠️

Important

Shared libraries can be adversely affected when both interactive and packaged Endpoint Privilege Management for Unix and Linux installations are present on the same computer. For more information, see Installation Process.

Use EPM-UL third-party libraries

If you have your own Kerberos, SSL, LDAP, or CURL libraries but wish to use Endpoint Privilege Management for Unix and Linux third-party libraries, you should do one of the following:

• Remove your libraries from /usr/lib or /lib and point to the Endpoint Privilege Management for Unix and Linux third-party libraries in /usr/lib/beyondtrust/pb or /usr/lib/beyondtrust/pb in pb.settings.
• Replace your third-party libraries with the Endpoint Privilege Management for Unix and Linux third-party libraries in /usr/lib or /lib and specify this directory in pb.settings.

Third-party library file names and locations

If you are installing Endpoint Privilege Management for Unix and Linux shared libraries, the following files are installed:

• Kerberos:
  • llibcom_err.so.3.0
  • libk5crypto.so.3.1
  • libkrb5support.so.0.1
  • libkrb5.so.3.3
  • libgssapi_krb5.so.2.2
• SSL:
  • libcrypto.so.1.1
  • libssl.so.1.1
• LDAP:
  • liblber-2.5.so.0.1.7
  • libldap-2.5.so.0.1.7****
• CURL:
  • libcurl.so.4.8.0

Shared library directory location for AIX and HP (PA RISC)

For AIX and HP (PA-RISC), the directory for installing third-party libraries must be in one of the following locations:

• /usr/lib/beyondtrust/pb
• /usr/lib
• /lib
• /usr/local/lib

If any other directory is specified, it is rejected with an error message that instructs you to use one of these directory locations.

Shared library file name for AIX

The notation used on AIX to specify LDAP libraries is different from other platforms. On AIX, for archived third-party libraries, you need to specify the shared object that is a member of the archive and add it to the file name.

The notation for default LDAP libraries is:

• /usr/lib/beyondtrust/pb/liblber-2.5.a(liblber-2.5.so.0)
• /usr/lib/beyondtrust/pb/libldap-2.5.a(libldap-2.5.so.0)

For example, if libcom_err.a.3.0 is an archive and shr.0.3.0 is the actual shared object, the file specification for the member of the archive is libcom_err.a.3.0(shr.0.3.0).

ℹ️

Note

For SSL and Kerberos, it is not necessary to alter the file name because the library is not an archive.

Use your own third-party libraries

If you have chosen to configure Endpoint Privilege Management for Unix and Linux with Kerberos, SSL, or LDAP, and do not load Endpoint Privilege Management for Unix and Linux built-in third-party libraries, you must specify your own shared library file names. If you have Kerberos, SSL, or LDAP libraries of your own in /usr/lib or /lib and you are using them for other applications, you need to use your libraries for Endpoint Privilege Management for Unix and Linux as well and not use any of the libraries in /usr/lib/beyondtrust/pb or /usr/lib/beyondtrust/pb. During the Endpoint Privilege Management for Unix and Linux installation, specify no for the install option Install BeyondTrust built-in libraries, and then enter the appropriate shared library directory and filename.

ℹ️

Note

For more information about the installation instructions, see Advanced Installation Instructions Using pbinstall.

Install third-party libraries in future installations

If you do not enable the third-party libraries during the Endpoint Privilege Management for Unix and Linux installation and in the future you decide to enable Kerberos, SSL, or LDAP in your Endpoint Privilege Management for Unix and Linux policy, then you must do the following:

• Install Endpoint Privilege Management for Unix and Linux third-party libraries or your own third-party libraries.
• In the pb.settings file, do one of the following:
  • If you are using the Endpoint Privilege Management for Unix and Linux third-party libraries, specify the directories to install the operating system third-party libraries in by setting the following keywords to specify the full path and library file names:
    • sharedlibkrb5dependencies
    • sharedlibssldependencies
    • sharedlibLDAPdependencies
    • sharedlibcurldependencies

If you are using your own third-party libraries, then perform the following actions.

• Specify the Kerberos library setting and provide the full path and library file names.
• Specify the SSL library setting and provide the full path and library file names.
• Specify the LDAP library setting and provide the full path and library file names.
• Specify the CURL library setting and provide the full path and library file names.
• Ensure that your libraries are listed in the correct order. For example, if lib1 is dependent on lib2, you must list lib2 first, followed by lib1.

Improve security

Additional configuration can improve the security of Endpoint Privilege Management for Unix and Linux.

Endpoint Privilege Management for Unix and Linux does not contain a Certificate Authority; therefore, certificates generated during install are self-signed, and cannot be used to properly identify the host. Creating and deploying proper x509 certificates, with hostname information in the Subject Alternative Name field, allows Endpoint Privilege Management for Unix and Linux hosts to properly identify hosts.

TLS clients can verify the server’s certificate and hostname by adding the ValidateServer option to the ssloptions keyword in /etc/pb.settings. For TLS, pbmasterd and pblocald are clients to pblogd. Additionally, servers can validate the certificates and hostname of the client hosts by adding the ValidateClients option to the ssloptions keyword in /etc/pb.settings.

Configure Endpoint Privilege Management for Unix and Linux to use the SSLFirst keyword in /etc/pb.settings. This keyword must have the same value on all hosts in the Endpoint Privilege Management for Unix and Linux domain. The SSLFirst keyword results in SSL/TLS occurring prior to any Endpoint Privilege Management for Unix and Linux proprietary protocol negotiations (that use symmetric keys), reducing any issue with compromised symmetric network encryption keys.

The TLS ciphers should be changed to disallow anonymous ciphers.

Edit the sslpbruncipherlist and sslservercipherlist entries in /etc/pb.settings:

sslpbruncipherlist      TLSv1.2:!SSLv2:!3DES:!MD5:!ADH:!AECDH:!DHE:!eNULL:@STRENGTH
sslservercipherlist     TLSv1.2:!SSLv2:!3DES:!MD5:!ADH:!AECDH:!DHE:!eNULL:@STRENGTH

Edit the ssl.cipher-list entry in /usr/lib/beyondtrust/pb/rest/etc/pblighttpd.conf:

ssl.cipher-list          = " TLSv1.2:!SSLv2:!3DES:!MD5:!ADH:!AECDH:!DHE:!eNULL:@STRENGTH"