If you are managing a Red Hat Enterprise Linux (RHEL) server, you likely face the challenge of ensuring only trusted software runs on your system. You might find yourself in a scenario where a user accidentally downloads an untrusted script from the internet and attempts to execute it, or perhaps an attacker manages to place a malicious binary in a temporary directory. Without a robust application control framework, these unauthorized programs can compromise your entire environment.
Enter fapolicyd.
Developed as a modern framework for software whitelisting, fapolicyd (File Access Policy Daemon) allows administrators to define exactly which applications are permitted to run based on a system-wide policy. Unlike traditional permissions, it can verify the integrity of a file before allowing it to execute. This guide provides a comprehensive, step-by-step walkthrough for installing, configuring, and monitoring fapolicyd to enhance your Linux server security best practices.
Table of Contents
Key Takeaways: Mastering fapolicyd
- Application Whitelisting → The primary role of
fapolicydis to block unauthorized execution of programs not found in the official RHEL repositories. - Trust Database → It uses the RPM database as a source of truth for “trusted” files, making management automatic for system-installed tools.
- Integrity Verification → The daemon can be configured to check file hashes, ensuring that even trusted binaries haven’t been tampered with.
- Administrative Control → Because it modifies deep system behavior, understanding the Linux sudo command is essential for managing the service.
Step 1: Install the fapolicyd Package
Before you can enforce policies, you must install the physical binaries from the official Red Hat repositories. This is done using the standard package manager.
Command: sudo dnf install fapolicyd
Expected Output:
Installing:
fapolicyd x86_64 1.1.3-1.el9
Transaction Summary:
Install 1 Package
Is this ok [y/N]: y
Complete!
Note: If you are auditing a new server, it is a good habit to check file size in Linux for any unexpected large binaries before enabling strict execution policies.
Step 2: Configure the Trust Policy
fapolicyd relies on a set of rules located in /etc/fapolicyd/. By default, it is often configured to trust everything currently in the RPM database.
- Open the configuration file:
sudo vi /etc/fapolicyd/fapolicyd.conf. - Verify the trust source: Ensure
integrity = sizeorintegrity = sha256is set if you want to verify files beyond their existence. - Define local rules: If you have custom scripts, you must add them to
/etc/fapolicyd/rules.d/so they aren’t blocked.
Step 3: Enable and Start the Service
Once configured, you must load the daemon. It is recommended to start it in a non-blocking mode first to ensure you don’t lock yourself out of essential tools.
Command: sudo systemctl enable --now fapolicyd
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
Check Status: sudo systemctl status fapolicyd
Step 4: Add Custom Applications to the Whitelist
If you have a proprietary application not installed via RPM, fapolicyd will block it by default. You must manually add it to the trust list.
Command: fapolicyd-cli --add /path/to/my_app
Expected Result: The daemon will record the file’s metadata and allow it to execute in future sessions without interruption.
Step 5: Monitor Blocked Executions
To see if fapolicyd is working or if it is blocking legitimate tools, you should monitor the system logs.
Command: sudo journalctl -u fapolicyd
Sample Log Output:
fapolicyd: rule=999, decision=deny, auid=1000, pid=5678, path=/tmp/malicious.sh
This output tells you exactly which rule triggered the denial and the path of the blocked file.
Important Best Practices
- Maintenance: Whenever you update your system using
dnf,fapolicydautomatically refreshes its view of the RPM database. - Testing Mode: During initial deployment, set the daemon to “permissive” mode in the config file to log violations without actually blocking them.
- Backups: Before making major changes to the rules, ensure you can list all users in Linux to verify which accounts will be affected by execution restrictions.
Summary Tables
| Goal | fapolicyd Command | Purpose |
|---|---|---|
| Check Trust | fapolicyd-cli --check-config | Validates syntax of rules. |
| Add File | fapolicyd-cli --add <path> | Marks a local file as trusted. |
| List Rules | fapolicyd-cli --list | Shows current enforcement rules. |
| Dump Database | fapolicyd-cli --dump-db | View all files currently trusted. |
| File Location | Role | Persistence |
|---|---|---|
| /etc/fapolicyd/fapolicyd.conf | Main daemon settings | Permanent |
| /etc/fapolicyd/rules.d/ | Individual rule blocks | Permanent |
| /var/log/fapolicyd/ | Service activity logs | Session-based |
FAQ
What happens if the RPM database is corrupted? fapolicyd will lose its primary source of trust. It is vital to maintain RPM integrity to ensure your security policies remain effective.
Does fapolicyd impact system performance? There is a minor overhead because the daemon must intercept system calls. Using integrity = size is faster than sha256, though less secure.
Can I use fapolicyd to block specific users? Yes, rules can be written to filter by auid (Audit User ID), allowing you to restrict execution for specific Linux users.
