In this lesson, you will learn how to restrict container access to physical hardware firmware interfaces to prevent attackers from using compromised containers to overwrite or exfiltrate sensitive system firmware.
The Firmware Threat Vector
Modern hardware relies on complex firmware (UEFI, BIOS, Option ROMs, and peripheral microcode) to initialize the system. When a container gains access to hardware interfaces—such as the /sys/class/firmware directory or raw access to memory-mapped IO (MMIO) regions—an attacker can potentially trigger a firmware update process or manipulate system configuration registers. If an attacker successfully compromises a container and manages to flash malicious firmware, they establish persistence that survives a host reboot and exists below the OS layer, effectively bypassing all LSM and namespace protections you have previously implemented.
Restricting Firmware Interfaces
To protect the system, you must ensure that containers never possess the privileges required to interact with the system's "System Management Mode" (SMM) or flash memory.
First, ensure that your container runtime does not mount firmware-related sysfs or debugfs nodes. Specifically, block access to /sys/firmware/efi/efivars. These variables hold critical boot configuration data; if writable, an attacker could change the BootOrder or execute malicious code during the next EFI boot phase.
You should use your existing AppArmor or SELinux knowledge to explicitly deny access to these paths. For example, in an AppArmor profile, you should deny write access to the firmware subsystem:
# Prevent container modification of UEFI variables
deny /sys/firmware/efi/efivars/** w,
# Prevent interaction with the firmware loader
deny /sys/class/firmware/** w,
Additionally, ensure that the kernel is booted with module_sig_enforce=1 and efi=disable_early_pci_dma. The latter mitigates the risk where an attacker uses a compromised device (via a container) to perform DMA attacks against the system memory, which could be used to bypass firmware protections.
By treating firmware as an immutable, off-limits resource rather than a peripheral interface, you close a critical gap that exists between your containerized workloads and the physical platform integrity.
Key Takeaway: Firmware isolation is achieved by explicitly denying container access to EFI variables and sysfs firmware interfaces via LSM policies, effectively locking the "hardware-level" door against container escapes.