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
Simple rules for a binary
Simple rules for a binary called “myApp”, located in “/home/Desktop/”:
Setup:
•Rule 1: Allow – “/home/user/Desktop/myApp”
•Rule 2: Deny – “/home/user/Desktop/myApp”
Result:
Allow execution of “/home/user/Desktop/myApp”
Logic:
Allow by location takes precedence to deny by location (the level of specialization here is the same for both rules).
Simple rules for a binary - unoptimized and optimized
Same simple rules for a binary called “myApp”, located in “/home/Desktop/”, with an optimization suggestion:
Unoptimized example
Setup:
•Rule 1: Deny – “/home/user/Desktop/myApp”
•Rule 2: Allow – “/home/user/Desktop/myApp”
Result:
Allow execution of “/home/user/Desktop/myApp”
Logic:
Allow by location takes precedence to deny by location (the level of specialization here is the same for both rules).
Deny is analyzed, as it’s specified first, and the system must consider it, not knowing what will follow.
Optimized example:
Setup:
•Rule 1: Allow – “/home/user/Desktop/myApp”
•Rule 2: Deny – “/home/user/Desktop/myApp”
Result:
Allow execution of “/home/user/Desktop/myApp”
Logic:
Allow by location takes precedence to deny by location (the level of specialization here is the same for both rules).
Deny is ignored, the result is immediate, because allows have precedence to denies.
Rules for a binary using full path and hashing
Simple rules for a binary called “myApp”, located in “/home/Desktop/”, by location (full path) and by signature (hashing):
Setup:
•Rule 1: Allow – “/home/user/Desktop/myApp”
•Rule 2: Deny – “/home/user/Desktop/myApp” – Use hashing is checked
Result:
Deny execution of “/home/user/Desktop/myApp”
Logic:
Deny by hashing takes precedence to allow by location (the level of specialization here is the same for both rules, but the globality differs).
Rules for a binary and parent location
Simple rules for a binary called “myApp”, and its parent location “/home/user/Desktop/”:
Setup:
•Rule 1: Deny – “/home/user/Desktop/”
•Rule 2: Allow – “/home/user/Desktop/myApp”
Result:
Allow execution of “/home/user/Desktop/myApp”
Logic:
Allow set by the most specialized rule on the executing binary takes precedence to the deny for its parent location.
Rules for a binary - use of syntax
Simple rules for a location, “/home/user/Desktop/”, with a minor difference in syntax, but lexically identical:
Setup:
•Rule 1: Allow – “/home/user/Desktop”
•Rule 2: Deny – “/home/user/Desktop/”
Result:
Allow execution of anything in “/home/user/Desktop/”
Logic:
Allow by location takes precedence to deny by location (the level of specialization here will be the same for both rules).
While searching for the most specialized rule by location, the system knows and accounts for the fact that the last “/” is not changing it, so both syntaxes are treated as the same location.
Complex rules for a binary - example 1
More complex scenario, with rules for a binary called “myApp”, located in “/home/user/Desktop/”, its parent location, the “home” directory, and the system binary “ls”:
Setup:
•Rule 1: Allow – “/home/user/Desktop/”
•Rule 2: Deny – “/home/”
•Rule 3: Deny – “/home/user/Desktop/myApp”
•Rule 4: Deny – “/usr/bin/ls” – Use hashing is checked
Result:
Deny execution of anything in “/home/”, except allowing execution of anything in “/home/user/Desktop/”, but again deny the execution of “/home/user/Desktop/myApp”, and finally deny the execution of “ls” globally, not only from “/usr/bin/” (e.g., even if “ls” would be copied in “/home/user/Desktop/”).
Logic:
Deny for “ls” is global, by hashing, deny set by the most specialized rule on the executing binary for “myApp” takes precedence to the allow for its parent location, then anything else in its parent location “/home/user/Desktop/” would be allowed, taking precedence by specialization to the deny rule for its parent folder “/home/”, and finally, the deny on “/home/” is enforced.
Rules to block an app allowed by its parent location
Another complex scenario, with rules to block an app, “/usr/bin/ls”, implicitly allowed by the policy default rules by allowing its parent location “/usr/bin/”:
Default:
Rule x: Allow – “/usr/bin/”
Note, the default exists for both setups presented below:
Setup 1:
•Rule 1: Allow – “/home/user/Desktop/”
•Rule 2: Deny – “/usr/bin/ls”
Result 1:
Allow execution of anything in “/usr/bin/”, also allow execution of anything in “/home/user/Desktop/” but deny the execution of “/usr/bin/ls”, locally, only if executed from “/usr/bin/” (e.g., if “ls” would be copied in “/home/user/Desktop/” it would be allowed to execute).
Logic 1:
Deny for “ls” is local but set by the most specialized rule on the executing binary, so it takes precedence to the allow in policy defaults for its parent location, “/usr/bin/”.
Allow for “/home/user/Desktop/” will allow execution of any binary in it, unless explicitly denied, so since the deny for “ls” is not global, by hashing, and since there is no local deny for a copy of “ls” in “/home/user/Desktop/”, if that copy would exist, it would be allowed to execute.
Remember, the default is still there for this setup:
Setup 2:
•Rule 1: Allow – “/home/user/Desktop/”
•Rule 2: Deny – “/usr/bin/ls” – Use hashing is checked
Result 2:
Allow execution of anything in “/usr/bin/”, also allow execution of anything in “/home/user/Desktop/” but deny the execution of “/usr/bin/ls”, globally, not only from “/usr/bin/” (e.g., even if “ls” would be copied in “/home/user/Desktop/”).
Logic 2:
Deny for “ls” is global, set by hashing, and by the most specialized rule on the executing binary, so it takes full precedence to the allow in policy defaults for its parent location, “/usr/bin/”, and to the allow for “/home/user/Desktop/”, so if a copy of it were to exist there, it would be denied execution.
Environment variable examples
A few examples of expanding Environment Variables and how they are treated:
Case 1 – simple or composed:
Setup:
•$OTHER = “/home/Desktop/Folder/”
•$ENV = “/home/usr/$OTHER”
Result:
→ “/home/usr/home/Desktop/Folder/”
Logic:
will expand, composing the sub-paths, and removing extra “/”.
Case 2 – undefined variable:
Setup:
$UNDEFINED – is not defined on the system
Result:
→ N/A
Logic:
will not expand and the rule will be ignored for security reasons.
Case 3 – garbage variable
Setup:
$GARBAGE = “#847e08” – is defined, but unusable
Result:
→ N/A
Logic:
will not expand and the rule will be ignored for security reasons.
Case 4 – not found variable:
Setup:
$NOTFOUND = “/home/<none>/” – is defined, but path is not found
Result:
→ N/A
Logic:
will not expand and the rule will be ignored for security reasons.
Case 5 – empty variable:
Setup:
•$EMPTY = “” or “/” – is defined, but has no impact
•$OTHER = “/home/Desktop/Folder/$EMPTY”
Result:
→ “/home/Desktop/Folder/”
Logic:
will expand, composing the sub-paths, and removing extra “/”.
Case 6 – semantic identity:
Setup:
•Rule 1: Deny – “/home/$VAR”, where $VAR = “/user/Desktop/”
•Rule 2: Allow - “/home/user/Desktop/”
Result:
Allow execution of anything in “/home/user/Desktop/”
Logic:
Allow by location takes precedence to deny by location.
Rule 1’s path will expand, compose sub-paths, and remove extra “/”.
Related Topics:
Installation (opens UWM Help)