Configuration

This help page section describes the characteristics that can be configured to influence system capabilities.

Zero-Day Protection

The Policy Defaults rule set is listed below. Its purpose is to ensure base system functionality is allowed.
Note, this file comprises paths only; it does not contain binaries. The first path specified is Application Control for Linux

/opt/arrow/ac/

/usr/bin/

/usr/libexec/

/usr/lib/xorg/

/usr/lib/gdm3/

/etc/gdm3/

/usr/sbin/

/usr/lib/

/usr/lib/debug/

/usr/lib/debug/lib/

/usr/lib/debug/lib/libc6-prof/x86_64-linux-gnu/

/usr/lib/debug/lib/libc6-prof/

/usr/lib/debug/lib/x86_64-linux-gnu/

/usr/lib/i386-linux-gnu/

/usr/lib/x86_64-linux-gnu/

/sbin/

/etc/

/proc

/var

/etc/init/

/boot/grub2/

/boot/efi/EFI/redhat/

/boot/loader/

/etc/default/

/proc/

/boot/

/boot/efi/

/boot/efi/EFI/

/usr/lib64/

/usr/libexec/

/usr/libexec/sssd/

/usr/libexec/hypervkvpd/

/usr/lib/systemd/

/usr/lib/gdm3/

Local Allowedlists

Due to RPM database API technical limitations the Application Control for Linux engine cannot account for changes that occur in the RPM database whilst it is running.

For further information on this technical issue refer to: https://github.com/rpm-software-management/rpm/issues/1124.

Restart Engine Daemon

If packages are installed or updated on the Linux endpoint, you are advised to restart the engine’s daemon. This action is required to keep the engine synchronized with the refreshed version of the installed packages in the RPM database.

1.Enable the Linux endpoint engine daemon using the following command:

sudo systemctl enable ivanti-ac-engine

2.Start the Linux endpoint engine daemon using the following command:

sudo systemctl start ivanti-ac-engine

3.Verify Linux endpoint engine daemon status using the following command:

sudo systemctl status ivanti-ac-engine

Allow/Deny Rules

Hashing for binaries

The option to Use Hashing helps inform the Application Control for Linux engine that the target binary should be allowed or denied via its signature rather than its location. This means that if the target binary is copied into another location, the enforcement on it cannot be circumvented.

There is no practical method for the system to predict if the specified target is a path or a binary - or whether it exists on all the Linux endpoints where the policy containing the rule might be deployed. The decision to allow or deny is made locally on each endpoint by each Application Control for Linux engine. The system will not prevent the administrator from selecting the Use Hashing option for a path - but if wrongly set, hashing option is ignored.

Whilst it is possible to check the Use Hashing check box in the web console for any target – the system requires the administrator to set it correctly.
Hashing can only be applied by the engine for existing binaries.

Enabling or disabling individual rules:

Rules can be enabled or disabled at an individual level. This allows administrators to test settings and configurations before finalizing policies.

Audit vs. Restrict

Viewing results of deployed policies:

The effects of a deployed policy, in either Audit or Restrict mode, can be observed in the Audit Log or Debug Info tabs available for each device in the Devices page.

Note, operation identifiers are different for each mode:

Audit mode - Allowed or Denied

Restrict mode - Permitted or Blocked

Search, Filter, and Order functions are available in the Audit Log or Debug Info tabs and allow you to inspect any results of interest.

Root User Exclusion

The root user is excluded from all the enforcements performed by the Application Control for Linux engine.

Related Topics:

Administration

Maintenance

Applying Rule Sets

Installation (opens UWM Help)