<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rhel on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/rhel/</link><description>Recent content in Rhel on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/rhel/index.xml" rel="self" type="application/rss+xml"/><item><title>AIDE (Advanced Intrusion Detection Environment)</title><link>https://lesitedefrancois.be/en/security/aide/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/aide/</guid><description>&lt;p&gt;&lt;strong&gt;AIDE (Advanced Intrusion Detection Environment)&lt;/strong&gt; is a host-based intrusion detection tool that implements &lt;strong&gt;file integrity monitoring (FIM)&lt;/strong&gt;: 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 &lt;strong&gt;fapolicyd&lt;/strong&gt;, &lt;strong&gt;SELinux&lt;/strong&gt;, and &lt;strong&gt;IMA&lt;/strong&gt;), 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 &lt;code&gt;authorized_keys&lt;/code&gt; 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&amp;rsquo;s deployment model must address.&lt;/p&gt;</description></item><item><title>fapolicyd (File Access Policy Daemon)</title><link>https://lesitedefrancois.be/en/security/fapolicyd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/fapolicyd/</guid><description>&lt;p&gt;&lt;strong&gt;fapolicyd (File Access Policy Daemon)&lt;/strong&gt; 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 &lt;strong&gt;SELinux&lt;/strong&gt;: 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&amp;rsquo;s behaviour; fapolicyd prevents untrusted applications from running.&lt;/p&gt;</description></item><item><title>firewalld</title><link>https://lesitedefrancois.be/en/security/firewalld/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/firewalld/</guid><description>&lt;p&gt;&lt;strong&gt;firewalld&lt;/strong&gt; 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 &lt;strong&gt;nftables&lt;/strong&gt; (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is &lt;strong&gt;runtime versus permanent configuration&lt;/strong&gt;: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (&lt;code&gt;--runtime&lt;/code&gt;, the default), and separately persisted to disk so they survive reboots (&lt;code&gt;--permanent&lt;/code&gt;). 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 &lt;strong&gt;D-Bus&lt;/strong&gt;, 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.&lt;/p&gt;</description></item><item><title>NBDE / Clevis / Tang (Network-Bound Disk Encryption)</title><link>https://lesitedefrancois.be/en/security/nbde-clevis-tang/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/nbde-clevis-tang/</guid><description>&lt;p&gt;&lt;strong&gt;NBDE (Network-Bound Disk Encryption)&lt;/strong&gt; is an approach to automatic &lt;strong&gt;LUKS&lt;/strong&gt; disk unlocking that binds the volume key not to hardware state (a &lt;strong&gt;TPM&lt;/strong&gt; PCR measurement) but to network presence: a &lt;strong&gt;LUKS&lt;/strong&gt;-encrypted volume unlocks automatically at boot if and only if the machine can reach a designated &lt;strong&gt;Tang&lt;/strong&gt; 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 &amp;ldquo;is this the right software stack?&amp;rdquo; and locks the key to a specific platform measurement; NBDE asks &amp;ldquo;is this machine on the trusted network?&amp;rdquo; 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 &lt;strong&gt;Policy-Based Decryption (PBD)&lt;/strong&gt; framework that the Clevis pin system implements.&lt;/p&gt;</description></item><item><title>SELinux (Security-Enhanced Linux)</title><link>https://lesitedefrancois.be/en/security/selinux/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/selinux/</guid><description>&lt;p&gt;&lt;strong&gt;SELinux (Security-Enhanced Linux)&lt;/strong&gt; is a &lt;strong&gt;Mandatory Access Control (MAC)&lt;/strong&gt; implementation developed by the NSA and released as open source in 2000, merged into the mainline Linux kernel in 2.6 via the &lt;strong&gt;LSM&lt;/strong&gt; framework in 2003. Its defining characteristic is &lt;strong&gt;default deny&lt;/strong&gt;: 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 &lt;strong&gt;security context&lt;/strong&gt; (also called a label) of the form &lt;code&gt;user:role:type:level&lt;/code&gt;. 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 &lt;code&gt;httpd_t&lt;/code&gt; domain can read files labelled &lt;code&gt;httpd_sys_content_t&lt;/code&gt; but is denied access to files labelled &lt;code&gt;user_home_t&lt;/code&gt; or &lt;code&gt;shadow_t&lt;/code&gt;, regardless of what Unix file permission bits say. If the web server is compromised, the attacker is confined to what &lt;code&gt;httpd_t&lt;/code&gt; permits — typically a narrow, well-defined set of files and network operations — rather than having the full access of the user account running Apache.&lt;/p&gt;</description></item><item><title>SSSD (System Security Services Daemon)</title><link>https://lesitedefrancois.be/en/security/sssd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/sssd/</guid><description>&lt;p&gt;&lt;strong&gt;SSSD (System Security Services Daemon)&lt;/strong&gt; is a multi-daemon suite that connects Linux systems to remote identity and authentication providers, presenting their data through the standard Linux identity interfaces — &lt;strong&gt;NSS (Name Service Switch)&lt;/strong&gt; for identity lookups (user names, UIDs, GIDs, group membership) and &lt;strong&gt;PAM (Pluggable Authentication Modules)&lt;/strong&gt; 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 &lt;strong&gt;LDAP&lt;/strong&gt; or &lt;strong&gt;AD&lt;/strong&gt; required configuring &lt;code&gt;nss_ldap&lt;/code&gt;, &lt;code&gt;pam_ldap&lt;/code&gt;, &lt;code&gt;pam_krb5&lt;/code&gt;, and &lt;code&gt;pam_winbind&lt;/code&gt; 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.&lt;/p&gt;</description></item><item><title>USBGuard</title><link>https://lesitedefrancois.be/en/security/usbguard/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/usbguard/</guid><description>&lt;p&gt;&lt;strong&gt;USBGuard&lt;/strong&gt; is a security framework for Linux that controls which USB devices are permitted to interact with the system. It sits above the kernel&amp;rsquo;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: &lt;strong&gt;BadUSB&lt;/strong&gt; 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 (&lt;code&gt;03:01:01&lt;/code&gt;) 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.&lt;/p&gt;</description></item></channel></rss>