initramfs (initial RAM filesystem) is the temporary root filesystem the Linux kernel mounts immediately after loading itself and before switching to the machine’s real root. The bootloader — GRUB, systemd-boot, or firmware loading a UKI — passes a compressed cpio image (historically called an initrd, though modern Linux always unpacks it as an initramfs into tmpfs, not a separate ramdisk block device). The kernel extracts this archive into an in-memory tree, executes /init as pid 1, and that early userspace environment is responsible for everything the bare kernel cannot yet do: loading storage and filesystem kernel modules, bringing up networking, discovering and unlocking LUKS volumes, activating LVM or multipath devices, mounting the true root partition, and finally calling switch_root (or pivot_root) to hand control to the installed system’s init — typically systemd on current distributions. If the initramfs fails, the boot stops before userspace on the real root ever starts; if it succeeds, it is discarded and its memory reclaimed once the pivot completes.
IMA (Integrity Measurement Architecture) is a Linux kernel subsystem, merged in kernel 2.6.30, that hooks into the kernel’s file access paths — execve(), mmap(), open() — and computes a cryptographic hash of each file’s contents before it is accessed, according to a configurable policy. It is the runtime half of the Linux integrity story: where TPM PCR measurements and Secure Boot cover what was loaded during the boot sequence, IMA covers what happens after the OS is running, hashing executables, libraries, kernel modules, firmware, and configuration files as they are opened, creating a continuously updated record of everything the system has actually used.
GRUB (GNU GRand Unified Bootloader) is the bootloader used by the majority of Linux distributions on x86 and x86-64 systems. Its role is to bridge the gap between what firmware hands control to and what the Linux kernel needs: firmware (BIOS or UEFI) loads GRUB, and GRUB locates the kernel image and initrd on disk, assembles a kernel command line, and transfers control to the kernel. Because GRUB understands a wide range of filesystem formats — ext4, XFS, Btrfs, FAT, and more — it can read its own configuration and the kernel directly from the root or boot partition without any intermediate step, which is what distinguishes it from simpler bootloaders that can only read from FAT.
fs-verity is a Linux kernel filesystem feature, merged in kernel 5.4, that provides read-only, content-addressable integrity verification at the individual file level. When fs-verity is enabled on a file (via the FS_IOC_ENABLE_VERITY ioctl), the kernel builds a Merkle tree of the file’s content blocks and stores it in a filesystem-specific location (in an ext4 or f2fs Merkle tree block range, or in a separate xattr-adjacent structure on btrfs). From that point, the file becomes immutable — writes are rejected — and every page read from the file is verified against the Merkle tree before being returned to userspace. The file’s fs-verity digest is the SHA-256 (or SHA-512) root hash of the Merkle tree, computable without reading the file at all once the tree is built: fsverity digest file returns this digest. A file’s fs-verity digest is a stable, content-derived identity: two files with the same content have the same digest, and any byte-level modification produces a different digest that verification will detect and reject with EIO. The kernel caches verified Merkle tree nodes in the page cache alongside file data, so the amortised verification overhead is low for sequentially-read files.
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.
eBPF (Extended Berkeley Packet Filter) is a Linux kernel subsystem, its modern form dating to kernel 3.18 (2014), that allows user-authored programs to run inside the kernel with near-native performance, subject to safety guarantees enforced at load time by a verifier. The name is historical: the original BPF (Berkeley Packet Filter, 1992) was a narrow packet filtering mechanism for tools like tcpdump. eBPF extended the instruction set, registers, and capabilities far beyond packet filtering into a general-purpose in-kernel programmability platform. The central design constraint is that eBPF programs must be provably safe: they cannot crash the kernel, loop infinitely, or access memory out of bounds. The verifier statically analyses every program at load time, checking that all memory accesses are bounds-checked, all loops are bounded or unrolled, and all pointer dereferences are preceded by null checks. Only programs that pass verification are accepted; once accepted, the kernel JIT-compiles the eBPF bytecode to native machine code for the host architecture — x86-64, ARM64, RISC-V — so eBPF programs run at the same speed as compiled kernel code, not as an interpreter.
dm-verity is a Linux device mapper target, available since kernel 3.4, that provides transparent read-only integrity verification for block devices. When a block device is mapped through dm-verity, every data block read from the underlying device is verified against a pre-computed Merkle tree of cryptographic hashes before being returned to the caller — any modification to any block, whether from corruption, bit rot, or deliberate tampering, produces a hash mismatch that dm-verity detects and handles according to its configured error mode. The verification is transparent to the filesystem and applications mounted above it: they read from the dm-verity device as if it were a normal block device, with no awareness that every read is being hash-checked. The security guarantee is that the integrity of the entire block device is committed to by a single root hash — a 32-byte SHA-256 value that covers the entire Merkle tree and therefore the entire data volume. If the root hash is known to be correct (because it was measured into a TPM PCR, embedded in a UKI, or signed by a Secure Boot key), then any verified read from the dm-verity device is guaranteed to return exactly the data that was present when the Merkle tree was computed.
composefs is a Linux filesystem technology created by Alexander Larsson and Giuseppe Scrivano at Red Hat that provides cryptographically verified, read-only filesystem trees with opportunistic file-level sharing across images. Its motivating problem is a gap that neither dm-verity nor plain overlayfs fills cleanly: dm-verity provides strong integrity over a whole block device but requires a self-contained disk image and cannot share files between images; overlayfs allows layered, shared filesystems but protects only file contents (via fs-verity) and not the directory structure or metadata — an attacker who can manipulate a file’s name, permissions, or position in the tree is not caught. composefs closes that gap by separately protecting content and metadata, then composing them at mount time.
Control Groups (cgroups) is a Linux kernel mechanism, introduced in 2.6.24 (2008), that organises processes into a hierarchy of named groups and uses controllers to account for and limit each group’s consumption of CPU time, memory, I/O bandwidth, and process count. Every container runtime in existence — Docker, containerd, CRI-O, Podman — uses cgroups to enforce the resource limits declared in a container spec (--memory, --cpus, requests.memory, limits.cpu). Every systemd service on a modern Linux system runs in its own cgroup slice. Without cgroups, a container or service could consume all available memory, CPU, or file descriptors, starving other workloads on the same host. The current production version is cgroups v2 (also written cgroupv2, unified hierarchy), stable since kernel 4.5 and the default on all major distributions since RHEL 9, Ubuntu 21.10, and Fedora 31.
bootc is a CNCF sandbox project, created by Colin Walters, that applies the OCI container model to operating system delivery. Where conventional container images package an application to run inside a host OS, a bootc image packages the entire OS — kernel (under /usr/lib/modules), initrd, systemd units, firmware, and all userspace — as a standard OCI image that can be built with podman build or buildah, stored in any OCI-conformant registry, signed with standard supply chain tools, and pulled to a machine where it becomes the running system. At runtime the base OS is not running inside a container; systemd is pid 1 as usual. The container image format is purely a transport and build model, not an execution model.
AppArmor (Application Armor) is a Mandatory Access Control (MAC) system implemented as a major LSM (Linux Security Module), developed originally by Immunix and now maintained by Canonical. It is the default MAC system on Ubuntu, Debian, and their derivatives, and the default container confinement mechanism for containerd and Docker on those distributions. Where SELinux assigns security labels to every object on the system and enforces policy based on label interactions, AppArmor takes a fundamentally different approach: it confines programs by filesystem path. A profile for nginx lists the specific file paths that nginx is allowed to read, write, and execute, the network operations it may perform, and the Linux capabilities it may use — anything not listed is denied. No relabelling of the filesystem is required and no extended attributes are set: AppArmor’s confinement decisions are made purely from the path of the file being accessed and the identity of the confined process. This path-based model makes AppArmor profiles far simpler to read, write, and audit than SELinux policy, and eliminates the mislabelled-file failure mode that is the most common SELinux operational problem.
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.
