When working with security-focused systems, especially those protected by fapolicyd, it’s essential to understand the implications of how trust is assigned to executable files.

In this blog post, we will walk through why adding trusted files explicitly using command-line tools is a more secure and controlled approach compared to allowing broad directory-level access in fapolicyd rule files.

• The Two Approaches
  • File-Based Trust (Preferred)
  • Directory-Based Trust (Not Preferred)
• 🔐 Why File Trust is Better
  • 1. Minimizes Attack Surface
  • 2. Respects Least Privilege
  • 3. Auditable and Reproducible
  • 4. Safe for CI/CD and Patch Cycles
• What’s the Risk of Directory Rules?
• Final Verdict: Add Trusted Files Only
• Pro Tip: After Adding Files
• Security is Intentional
• Conclusion

When hardening a Splunk deployment with fapolicyd, we face a critical decision:
Do we trust specific files? Or do we allow entire directories?

Here’s why I’ve shifted toward a file-level trust model, especially for .py and .pyc files.

The Two Approaches

File-Based Trust (Preferred)

**sudo find /opt/splunk/lib/python3.9/ -type f \( -name "*.py" -o -name "*.pyc" \) -print0 | sudo xargs -0 -n 1 fapolicyd-cli --file add**  
**sudo find /opt/splunk/etc/apps/ -type f -name "*.pyc" -print0 | sudo xargs -0 -n 1 fapolicyd-cli --file add**  
**sudo find /opt/splunk/etc/deployment-apps/ -type f -name "*.pyc" -print0 | sudo xargs -0 -n 1 fapolicyd-cli --file add**

Directory-Based Trust (Not Preferred)

# In splunk.rules:
allow perm=any uid=splunk : dir=/opt/splunk/lib/
allow perm=any uid=splunk : dir=/opt/splunk/etc/apps/
allow perm=any uid=splunk : dir=/opt/splunk/etc/deployment-apps/

🔐 Why File Trust is Better

1. Minimizes Attack Surface

Broad directory rules allow every file, current and future, in the path to be executed or read by the splunk user.
If a malicious or compromised file gets dropped into /opt/splunk/etc/apps/, it’s instantly executable.

With file-level trust, only what we explicitly approve can run.

2. Respects Least Privilege

The principle of least privilege says: “Grant only the access necessary.”
With fapolicyd-cli --file add, we’re trusting only the known-good .py or .pyc files generated by legitimate deployments.

3. Auditable and Reproducible

When using fapolicyd-cli --file add, trust is recorded per inode.
This means:

• Changes to a file (even in-place) break trust.
• It’s easier to compare environments (dev vs prod).

4. Safe for CI/CD and Patch Cycles

With file-based trust, automation scripts can re-trust only the files that were actually updated.

E.g., after a Splunk app update:

find /opt/splunk/etc/apps/my_app/ -type f -name "*.pyc" | while read -r file; do  
  fapolicyd-cli --file add "$file"  
done

This keeps the ruleset dynamic but secure.

What’s the Risk of Directory Rules?

Imagine you allow this:

allow perm=any uid=splunk : dir=/opt/splunk/etc/apps/

Now imagine someone places a rogue script into:

/opt/splunk/etc/apps/malicious/bin/virus.pyc

Your splunk user can execute it. No prompt, no denial, no audit trail — because the directory rule trusts everything.

Final Verdict: Add Trusted Files Only

Using commands like these:

*sudo find /opt/splunk/etc/apps/ -type f -name “.pyc” -print0

sudo xargs -0 -n 1 fapolicyd-cli –file add**

…keeps the trust database secure, auditable, and in line with how fapolicyd was meant to be used: as a whitelist-first policy engine.

You can still use a few minimal directory rules (like /opt/splunk/bin/ or /opt/splunk/lib/), but for everything app- or user-generated, explicit trust wins.

Pro Tip: After Adding Files

Always remember:

sudo fapolicyd-cli –update
sudo systemctl restart fapolicyd

And re-run your script or Splunk process to test.

Security is Intentional

Broad access rules are fast. File trust is deliberate.
In hardened environments — deliberate is more safe and secure.

Conclusion

While it may be tempting to authorize entire directories for convenience, this approach can unintentionally introduce risk by trusting files you didn’t explicitly vet. Using targeted commands to individually trust .py and .pyc files not only tightens your security posture, it aligns with best practices for managing trusted execution policies in environments like Splunk. When auditing or troubleshooting fapolicyd denials, remember: precision beats broad strokes every time.