STIGhubSTIGhub
STIGsRMF ControlsCompare

STIGhub

A free tool to search and browse the entire DISA STIG library. Saves up to 75% in security compliance research time.

Navigation

  • Browse STIGs
  • Search
  • RMF Controls
  • Compare Versions

Resources

  • About
  • Release Notes
  • VPAT
  • DISA STIG Library
STIGs updated 4 hours ago
Powered by Pylon
© 2026 Beacon Cloud Solutions, Inc. All rights reserved.
← Back to Red Hat Enterprise Linux 10 Security Technical Implementation Guide

V-280971

CAT II (Medium)

RHEL 10 must be configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs.

Rule ID

SV-280971r1184780_rule

STIG

Red Hat Enterprise Linux 10 Security Technical Implementation Guide

Version

V1R1

CCIs

CCI-001764CCI-001774

Discussion

The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as allowlisting. Using an allowlist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of allowlisted software occurs prior to execution or at system startup. User home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with a system administrator through shared resources. RHEL 10 ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". The "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either block list or allowlist processes or file access. Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system nonfunctional. The "fapolicyd" application programming interface (API) is not namespace aware and can cause issues when launching or running containers. Satisfies: SRG-OS-000368-GPOS-00154, SRG-OS-000370-GPOS-00155

Check Content

Verify the RHEL 10 "fapolicyd" employs a deny-all, permit-by-exception policy.

Check that "fapolicyd" is in enforcement mode with the following command:

$ sudo grep permissive /etc/fapolicyd/fapolicyd.conf

permissive = 0

If "fapolicyd" is not running in enforcement mode, this is a finding.

Check that "fapolicyd" employs a deny-all policy on system mounts with the following commands:

$ sudo tail /etc/fapolicyd/compiled.rules

allow exe=/usr/bin/python3.7 : ftype=text/x-python
deny_audit perm=any pattern=ld_so : all
deny perm=any all : all

If "fapolicyd" is not running with a deny-all, permit-by-exception policy, this is a finding.

Note: "deny_log" or "deny_audit" options meet the security requirements. These options will generate higher volumes of logs.

Fix Text

Configure RHEL 10 to employ a deny-all, permit-by-exception application allow listing policy with "fapolicyd".

With the "fapolicyd" installed and enabled, configure the daemon to function in permissive mode until the allow list is built correctly to avoid system lockout. Do this by editing the "/etc/fapolicyd/fapolicyd.conf" file with the following line:

permissive = 1

Build the allow list in a file within the "/etc/fapolicyd/rules.d" directory, ensuring the last rule implements a deny-all policy, such as "deny perm=any all : all".

Once it is determined the allow list is built correctly, set the "fapolicyd" to enforcing mode by editing the "permissive" line in the /etc/fapolicyd/fapolicyd.conf file.

permissive = 0