In this lesson, you will learn how we extend access control beyond just file permissions to ensure that only authorized, untampered code is permitted to execute within the kernel space.
The Problem: Beyond User-Space Permissions
Up until now, we have focused on how Discretionary (ACLs) and Mandatory (SELinux/AppArmor) Access Controls manage who can read, write, or execute files. However, those controls operate on the assumption that the kernel itself is trustworthy and the binary on the disk is the one the developer intended to run. If an attacker replaces a system binary or injects malicious code into a kernel module, standard permissions won't stop them because the kernel is already compromised.
Establishing a Chain of Trust
To secure the execution environment, we implement Secure Boot and Runtime Integrity.
- Secure Boot: This acts as the "gatekeeper" at power-on. It verifies the digital signature of every component in the boot chain—from the firmware to the bootloader, and finally the kernel image. If the signature doesn't match a trusted key stored in the hardware (UEFI), the system refuses to boot. This ensures no rootkit can hook into the startup process.
- Runtime Integrity (IMA): Once the kernel is running, we use the Integrity Measurement Architecture (IMA). Think of this as an "access control check for execution." Before the kernel loads a binary or a library into memory, it calculates a cryptographic hash of that file and compares it against a known-good "golden" list of hashes (stored as extended attributes on the filesystem).
Concrete Illustration
If an attacker tries to overwrite /usr/bin/login with a malicious version, the file's hash changes. When you attempt to execute it, the kernel performs an integrity check:
# Conceptually, the kernel checks the file metadata:
# 1. Access Control (SELinux/ACL) - "Can this user execute this?"
# 2. Integrity Check (IMA) - "Has this file been modified since it was signed?"
If the hash doesn't match the signed policy, the kernel denies the execve() system call, effectively treating an unauthorized change as a violation of the system's runtime integrity.
Key Takeaway: Secure Boot ensures the kernel starts in a trusted state, while Runtime Integrity ensures that only verified, immutable code is permitted to execute within the kernel's domain.