Create Policy Files in Endpoint Privilege Management for Unix and Linux

A security policy file is a collection of instructions that define the system security rules that Endpoint Privilege Management for Unix and Linux applies during task verification processing. These instructions are written using Endpoint Privilege Management for Unix and Linux Security Policy Scripting Language.

The default name of the primary Endpoint Privilege Management for Unix and Linux security policy file is pb.conf. This file is analogous to the main() function in a C program. It is possible to add Security Policy Scripting Language statements directly to pb.conf or to use security policy subfiles. Security policy subfiles are separate, individual security policy files invoked at runtime using the include statement (using the syntax include "subfilename";).

We strongly recommend that you use security policy subfiles.

Conceptually, the include statement can be thought of as a placeholder.

A diagram of how include statements work when creating policy files in Endpoint Privilege Management for Unix and Linux.

At run time, Endpoint Privilege Management for Unix and Linux replaces include statements with the actual contents of the specified include file. This process occurs in computer memory and does not alter the physical files in any way.

The use of security policy subfiles enables you to organize a site’s security policy implementation in a modular fashion. Using this method, each security policy subfile can focus on a specific area of security policy implementation. This compartmentalizes security policy implementation, making it much easier to maintain and enhance over time.

A common way to organize security profile files is by type of user and system access requirements.

root should own the security policy files and their permissions should be set to 400 or 600. Place the files in the same directory (we recommend /opt/pbul/policies) for convenience. The /opt/pbul/policies directory is the default location. A different directory can be specified with the policydir setting in the pb.settings file. To insure security policy file integrity, Endpoint Privilege Management for Unix and Linux does not process a security policy file if users other than root has security permissions that allow them to modify or delete the file. In other words, only root should have read/write permissions for these files, and the directories in which these files are stored should have security permissions that prevent users other than root from reading, modifying, or deleting them.

Security policy files are usually created with a standard text editor. They are saved as plain text files. By default, Endpoint Privilege Management for Unix and Linux uses a .conf file name suffix for security policy files, but this is not a requirement.

When naming security policy files, any file suffix may be used, or the suffix may be omitted. Starting with v9.0, a new Role Based Policy mechanism has been implemented that allows administrators to maintain their policy in a database with an option 'change management' functionality.

Default Policy

Starting with version 8.0, 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 a /opt/pbul/policies directory (from v9.4.3+ and in /etc/pb prior to v9.4.3) by default. pbul_policy.conf are then 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).

This default policy contains the following roles:

Helpdesk Role

Enabled by default, when invoking pbrun helpdesk it allows any user in HelpdeskUsers (default root) to initiate a helpdesk menu as root on any host in HelpdeskHosts (default submithost only). The helpdesk menu of actions contains:

  • List of processes (ps -ef)
  • Check if a machine is up (ping <host>)
  • List current users on this host (who -H)
  • Display host's IP settings (ifconfig -a)

PBTest

Enabled by default, for all users on all hosts, pbrun pbtest allows checking connectivity and policy.

Controlled Shells

Enabled by default, allows users in ControlledShellUsers (by default the submituser), for runhosts in ControlledShellHosts (by default only submithost), to enable iologging for pbksh/pbsh. iologs 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, allows users in AdminUsers (by default root) to run any command on runhosts in AdminHosts (by default only submithost).

Demo role

Disabled by default, 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).

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

This policy is meant to be used as a starting point for your own policy. You can enable or disable any of the roles listed above by simply setting the corresponding "Enable<rolename>Role" to true or false. Or you can completely delete the policy and use your own. If you choose to continue with the default policy as a starting point, you can add more users, hosts and commands to the various lists used for each role, for example you can take ControlledShellRole further by adding users to ControlledShellUsers, and hosts to ControlledShellHosts, and commands to ControlledShellRejectedCmds and ControlledShellPrivilegedCmds.

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.

For more information on the sudo wrapper, see "Sudo Wrapper" in the Endpoint Privilege Management for Unix and Linux Administration Guide.