EPM-UL installation | EPM-UL

This guide provides the information to perform a basic installation of the EPM-UL software.

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

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

Flavor and release definitions

Flavor is a BeyondTrust term that defines a build of a BeyondTrust product, such as EPM-UL, that is compiled and tested for a certain range of operating system versions and underlying hardware.

For instance, EPM-UL is 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 EPM-UL 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 EPM-UL.
• 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.

Interactive versus packaged installation

All flavors can be installed by using an interactive program that presents you with a series of options. Your choices determine the details of the 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, install EPM-UL using package installers.

• Package installers enable you to choose the options once, and then install that configuration 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.

Interactive and packaged installations on the same computer

Although it is possible to combine interactive and packaged 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 EPM-UL.

In the case of SELinux, if you attempt 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 EPM-UL 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 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.

Prefix and suffix installations

EPM-UL can be installed with prefixes or suffixes to create unique installations for multiple installs or for ease of identification.

Resource overhead

There are no startup or shutdown programs associated with EPM-UL. From a system resource perspective, a basic EPM-UL 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 EPM-UL 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 EPM-UL log server daemon, pblogd, are actually started by the superdaemon. The superdaemon is inetd, xinetd, launchd, or SMF depending on the platform.

For systems based on RedHat version 7+, xinetd is no longer installed by default, since it has been superseded by systemd, which is an init system. The installation program checks if systemd exists and is functional.

• If it exists, it configures EPM-UL 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 EPM-UL daemons. It is also possible to explicitly start the daemon as a persistent daemon.

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.

Required utilities

The EPM-UL installer requires the following Unix and Linux utilities and built-in commands:

Installation directories

EPM-UL is not sensitive about the location of its binary files; you can place them in any convenient directory. However, consider these points when selecting installation directories:

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

Default directories

The following table lists various EPM-UL 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 EPM-UL 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 EPM-UL log files.

Change /opt/pbul base directory

As seen in the previous table, files that EPM-UL generates at runtime are created under /opt/pbul. To change this default location, use pbinstall's basedir menu to set 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

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

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

Starting with version 7.1.0, if the system EPM-UL 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 EPM-UL 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.

Role-based policy database

Starting in 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 <host>)
  • 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.<user>.<runhost>.<YYYY-MM-DD>.[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

EPM-UL 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 EPM-UL systems included in the 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 EPM-UL 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 EPM-UL. It is recommended that you install the third-party libraries. However, you can use your own third-party libraries.

Use EPM-UL third-party libraries

If you have your own Kerberos, SSL, LDAP, or CURL libraries but want to use EPM-UL third-party libraries, do one of the following:

• Remove your libraries from /usr/lib or /lib and point to the EPM-UL third-party libraries in /usr/lib/beyondtrust/pb or /usr/lib/beyondtrust/pb in pb.settings.
• Replace your third-party libraries with the EPM-UL 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 EPM-UL 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.3
  • libssl.so.3
• LDAP:
  • liblber.so.2.0.200
  • libldap.so.2.0.200****
• CURL:
  • libcurl.so.4.8.0

Shared library directory location for AIX

For AIX, 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

AIX uses a different notation for LDAP libraries than other platforms. For archived third-party libraries on AIX, append the name of the shared object member in parentheses after the archive file name.

The notation for default LDAP libraries is:

• /usr/lib/beyondtrust/pb/liblber.a(liblber.so.2)
• /usr/lib/beyondtrust/pb/libldap.a(libldap.so.2)

For example, if libcom_err.a.3.0 is the archive and shr.0.3.0 is the shared object, specify the member as libcom_err.a.3.0(shr.0.3.0).

Use your third-party libraries

If you configure EPM-UL with Kerberos, SSL, or LDAP, and do not load EPM-UL built-in third-party libraries, you must specify your own shared library file names.

If you have Kerberos, SSL, or LDAP libraries in /usr/lib or /lib and you are using them for other applications, you need to use your libraries for EPM-UL as well and not use any of the libraries in /usr/lib/beyondtrust/pb or /usr/lib/beyondtrust/pb.

During the EPM-UL installation, specify no for the install option Install BeyondTrust built-in libraries, and then enter the appropriate shared library directory and filename.

Install third-party libraries in future installations

If you did not enable the third-party libraries during EPM-UL installation and you later decide to enable Kerberos, SSL, or LDAP in your policy, you must do the following:

• Install the EPM-UL third-party libraries or your own third-party libraries.

• In the pb.settings file, do one of the following:

  • If you are using the EPM-UL third-party libraries, set the following keywords to the full path and library file names of the operating system third-party libraries:

    • sharedlibkrb5dependencies
    • sharedlibssldependencies
    • sharedlibLDAPdependencies
    • sharedlibcurldependencies

  • If you are using your own third-party libraries, provide the full path and library file names for each of the following settings:

    • Kerberos library
    • SSL library
    • LDAP library
    • CURL library

    List your libraries in the correct order. For example, if lib1 depends on lib2, list lib2 first, followed by lib1.

Improve security

EPM-UL secures network communication with Transport Layer Security (TLS) by default. In v26.1 and later, the installation creates its own public key infrastructure (PKI). The first server you install generates a self-signed root certificate authority (CA) that acts as the trust anchor for the installation, and every other server and endpoint receives a certificate signed by that CA. Certificate and hostname validation are enforced for connections that use these certificates.

If your organization operates its own PKI, or policy requires certificates issued by a trusted external CA, you can install EPM-UL using your own certificates instead.

You can harden an installation further by validating server and client certificates, controlling when TLS negotiation happens relative to the EPM-UL proprietary protocol, and restricting the cipher suites that hosts accept.