Blocking Unauthorized Software on Fedora Server with fapolicyd: A Whitelisting Approach – ITFROMZERO

Table of Contents

When Root Privileges Aren’t Enough to Protect Your System

Even if you have layered firewalls, SELinux in Enforcing mode, and perform weekly patching, your system still has a critical vulnerability. If a user or a compromised service manages to download an unauthorized script into /tmp, grants it +x permissions, and executes it, the risk is immediate. SELinux can limit the damage, but stopping it right at the execution stage is a much more definitive approach.

After using Fedora for two years on critical projects, I realized that production environments need a “Zero Trust” mechanism for executable files. The principle is simple: Only what is permitted can run; everything else is blocked. This is where fapolicyd (File Access Policy Daemon) shines on Fedora Server.

Why Not Use Traditional Methods?

Before configuring it, let’s look at why old solutions often fail to stop professional attackers.

1. Mount Options (noexec)

Many admins mount /tmp or /home with the noexec option. However, this technique is easily bypassed. An attacker can simply call an interpreter directly, such as python3 script.py, or use ld-linux.so to load a binary, easily circumventing the restriction.

2. SELinux Policies

SELinux is incredibly powerful, but it focuses on what an application can do after it has started running. Writing policies to block execution in every nook and cranny is a technical nightmare and can easily lead to system hangs if you aren’t an expert.

3. fapolicyd – The Modern Solution

This tool operates at the Kernel level via fanotify. The biggest difference is its direct integration with Fedora’s RPM database. It trusts all software installed via dnf by default and automatically blocks everything installed manually from external sources.

Real-world Benefits on Fedora Server

Deploying fapolicyd on Fedora Server brings a rare level of ease to administrators. The system automatically scans the RPM database to identify “authentic” software.

Performance: CPU usage is typically under 1% during normal operation.
Reliability: Reduces the risk of “Living off the land” attacks (using existing tools for malicious purposes) by 90%.
Productive Annoyance: You will be blocked if you run random scripts. On a server, this annoyance is the most valuable security layer.

Installation and Configuration Guide for fapolicyd

I will perform these steps on the latest version of Fedora Server. Ensure you have sudo privileges.

Step 1: Install the Package

Run the following command to install the daemon:

sudo dnf install fapolicyd -y

Important Note: Do not enable the service immediately. If misconfigured, you could lock yourself out of your system administration tools.

Step 2: Update the Trust List

First, fapolicyd needs to synchronize the list of allowed files based on the RPM database:

sudo fapolicyd-cli --update

Then, activate the service to start monitoring:

sudo systemctl enable --now fapolicyd

Check the status to ensure everything is stable:

sudo systemctl status fapolicyd

Step 3: Real-world Testing

Try creating a simple script in the /tmp directory to see how strictly it operates:

echo -e "#!/bin/bash\necho 'Hacker script'" > /tmp/malware.sh
chmod +x /tmp/malware.sh
/tmp/malware.sh

The system will return an error: Operation not permitted. Even if you try to bypass it using the command bash /tmp/malware.sh, fapolicyd will still block it because it monitors interpreters as well.

How to Add Internal Applications to the Whitelist

In practice, you will always have custom scripts or binaries that are not in the RPM database. Do not modify the main configuration file /etc/fapolicyd/fapolicyd.rules. Instead, create a separate file in rules.d.

Example: Allowing a Custom Admin Tool

Suppose you have a tool at /opt/admin-tools/sync-data. Create a new rule file:

sudo nano /etc/fapolicyd/rules.d/90-admin-tools.rules

Add the following line to allow execution:

allow perm=any obj=/opt/admin-tools/sync-data

Finally, reload the rules and update the database to apply the changes:

sudo fagenrules --load
sudo systemctl restart fapolicyd

Controlling Integrity with Integrity Check

One feature I really like is the SHA256 hash check. A hacker could overwrite a whitelisted file with malicious code. To prevent this, fapolicyd can verify the file’s hash before allowing it to run. If the hash doesn’t match the declaration, execution is immediately denied.

Operational Tips to Avoid “Shooting Yourself in the Foot”

When first deploying, I once crashed a service because it created temporary executable files. To avoid disaster, you should apply these three rules:

Debug Mode: Run sudo fapolicyd --debug to observe in real-time what is being blocked before enforcing strictly.
Monitor System Logs: Use the command journalctl -u fapolicyd | grep deny frequently during the first week of deployment.
Prioritize Path Whitelisting: For directories containing many trusted scripts, whitelist the entire directory but maintain strict write permissions.

Final Advice

Using fapolicyd on Fedora Server is a shift from passive defense to proactive control. Initially, fine-tuning rules might take 30-60 minutes. However, the peace of mind knowing that no unauthorized software can run on your server is a reward well worth the effort.