USBGuard is a security framework for Linux that controls which USB devices are permitted to interact with the system. It sits above the kernel’s native USB authorisation subsystem — a per-device authorisation flag in the USB core that determines whether a device can be configured and begin sending data — and enforces a policy defined in a rule file against every device that connects or is present at startup. The threat model USBGuard addresses is both insider threat (unauthorised storage devices, data exfiltration) and hardware attack: BadUSB devices — malicious firmware embedded in devices that present themselves as HID keyboards, network adapters, or other trusted classes — can be blocked by a sufficiently specific USBGuard policy that restricts which USB interface classes are permitted. A USB device that claims to be a keyboard (03:01:01) but was not explicitly authorised cannot send keystrokes; a USB storage device plugged into a workstation with a policy that only allows a specific keyboard and mouse is blocked outright. USBGuard cannot protect against devices present at boot (before the daemon starts), so it is a defence-in-depth control for the running OS rather than a substitute for physical port security.
SSSD (System Security Services Daemon) is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — NSS (Name Service Switch) for identity lookups (user names, UIDs, GIDs, group membership) and PAM (Pluggable Authentication Modules) for authentication and session management — without creating local user accounts. It was originally developed as a component of the FreeIPA project at Red Hat, introduced in Fedora 11 (2009), and quickly became the standard identity integration layer across RHEL, Fedora, Ubuntu, Debian, and most enterprise Linux distributions. Before SSSD, integrating a Linux host with LDAP or AD required configuring nss_ldap, pam_ldap, pam_krb5, and pam_winbind independently — each with its own caching (or lack thereof), its own reconnection logic, and its own configuration syntax. SSSD replaced this collection with a single, unified daemon providing caching, offline authentication, multi-domain support, and access control in one place.
SELinux (Security-Enhanced Linux) is a Mandatory Access Control (MAC) implementation developed by the NSA and released as open source in 2000, merged into the mainline Linux kernel in 2.6 via the LSM framework in 2003. Its defining characteristic is default deny: unlike the standard Linux Discretionary Access Control model (file permission bits), where anything not explicitly forbidden is permitted, SELinux refuses all access that is not explicitly allowed by policy. Every process and every object — every file, socket, pipe, device node, and IPC object — carries a security context (also called a label) of the form user:role:type:level. The policy is a compiled set of rules, loaded at boot, that defines precisely which combinations of process context and object context may interact and how. An Apache web server process running in the httpd_t domain can read files labelled httpd_sys_content_t but is denied access to files labelled user_home_t or shadow_t, regardless of what Unix file permission bits say. If the web server is compromised, the attacker is confined to what httpd_t permits — typically a narrow, well-defined set of files and network operations — rather than having the full access of the user account running Apache.
NBDE (Network-Bound Disk Encryption) is an approach to automatic LUKS disk unlocking that binds the volume key not to hardware state (a TPM PCR measurement) but to network presence: a LUKS-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated Tang server on a trusted network. Remove the machine from that network — because it was stolen, because a data centre drive was pulled, because someone exfiltrated the hardware — and the volume key becomes unrecoverable without a fallback passphrase. The threat model is therefore complementary to TPM-based unlocking: TPM sealing asks “is this the right software stack?” and locks the key to a specific platform measurement; NBDE asks “is this machine on the trusted network?” and locks the key to network presence. Neither addresses both threat classes alone, which is why the two are routinely combined — and why RHEL formalises NBDE as a subcategory of the broader Policy-Based Decryption (PBD) framework that the Clevis pin system implements.
firewalld is the firewall management daemon on RHEL, CentOS Stream, Fedora, SUSE, and their derivatives, providing a higher-level policy model and a runtime-safe management API on top of nftables (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is runtime versus permanent configuration: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (--runtime, the default), and separately persisted to disk so they survive reboots (--permanent). This two-phase model solves the operational problem that raw nftables or iptables rule changes traditionally required either accepting a momentary policy gap during reload or building custom transaction logic. The daemon exposes its API over D-Bus, allowing NetworkManager, libvirt, Podman, and other system components to request firewall policy changes programmatically — when a VM is started in libvirt or a container port is published in Podman, the respective tool calls firewalld over D-Bus to open the required port rather than directly manipulating nftables rules.
fapolicyd (File Access Policy Daemon) is an application allowlisting framework for Linux, developed by Red Hat and shipped as a supported component of RHEL 8+. Its security premise is supply-chain integrity at the execution layer: only software that was installed through a trusted package manager (DNF/RPM) or explicitly declared as trusted by an administrator may execute on the system. An attacker who achieves a foothold and drops a new binary — a reverse shell, a lateral movement tool, a cryptominer — will find that binary blocked at execution time, because it is absent from the trust database, regardless of its Unix permissions or SELinux label. fapolicyd addresses a different dimension of access control than SELinux: SELinux models how applications behave (what resources they may access); fapolicyd models whether applications are trusted at all (whether they may execute in the first place). The two are complementary: SELinux confines a trusted application’s behaviour; fapolicyd prevents untrusted applications from running.
AIDE (Advanced Intrusion Detection Environment) is a host-based intrusion detection tool that implements file integrity monitoring (FIM): it builds a baseline database capturing cryptographic hashes and metadata for every file it is configured to watch, and on subsequent runs compares the live filesystem against that database, reporting anything that has been added, removed, or changed. Its security premise is detection after the fact: AIDE does not prevent modifications (that is the role of fapolicyd, SELinux, and IMA), but it provides a reliable, auditable record that modifications occurred, when a check was run, and which specific attributes changed. An attacker who compromises a system and modifies a binary, a configuration file, a cron job, or an SSH authorized_keys file will leave a fingerprint in the next AIDE check — provided the database has not also been compromised, which is the central operational concern the tool’s deployment model must address.
