Course contentsShow
← Linux
Lesson 446 of 1,8194. Advanced Access Control ModelsFree lesson

Securing Kernel Module Loading

Restrict the ability to load kernel modules based on file integrity and user privilege level.

In this lesson, you will learn how to restrict kernel module loading by enforcing strict file integrity checks and verifying the privilege level of the entity requesting the load.

Why Restrict Module Loading?

Kernel modules (.ko files) run with the highest level of system privilege. If an attacker can trick the system into loading a malicious module, they gain full control over the kernel. To prevent this, we move beyond simple file permissions and enforce a "trust chain" that verifies both the module's origin and the identity of the user attempting to load it.

Implementing Integrity-Based Control

The primary mechanism for this is Kernel Module Signing. By configuring the kernel to only accept modules cryptographically signed by a trusted key, you ensure that even if an attacker gains write access to the filesystem and replaces a module, the kernel will refuse to load it because the signature will not match.

To enforce this at the system level, you can set the following kernel parameter via /etc/sysctl.conf:

# Require all modules to be signed by a trusted key
kernel.modules_disabled = 0
kernel.sig_enforce = 1

Privileged Access Enforcement

Even with signed modules, you must limit who can trigger the loading process. In a hardened environment, you should ensure that only processes with the CAP_SYS_MODULE capability—and ideally, only those running under a specific security context defined by your Mandatory Access Control (MAC) system—can initiate a load.

You can verify if a user has the necessary permissions by checking their current capabilities:

# Check if the current user has the capability to load modules
capsh --print | grep cap_sys_module

By combining file integrity (the module must be signed by you) and privilege restriction (the user must hold the CAP_SYS_MODULE capability), you create a "fail-closed" security posture. If a module lacks a valid signature or is requested by an unprivileged user, the kernel will block the operation and log the attempt, effectively neutralizing the risk of unauthorized rootkits being inserted into your running system.

Key Takeaway: Secure your kernel by mandating cryptographic signatures for all modules and strictly limiting the CAP_SYS_MODULE capability to trusted administrative processes.