Applying Rule Sets

This help page section describes the concept of how Ivanti Application Control for Linux uses and applies rule sets. It summarizes how to create rules, the logic used to apply those rules, and includes a range of specific Rule Set Examples.

Concepts

The rule system applied in Application Control for Linux is based on three fundamental concepts:

These concepts are supported by functional details:

  • Denied by default for zero-day protection

  • Policy defaults and local allowlisting

  • Root user exclusion.

Understanding the concepts will help you grasp how to correctly compose your rule system to obtain the expected results.

Target Identification

Rules apply on execution operations as final targets (where targets can be specified as binaries, shared objects, scripts, or commands).

  • When defining a rule set, a target is the first input required as it specifies where (or exactly on what) you want the rule to apply.

You can specify a location (relative or full path) as a target. The resulting rule will apply to all execution operations started under or by the current user in the location specified.

You can specify a binary (via a relative or full path to it) as a target. The resulting rule will apply to the execution operation identified, started under (or by) the current user.

In addition to specifying a target for your rule set, for binary targets you can also set the Use Hashing option (see also Administration). If selected, the system creates a hashing value for the final target at the location specified. The hashing value is used globally to identify the final target - it is used instead of the original target location.

  • The system can identify a final target by location or by signature, making the identification and rule enforcement local or global.

Operator Precedence

There are three operators considered in the Application Control environment: Allow, Deny, and Hashing.

  • General Comments

Allow and Deny are mandatory Boolean operators. Hashing is an optional, conditional operator.

Allow and Deny set the enforcement type (that is, they permit or block an event), while Hashing changes the enforcement’s coverage from local to global.

  • Allow specifies that a certain final target should be allowed to execute.
    Where:

The final target is the binary, shared objects, script, or command specified in the rules set

The target is located at its specified or inherited location or is identified by its signature (globally)

The execution is triggered under (or by) the current user

  • Deny specifies that a certain final target should be denied execution.
    Where:

The final target is the binary, shared objects, script, or command specified in the rules set

The target is located at its specified or inherited location or is identified by its signature (globally)

The execution is triggered under (or by) the current user

  • Hashing specifies that a certain final target should be identified by its signature instead of its location, and globally consider further the enforcement of its execution, under or by the current user.
    Where:

The final target is the binary, shared objects, script, or command specified in the rules set

Given the details above, the operator precedence is as follows:

  1. Initially, the hashing is considered, first the Allow operators, then the Deny operator.

  2. Second, the Allow operator is considered, by final target location.

  3. Third, the Deny operator is considered, by final target location.

Notes:
  • Although the Hashing operator is optional, because it applies globally it is considered first.

  • The system is designed to Deny by default. Allow operators are considered to prevent the whole system becoming blocked.

Hierarchical Specialization:

Hierarchical Specialization is used to determine how a rule is applied within the system.

  • Initially, all final targets are found so the system identifies where and what they are. Targets are then identified either by location or by signature (if Hashing is enabled).

  • When deciding a rule for a final target, the system will perform the following steps:

Compute the hash of the executed binary and search the internal rules hashes table for Allow or Deny operators.

If no rule is matched the system will search for a non-hashing Allow/Deny rule for the exact location of the executed binary.
Note this is referred to as the most specialized rule for the final target.

If no rule is matched the system will start reducing the path to the executed binary. The process starts at the end of the path by removing the right-most element. First the binary itself if removed, then the previous directory, and this process continues to the root directory (“/”). With each reduction the system searches for a rule in the rules list that applies to the reduced location. If a match is found, the rule is applied to the initial executing binary.
Note this is referred to as the closest specialized rule for the final target.

Whilst performing the steps above, the system will also consider the policy defaults and the local allowlisting tables in establishing the correct definitive rule for an executing binary.

Ultimately, if no rule can be found for the final target, its execution will be denied by default.

Understanding the functional details allows you to get a better overview on the behavior of the Application Control system as a whole and its capabilities. Refer to Capabilities and Utilization sections for further information.

Rule Set Examples

Related Topics:

Configuration

Administration

Installation (opens UWM Help)