Operating SystemsLoadable Kernel Modules

Loadable Kernel Modules

LevelIntermediate

Duration75 mins

TopicLoadable Kernel Modules

5 / 5

Security Implications

The Double-Edged Sword of Kernel Extensibility

Loadable kernel modules are perhaps the most powerful and dangerous feature of modern operating systems. The same capability that enables seamless hardware support and system flexibility also creates a direct pathway for malicious code to execute with the highest system privileges.

A loaded kernel module runs in ring 0—the same privilege level as the kernel itself. It can:

Access any memory in the system
Intercept and modify any system call
Hide its presence from detection tools
Persist across security software updates
Compromise any process, including security software

This makes kernel modules the ultimate target for advanced attackers and the ultimate responsibility for system defenders. Understanding the security implications of kernel modules is not optional for anyone working with Linux security.

What You Will Learn

By the end of this page, you will understand the complete security landscape of kernel modules: attack vectors from rootkits to supply chain compromise, defense mechanisms including module signing and Secure Boot, mandatory access controls, and operational best practices for secure module management.

The Threat Landscape

Kernel modules present a uniquely attractive target for attackers because of the unparalleled access they provide. Understanding the threat landscape helps prioritize defensive measures.

Why attackers target kernel modules:

Attacker Motivations for Kernel Module Exploitation

•Complete system control — Kernel code can access any resource, bypass any check, and override any policy.
•Persistence — Kernel modules survive user-space security updates and can reinstall themselves after removal attempts.
•Stealth — From kernel space, malware can hide processes, files, network connections, and even itself from detection tools.
•Security software bypass — Kernel-level malware operates at a higher privilege than most security software.
•Credential harvesting — Direct access to memory allows capturing passwords, encryption keys, and authentication tokens.
•Network interception — Kernel-level access enables invisible traffic sniffing and modification.

Historical precedents:

Kernel module attacks are not theoretical—they have been deployed in the wild:

Sony BMG Rootkit (2005) — Installed hidden kernel components for DRM enforcement
Rustock (2006-2011) — Kernel driver-based spam botnet affecting millions of machines
Uroburos/Snake (2014) — Nation-state APT using kernel drivers for persistence
DoublePulsar (2017) — NSA-derived tool installing kernel backdoors
Slingshot APT (2018) — Replaced router drivers with weaponized versions
Netfilter Rootkit (2021) — Posed as legitimate driver signed by Microsoft WHQL

These examples demonstrate that kernel module attacks span from corporate overreach to nation-state operations.

Advanced Persistent Threats

Sophisticated attackers specifically target kernel modules because traditional security software operates at user level and cannot reliably detect kernel-level compromise. Once an attacker achieves kernel execution, they effectively control the 'truth' the OS reports about itself.

Attack Vectors

Understanding how attackers compromise systems through kernel modules reveals where defenses must be focused.

Direct module loading:

The simplest attack: obtain root access and load a malicious module.

# Attacker with root access
$ sudo insmod rootkit.ko
# System now compromised at kernel level

This requires existing root access, but root-to-kernel escalation dramatically increases attacker capabilities. Even if the root account is recovered, the kernel module may persist or reinfect.

Vulnerability exploitation:

Kernel modules are code, and code has bugs. Vulnerabilities in modules can be exploited:

Buffer overflows in driver IOCTL handlers
Use-after-free in device cleanup paths
Race conditions in concurrent code
Integer overflows in size calculations

Module Attack Vector Categories
Vector	Required Access	Attack Complexity	Example
Direct loading	Root/sudo	Low	insmod malicious.ko
Vulnerability exploit	Varies (may be unprivileged)	High	CVE-2017-6001 (race in ip_vs)
Supply chain	None (compromised source)	Very High	Compromised driver download
Firmware compromise	Physical/firmware access	Very High	Malicious UEFI driver
Trojanized module	Development access	Medium	Backdoored open-source driver
Signed driver abuse	Code signing access	High	Stolen/purchased signing cert

Supply chain attacks:

Attackers increasingly target the development and distribution pipeline:

Compromise developer workstations
Inject malicious code into driver source repositories
Compromise build systems to inject code during compilation
Attack distribution infrastructure to replace legitimate modules

These attacks are especially dangerous because they can affect many systems simultaneously and may evade signature verification if they compromise the signing infrastructure.

Signed driver abuse:

On systems with Secure Boot, modules must be signed. Attackers circumvent this by:

Stealing signing keys from legitimate vendors
Tricking certificate authorities into issuing certificates
Purchasing certificates through fraudulent companies
Exploiting vulnerabilities in legitimately signed but poorly written drivers

The WHQL Problem

Windows Hardware Quality Labs (WHQL) signing has been abused by attackers who submitted malicious drivers for Microsoft signing. Similar risks exist for any signing authority. Signature verification proves authenticity, not safety—a signed module can still be malicious if the signer is compromised or complicit.

Kernel Module Rootkits

A rootkit is malware designed to hide its presence and that of other malicious software. Kernel module rootkits are the most powerful form because they can manipulate the kernel's view of the system.

Rootkit techniques:

rootkit_techniques.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// ===== EDUCATIONAL EXAMPLE - DO NOT USE FOR MALICIOUS PURPOSES =====
 
// 1. SYSTEM CALL TABLE HOOKING
// Replace entries in the syscall table to intercept calls
 
// Find the syscall table (varies by kernel)
unsigned long *sys_call_table;
 
// Original function pointer
asmlinkage long (*original_read)(unsigned int, char __user *, size_t);
 
// Hook function
asmlinkage long hooked_read(unsigned int fd, char __user *buf, size_t count) {
    long ret = original_read(fd, buf, count);
    // Hide specific content, log data, etc.
    return ret;
}
 
// Installation (simplified, ignores write protection)
original_read = (void *)sys_call_table[__NR_read];
sys_call_table[__NR_read] = (unsigned long)hooked_read;
 
// 2. VFS HOOKING
// Intercept filesystem operations
 
struct file_operations *proc_fops;
original_iterate = proc_fops->iterate_shared;
proc_fops->iterate_shared = hooked_iterate;
 
// 3. PROCESS HIDING
// Remove process from task list
 
list_del(&target_task->tasks);  // Hide from ps, top
// Process still runs but is invisible
 
// 4. MODULE HIDING
// Hide the rootkit module itself
 
list_del(&THIS_MODULE->list);   // Hide from lsmod
kobject_del(&THIS_MODULE->mkobj.kobj);  // Hide from /sys

Detection challenges:

Kernel rootkits are exceptionally difficult to detect because they can:

Hide from process listings by unlinking from task lists
Hide files and directories by hooking VFS operations
Hide network connections by filtering /proc/net data
Hide modules by removing from module lists (lsmod shows nothing)
Subvert security software that relies on kernel APIs for information

Detection approaches:

Cross-view analysis — Compare results from different methods (syscalls vs. direct memory reading)
Memory forensics — Analyze raw memory dumps for anomalies
Integrity verification — Compare kernel memory against known-good states
Hardware-assisted — Use CPU virtualization to inspect kernel from hypervisor
Boot-time verification — Validate kernel and modules before they execute

The Trust Problem

Once a kernel rootkit is installed, you cannot trust any information from that system. The kernel controls what user-space tools see. The only reliable analysis requires external observation: memory dumps, network monitoring from another machine, or hypervisor-level inspection.

Module Signing

Module signing is a key defense mechanism that ensures only cryptographically authenticated modules can be loaded. Linux supports mandatory module signature verification starting from kernel 3.7.

How module signing works:

1. Kernel build generates signing key pair:
   - Private key: signs modules
   - Public key: embedded in kernel

2. Modules signed during build:
   sign-file sha256 signing_key.priv signing_key.x509 module.ko

3. At load time, kernel verifies signature:
   - Computes hash of module
   - Verifies signature against embedded public key
   - Rejects module if verification fails (when enforced)

module_signing.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Check if module signing is enabled in kernel
$ grep CONFIG_MODULE_SIG /boot/config-$(uname -r)
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y  # Reject unsigned modules
CONFIG_MODULE_SIG_ALL=y    # Sign all modules during build
CONFIG_MODULE_SIG_SHA256=y # Hash algorithm
 
# Check if a module is signed
$ modinfo mymodule.ko | grep -E '^sig'
sig_id:         PKCS#7
sig_key:        01:23:45:67:89:AB:CD:EF...
sig_hashalgo:   sha256
signature:      30:82:04:...
 
# Check kernel signature enforcement mode
$ cat /proc/cmdline
... module.sig_enforce=1 ...
 
# Sign a module manually (requires private key access)
$ /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
    ./signing_key.priv \
    ./signing_key.x509 \
    mymodule.ko
 
# Generate a new key pair for signing
$ openssl req -new -x509 -newkey rsa:4096 \
    -keyout signing_key.priv \
    -out signing_key.x509 \
    -days 36500 \
    -nodes \
    -subj "/CN=Kernel Module Signing Key/"
 
# Attempting to load unsigned module with enforcement
$ insmod unsigned.ko
insmod: ERROR: could not insert module: Required key not available

Kernel Module Signing Configuration Options
Option	Effect	Security Level
CONFIG_MODULE_SIG=n	No signature checking	None
CONFIG_MODULE_SIG=y only	Check sigs, allow unsigned	Weak (logging only)
CONFIG_MODULE_SIG_FORCE=y	Reject unsigned modules	Strong
module.sig_enforce=1	Runtime enforcement	Bootloader controlled
Lockdown=integrity	Additional restrictions	Very strong

Key Management

The signing private key must be protected rigorously. If compromised, attackers can sign malicious modules. Best practice: generate key at build time, sign modules, then destroy private key. For distributions, use HSM (Hardware Security Module) for key protection.

Secure Boot Integration

Secure Boot extends trust from firmware through bootloader to kernel to modules, creating a verified chain of boot. When combined with module signing, it provides strong protection against unauthorized kernel code execution.

The chain of trust:

UEFI Firmware (immutable root of trust)
         ↓ verifies signature
Bootloader (e.g., GRUB, signed by Microsoft/vendor)
         ↓ verifies signature
Linux Kernel (signed by distribution)
         ↓ verifies signatures
Kernel Modules (signed by distribution or MOK)

secure_boot.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Check Secure Boot status
$ mokutil --sb-state
SecureBoot enabled
 
# List enrolled keys (Machine Owner Keys)
$ mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67
Subject: CN=My Custom Key
 
# Enroll new key for module signing (requires reboot)
$ sudo mokutil --import my_signing_key.der
Input password for new MOK: ****
Confirm password: ****
# Reboot, MOK Manager prompts to enroll key
 
# Generate key and enroll for DKMS modules
$ openssl req -new -x509 -newkey rsa:4096 \
    -keyout MOK.priv -out MOK.der \
    -outform DER -days 36500 -nodes \
    -subj "/CN=Custom Kernel Module Signing Key/"
    
$ sudo mokutil --import MOK.der
 
# Configure DKMS to use the key
$ cat /etc/dkms/sign_helper.sh
#!/bin/bash
/usr/src/linux-headers-$1/scripts/sign-file sha256 \
    /root/MOK.priv \
    /root/MOK.der "$2"
 
# Sign DKMS-built modules
$ sudo dkms autoinstall --sign

Machine Owner Key (MOK) enrollment:

Distributions like Ubuntu and Fedora use a secondary key database called MOK to allow users to sign their own modules:

User generates a key pair
User enrolls public key with mokutil --import
On reboot, UEFI firmware prompts to confirm enrollment
Key is now trusted for module signatures

This enables third-party and custom module signing while maintaining Secure Boot.

Lockdown mode:

Kernel lockdown provides additional security beyond module signing:

Blocks access to /dev/mem and /dev/kmem
Prevents writing to MSR registers
Blocks eBPF write to kernel memory
Prevents hibernation (which could modify kernel)
Restricts kexec to signed kernels

$ cat /sys/kernel/security/lockdown
[none] integrity confidentiality

# Enable via boot parameter
GRUB_CMDLINE_LINUX="lockdown=integrity"

Shim and Distribution Keys

Most Linux distributions use 'shim' — a small bootloader signed by Microsoft that contains the distribution's key. Shim verifies the GRUB bootloader, which verifies the kernel. This allows Linux to boot on systems that only trust Microsoft's key.

Mandatory Access Controls

Mandatory Access Control (MAC) systems like SELinux and AppArmor can restrict module loading operations, providing defense-in-depth beyond signature verification.

SELinux module loading controls:

SELinux can restrict which processes can load modules and from where:

# SELinux module loading permissions
allow init_t self:capability sys_module;
allow init_t modules_object_t:file { read getattr execute };
allow init_t kernel_t:system module_load;

# Deny module loading from untrusted paths
neverallow * { usb_device_t removable_device_t }:file module_load;

mac_controls.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# SELinux: Check module loading permissions
$ sesearch --allow --source init_t --target kernel_t --class system
allow init_t kernel_t:system module_load;
 
# SELinux: View module loading denials
$ ausearch -m AVC -c modprobe
type=AVC msg=audit(1234567890.123:456): avc:  denied  { module_load }
 
# AppArmor: Profile restricting module loading
$ cat /etc/apparmor.d/sbin.insmod
#include <tunables/global>
 
/sbin/insmod {
  #include <abstractions/base>
  
  capability sys_module,
  
  /lib/modules/** r,
  /lib/modules/**/*.ko r,
  
  # Deny loading from removable media
  deny /media/** r,
  deny /mnt/** r,
}
 
# Systemd: Restrict module loading capabilities
$ cat /etc/systemd/system/myservice.service.d/security.conf
[Service]
CapabilityBoundingSet=~CAP_SYS_MODULE
SystemCallFilter=~finit_module init_module
 
# View capability in running process
$ getpcaps $$ 
$$ = cap_chown,cap_dac_override,...
# Note: cap_sys_module should NOT be present for most processes

Defense in Depth Layers

•Root access required — First barrier: only root/sudo can load modules (CAP_SYS_MODULE)
•Module signing — Second barrier: modules must be cryptographically signed
•Secure Boot — Third barrier: kernel and bootloader are verified
•MAC policies — Fourth barrier: SELinux/AppArmor restrict loading by context
•Syscall filtering — Fifth barrier: seccomp can block init_module syscalls
•Kernel lockdown — Sixth barrier: prevents runtime kernel modification
•Integrity monitoring — Detection layer: audit and alert on module operations

CAP_SYS_MODULE

The CAP_SYS_MODULE capability allows loading kernel modules. Grant it only to processes that absolutely require it. Container runtimes, unprivileged users, and most services should never have this capability. Docker containers typically do not have CAP_SYS_MODULE by default.

Operational Best Practices

Security requires not just tools but also operational discipline. The following best practices help reduce the attack surface and risk associated with kernel modules.

Minimize module surface area:

security_hardening.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# 1. DISABLE UNNECESSARY MODULE LOADING (after boot)
# Add to /etc/sysctl.d/50-modules.conf
kernel.modules_disabled = 1  # After setting, no new modules can load
$ sysctl -w kernel.modules_disabled=1
 
# 2. BLACKLIST UNUSED MODULES
$ cat /etc/modprobe.d/security-blacklist.conf
# Unused filesystems
install cramfs /bin/false
install freevxfs /bin/false
install hfs /bin/false
install hfsplus /bin/false
install jffs2 /bin/false
install udf /bin/false
 
# Unused network protocols
install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false
 
# Unusual bus types
install firewire-core /bin/false
install firewire-ohci /bin/false
 
# 3. AUDIT MODULE OPERATIONS
$ cat /etc/audit/rules.d/99-modules.rules
# Log all module loading
-a always,exit -F arch=b64 -S init_module -S finit_module -k modules
-a always,exit -F arch=b64 -S delete_module -k modules
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
 
# 4. MONITOR FOR UNSIGNED MODULES
$ for mod in /sys/module/*/taint; do 
    grep -q O "$mod" 2>/dev/null && echo "$(dirname $mod): out-of-tree"; 
    grep -q E "$mod" 2>/dev/null && echo "$(dirname $mod): unsigned"; 
done
 
# 5. VERIFY MODULE INTEGRITY
$ cat /usr/local/bin/verify-modules.sh
#!/bin/bash
for ko in /lib/modules/$(uname -r)/**/*.ko; do
    if ! /usr/src/linux-headers-$(uname -r)/scripts/sign-file -d sha256 \
         /dev/null /dev/null "$ko" 2>/dev/null | grep -q "valid"; then
        echo "UNSIGNED: $ko"
    fi
done

Security Best Practices Summary

•Enable module signing enforcement — Set CONFIG_MODULE_SIG_FORCE or use module.sig_enforce boot parameter.
•Enable Secure Boot — Ensure chain of trust from firmware to modules.
•Disable module loading after boot — Set kernel.modules_disabled=1 for static systems.
•Blacklist unused modules — Reduce attack surface by preventing unnecessary module loading.
•Enable audit logging — Log all module operations for forensic analysis.
•Regular integrity verification — Periodically verify module signatures haven't been tampered with.
•Limit CAP_SYS_MODULE — Drop this capability from all processes that don't require it.
•Use immutable infrastructure — Where possible, prevent runtime modification entirely.

Container Security

Containers share the host kernel and typically cannot load modules. This is a significant security advantage of containerized workloads—even a container root compromise cannot directly install kernel modules. Ensure container runtimes are configured to drop CAP_SYS_MODULE.

The Flexibility vs Security Tradeoff

The module security landscape embodies a fundamental tension in system design: flexibility versus security. More restrictions improve security but reduce usability. Finding the right balance requires understanding the tradeoffs.

Security Configuration Tradeoffs
Setting	Security Benefit	Flexibility Cost
modules_disabled=1	No runtime module loading	Cannot add new hardware; requires reboot
sig_enforce=1	Only signed modules load	DKMS modules need MOK enrollment
Secure Boot	Verified boot chain	Custom kernel/module development harder
lockdown=integrity	Prevents kernel modification	Breaks some debugging/tuning tools
Blacklisting	Reduces attack surface	May break unexpected functionality

Context-appropriate security:

Different environments warrant different security postures:

High-security production servers:

Enable all security features
Use modules_disabled after boot
Mandatory Secure Boot and signing
Comprehensive audit logging

Development workstations:

Module signing optional
Frequent module reloading needed
Secure Boot may complicate development
Balance productivity with reasonable protection

Embedded/IoT devices:

Static module configuration at build time
No module loading at runtime
Verified boot from known-good image
Limited attack surface by design

Cloud/container environments:

Host kernel secured; containers can't load modules
Hypervisor provides additional isolation
Focus on host-level module security

The Future: eBPF

eBPF provides a safer alternative to modules for some use cases—it allows running sandboxed programs in kernel context with verification. However, eBPF itself has security implications and doesn't replace all module functionality. The security landscape continues to evolve.

Summary: Securing Kernel Extensibility

Kernel module security is one of the most critical aspects of system security. The power that makes modules useful—direct kernel-level access—makes them dangerous in the wrong hands. Let's consolidate the key security concepts:

Key Takeaways

•Kernel modules are the ultimate attack vector—ring 0 access means complete system control, stealth capability, and security software bypass.
•Rootkits leverage kernel access to hide processes, files, and network connections. Detection requires cross-view analysis or external observation.
•Module signing cryptographically authenticates modules, preventing unauthorized code from loading when enforcement is enabled.
•Secure Boot extends trust from firmware through kernel to modules, creating a verified chain of boot.
•Mandatory Access Controls (SELinux, AppArmor) provide additional layers restricting module operations by context.
•Operational practices matter—blacklisting, auditing, capability restriction, and integrity monitoring reduce risk.
•Defense in depth combines multiple barriers: root access, signing, Secure Boot, MAC, syscall filtering, and lockdown.
•Balance flexibility and security according to your environment—development and production have different needs.

Module security is not optional:

In an era of sophisticated attackers, kernel module security cannot be an afterthought. Whether you're a system administrator, kernel developer, or security engineer, understanding these risks and defenses is essential. The kernel is the foundation of everything—when it's compromised, nothing on the system can be trusted.

This completes our exploration of Loadable Kernel Modules. You now understand their internal structure, management, advantages, and security implications—knowledge that forms the foundation for effective Linux system engineering.

Module Complete

Congratulations! You've completed the Loadable Kernel Modules module. You now understand dynamic loading mechanisms, Linux .ko format, module advantages, management tools, and the critical security considerations. This knowledge is essential for anyone working with Linux at the operating system level.

5 / 5

Loading learning content...

Operating SystemsLoadable Kernel Modules

Loadable Kernel Modules

LevelIntermediate

Duration75 mins

TopicLoadable Kernel Modules

5 / 5

Security Implications

The Double-Edged Sword of Kernel Extensibility

A loaded kernel module runs in ring 0—the same privilege level as the kernel itself. It can:

Access any memory in the system
Intercept and modify any system call
Hide its presence from detection tools
Persist across security software updates
Compromise any process, including security software

What You Will Learn

The Threat Landscape

Kernel modules present a uniquely attractive target for attackers because of the unparalleled access they provide. Understanding the threat landscape helps prioritize defensive measures.

Why attackers target kernel modules:

Attacker Motivations for Kernel Module Exploitation

•Complete system control — Kernel code can access any resource, bypass any check, and override any policy.
•Persistence — Kernel modules survive user-space security updates and can reinstall themselves after removal attempts.
•Stealth — From kernel space, malware can hide processes, files, network connections, and even itself from detection tools.
•Security software bypass — Kernel-level malware operates at a higher privilege than most security software.
•Credential harvesting — Direct access to memory allows capturing passwords, encryption keys, and authentication tokens.
•Network interception — Kernel-level access enables invisible traffic sniffing and modification.

Historical precedents:

Kernel module attacks are not theoretical—they have been deployed in the wild:

Sony BMG Rootkit (2005) — Installed hidden kernel components for DRM enforcement
Rustock (2006-2011) — Kernel driver-based spam botnet affecting millions of machines
Uroburos/Snake (2014) — Nation-state APT using kernel drivers for persistence
DoublePulsar (2017) — NSA-derived tool installing kernel backdoors
Slingshot APT (2018) — Replaced router drivers with weaponized versions
Netfilter Rootkit (2021) — Posed as legitimate driver signed by Microsoft WHQL

These examples demonstrate that kernel module attacks span from corporate overreach to nation-state operations.

Advanced Persistent Threats

Attack Vectors

Understanding how attackers compromise systems through kernel modules reveals where defenses must be focused.

Direct module loading:

The simplest attack: obtain root access and load a malicious module.

# Attacker with root access
$ sudo insmod rootkit.ko
# System now compromised at kernel level

This requires existing root access, but root-to-kernel escalation dramatically increases attacker capabilities. Even if the root account is recovered, the kernel module may persist or reinfect.

Vulnerability exploitation:

Kernel modules are code, and code has bugs. Vulnerabilities in modules can be exploited:

Buffer overflows in driver IOCTL handlers
Use-after-free in device cleanup paths
Race conditions in concurrent code
Integer overflows in size calculations

Module Attack Vector Categories
Vector	Required Access	Attack Complexity	Example
Direct loading	Root/sudo	Low	insmod malicious.ko
Vulnerability exploit	Varies (may be unprivileged)	High	CVE-2017-6001 (race in ip_vs)
Supply chain	None (compromised source)	Very High	Compromised driver download
Firmware compromise	Physical/firmware access	Very High	Malicious UEFI driver
Trojanized module	Development access	Medium	Backdoored open-source driver
Signed driver abuse	Code signing access	High	Stolen/purchased signing cert

Supply chain attacks:

Attackers increasingly target the development and distribution pipeline:

Compromise developer workstations
Inject malicious code into driver source repositories
Compromise build systems to inject code during compilation
Attack distribution infrastructure to replace legitimate modules

These attacks are especially dangerous because they can affect many systems simultaneously and may evade signature verification if they compromise the signing infrastructure.

Signed driver abuse:

On systems with Secure Boot, modules must be signed. Attackers circumvent this by:

Stealing signing keys from legitimate vendors
Tricking certificate authorities into issuing certificates
Purchasing certificates through fraudulent companies
Exploiting vulnerabilities in legitimately signed but poorly written drivers

The WHQL Problem

Kernel Module Rootkits

Rootkit techniques:

rootkit_techniques.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// ===== EDUCATIONAL EXAMPLE - DO NOT USE FOR MALICIOUS PURPOSES =====
 
// 1. SYSTEM CALL TABLE HOOKING
// Replace entries in the syscall table to intercept calls
 
// Find the syscall table (varies by kernel)
unsigned long *sys_call_table;
 
// Original function pointer
asmlinkage long (*original_read)(unsigned int, char __user *, size_t);
 
// Hook function
asmlinkage long hooked_read(unsigned int fd, char __user *buf, size_t count) {
    long ret = original_read(fd, buf, count);
    // Hide specific content, log data, etc.
    return ret;
}
 
// Installation (simplified, ignores write protection)
original_read = (void *)sys_call_table[__NR_read];
sys_call_table[__NR_read] = (unsigned long)hooked_read;
 
// 2. VFS HOOKING
// Intercept filesystem operations
 
struct file_operations *proc_fops;
original_iterate = proc_fops->iterate_shared;
proc_fops->iterate_shared = hooked_iterate;
 
// 3. PROCESS HIDING
// Remove process from task list
 
list_del(&target_task->tasks);  // Hide from ps, top
// Process still runs but is invisible
 
// 4. MODULE HIDING
// Hide the rootkit module itself
 
list_del(&THIS_MODULE->list);   // Hide from lsmod
kobject_del(&THIS_MODULE->mkobj.kobj);  // Hide from /sys

Detection challenges:

Kernel rootkits are exceptionally difficult to detect because they can:

Hide from process listings by unlinking from task lists
Hide files and directories by hooking VFS operations
Hide network connections by filtering /proc/net data
Hide modules by removing from module lists (lsmod shows nothing)
Subvert security software that relies on kernel APIs for information

Detection approaches:

Cross-view analysis — Compare results from different methods (syscalls vs. direct memory reading)
Memory forensics — Analyze raw memory dumps for anomalies
Integrity verification — Compare kernel memory against known-good states
Hardware-assisted — Use CPU virtualization to inspect kernel from hypervisor
Boot-time verification — Validate kernel and modules before they execute

The Trust Problem

Module Signing

Module signing is a key defense mechanism that ensures only cryptographically authenticated modules can be loaded. Linux supports mandatory module signature verification starting from kernel 3.7.

How module signing works:

1. Kernel build generates signing key pair:
   - Private key: signs modules
   - Public key: embedded in kernel

2. Modules signed during build:
   sign-file sha256 signing_key.priv signing_key.x509 module.ko

3. At load time, kernel verifies signature:
   - Computes hash of module
   - Verifies signature against embedded public key
   - Rejects module if verification fails (when enforced)

module_signing.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Check if module signing is enabled in kernel
$ grep CONFIG_MODULE_SIG /boot/config-$(uname -r)
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y  # Reject unsigned modules
CONFIG_MODULE_SIG_ALL=y    # Sign all modules during build
CONFIG_MODULE_SIG_SHA256=y # Hash algorithm
 
# Check if a module is signed
$ modinfo mymodule.ko | grep -E '^sig'
sig_id:         PKCS#7
sig_key:        01:23:45:67:89:AB:CD:EF...
sig_hashalgo:   sha256
signature:      30:82:04:...
 
# Check kernel signature enforcement mode
$ cat /proc/cmdline
... module.sig_enforce=1 ...
 
# Sign a module manually (requires private key access)
$ /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
    ./signing_key.priv \
    ./signing_key.x509 \
    mymodule.ko
 
# Generate a new key pair for signing
$ openssl req -new -x509 -newkey rsa:4096 \
    -keyout signing_key.priv \
    -out signing_key.x509 \
    -days 36500 \
    -nodes \
    -subj "/CN=Kernel Module Signing Key/"
 
# Attempting to load unsigned module with enforcement
$ insmod unsigned.ko
insmod: ERROR: could not insert module: Required key not available

Kernel Module Signing Configuration Options
Option	Effect	Security Level
CONFIG_MODULE_SIG=n	No signature checking	None
CONFIG_MODULE_SIG=y only	Check sigs, allow unsigned	Weak (logging only)
CONFIG_MODULE_SIG_FORCE=y	Reject unsigned modules	Strong
module.sig_enforce=1	Runtime enforcement	Bootloader controlled
Lockdown=integrity	Additional restrictions	Very strong

Key Management

Secure Boot Integration

The chain of trust:

UEFI Firmware (immutable root of trust)
         ↓ verifies signature
Bootloader (e.g., GRUB, signed by Microsoft/vendor)
         ↓ verifies signature
Linux Kernel (signed by distribution)
         ↓ verifies signatures
Kernel Modules (signed by distribution or MOK)

secure_boot.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Check Secure Boot status
$ mokutil --sb-state
SecureBoot enabled
 
# List enrolled keys (Machine Owner Keys)
$ mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef:01:23:45:67
Subject: CN=My Custom Key
 
# Enroll new key for module signing (requires reboot)
$ sudo mokutil --import my_signing_key.der
Input password for new MOK: ****
Confirm password: ****
# Reboot, MOK Manager prompts to enroll key
 
# Generate key and enroll for DKMS modules
$ openssl req -new -x509 -newkey rsa:4096 \
    -keyout MOK.priv -out MOK.der \
    -outform DER -days 36500 -nodes \
    -subj "/CN=Custom Kernel Module Signing Key/"
    
$ sudo mokutil --import MOK.der
 
# Configure DKMS to use the key
$ cat /etc/dkms/sign_helper.sh
#!/bin/bash
/usr/src/linux-headers-$1/scripts/sign-file sha256 \
    /root/MOK.priv \
    /root/MOK.der "$2"
 
# Sign DKMS-built modules
$ sudo dkms autoinstall --sign

Machine Owner Key (MOK) enrollment:

Distributions like Ubuntu and Fedora use a secondary key database called MOK to allow users to sign their own modules:

User generates a key pair
User enrolls public key with mokutil --import
On reboot, UEFI firmware prompts to confirm enrollment
Key is now trusted for module signatures

This enables third-party and custom module signing while maintaining Secure Boot.

Lockdown mode:

Kernel lockdown provides additional security beyond module signing:

Blocks access to /dev/mem and /dev/kmem
Prevents writing to MSR registers
Blocks eBPF write to kernel memory
Prevents hibernation (which could modify kernel)
Restricts kexec to signed kernels

$ cat /sys/kernel/security/lockdown
[none] integrity confidentiality

# Enable via boot parameter
GRUB_CMDLINE_LINUX="lockdown=integrity"

Shim and Distribution Keys

Mandatory Access Controls

Mandatory Access Control (MAC) systems like SELinux and AppArmor can restrict module loading operations, providing defense-in-depth beyond signature verification.

SELinux module loading controls:

SELinux can restrict which processes can load modules and from where:

# SELinux module loading permissions
allow init_t self:capability sys_module;
allow init_t modules_object_t:file { read getattr execute };
allow init_t kernel_t:system module_load;

# Deny module loading from untrusted paths
neverallow * { usb_device_t removable_device_t }:file module_load;

mac_controls.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# SELinux: Check module loading permissions
$ sesearch --allow --source init_t --target kernel_t --class system
allow init_t kernel_t:system module_load;
 
# SELinux: View module loading denials
$ ausearch -m AVC -c modprobe
type=AVC msg=audit(1234567890.123:456): avc:  denied  { module_load }
 
# AppArmor: Profile restricting module loading
$ cat /etc/apparmor.d/sbin.insmod
#include <tunables/global>
 
/sbin/insmod {
  #include <abstractions/base>
  
  capability sys_module,
  
  /lib/modules/** r,
  /lib/modules/**/*.ko r,
  
  # Deny loading from removable media
  deny /media/** r,
  deny /mnt/** r,
}
 
# Systemd: Restrict module loading capabilities
$ cat /etc/systemd/system/myservice.service.d/security.conf
[Service]
CapabilityBoundingSet=~CAP_SYS_MODULE
SystemCallFilter=~finit_module init_module
 
# View capability in running process
$ getpcaps $$ 
$$ = cap_chown,cap_dac_override,...
# Note: cap_sys_module should NOT be present for most processes

Defense in Depth Layers

•Root access required — First barrier: only root/sudo can load modules (CAP_SYS_MODULE)
•Module signing — Second barrier: modules must be cryptographically signed
•Secure Boot — Third barrier: kernel and bootloader are verified
•MAC policies — Fourth barrier: SELinux/AppArmor restrict loading by context
•Syscall filtering — Fifth barrier: seccomp can block init_module syscalls
•Kernel lockdown — Sixth barrier: prevents runtime kernel modification
•Integrity monitoring — Detection layer: audit and alert on module operations

CAP_SYS_MODULE

Operational Best Practices

Security requires not just tools but also operational discipline. The following best practices help reduce the attack surface and risk associated with kernel modules.

Minimize module surface area:

security_hardening.sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# 1. DISABLE UNNECESSARY MODULE LOADING (after boot)
# Add to /etc/sysctl.d/50-modules.conf
kernel.modules_disabled = 1  # After setting, no new modules can load
$ sysctl -w kernel.modules_disabled=1
 
# 2. BLACKLIST UNUSED MODULES
$ cat /etc/modprobe.d/security-blacklist.conf
# Unused filesystems
install cramfs /bin/false
install freevxfs /bin/false
install hfs /bin/false
install hfsplus /bin/false
install jffs2 /bin/false
install udf /bin/false
 
# Unused network protocols
install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false
 
# Unusual bus types
install firewire-core /bin/false
install firewire-ohci /bin/false
 
# 3. AUDIT MODULE OPERATIONS
$ cat /etc/audit/rules.d/99-modules.rules
# Log all module loading
-a always,exit -F arch=b64 -S init_module -S finit_module -k modules
-a always,exit -F arch=b64 -S delete_module -k modules
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
 
# 4. MONITOR FOR UNSIGNED MODULES
$ for mod in /sys/module/*/taint; do 
    grep -q O "$mod" 2>/dev/null && echo "$(dirname $mod): out-of-tree"; 
    grep -q E "$mod" 2>/dev/null && echo "$(dirname $mod): unsigned"; 
done
 
# 5. VERIFY MODULE INTEGRITY
$ cat /usr/local/bin/verify-modules.sh
#!/bin/bash
for ko in /lib/modules/$(uname -r)/**/*.ko; do
    if ! /usr/src/linux-headers-$(uname -r)/scripts/sign-file -d sha256 \
         /dev/null /dev/null "$ko" 2>/dev/null | grep -q "valid"; then
        echo "UNSIGNED: $ko"
    fi
done

Security Best Practices Summary

•Enable module signing enforcement — Set CONFIG_MODULE_SIG_FORCE or use module.sig_enforce boot parameter.
•Enable Secure Boot — Ensure chain of trust from firmware to modules.
•Disable module loading after boot — Set kernel.modules_disabled=1 for static systems.
•Blacklist unused modules — Reduce attack surface by preventing unnecessary module loading.
•Enable audit logging — Log all module operations for forensic analysis.
•Regular integrity verification — Periodically verify module signatures haven't been tampered with.
•Limit CAP_SYS_MODULE — Drop this capability from all processes that don't require it.
•Use immutable infrastructure — Where possible, prevent runtime modification entirely.

Container Security

The Flexibility vs Security Tradeoff

Security Configuration Tradeoffs
Setting	Security Benefit	Flexibility Cost
modules_disabled=1	No runtime module loading	Cannot add new hardware; requires reboot
sig_enforce=1	Only signed modules load	DKMS modules need MOK enrollment
Secure Boot	Verified boot chain	Custom kernel/module development harder
lockdown=integrity	Prevents kernel modification	Breaks some debugging/tuning tools
Blacklisting	Reduces attack surface	May break unexpected functionality

Context-appropriate security:

Different environments warrant different security postures:

High-security production servers:

Enable all security features
Use modules_disabled after boot
Mandatory Secure Boot and signing
Comprehensive audit logging

Development workstations:

Module signing optional
Frequent module reloading needed
Secure Boot may complicate development
Balance productivity with reasonable protection

Embedded/IoT devices:

Static module configuration at build time
No module loading at runtime
Verified boot from known-good image
Limited attack surface by design

Cloud/container environments:

Host kernel secured; containers can't load modules
Hypervisor provides additional isolation
Focus on host-level module security

The Future: eBPF

Summary: Securing Kernel Extensibility

Key Takeaways

•Kernel modules are the ultimate attack vector—ring 0 access means complete system control, stealth capability, and security software bypass.
•Rootkits leverage kernel access to hide processes, files, and network connections. Detection requires cross-view analysis or external observation.
•Module signing cryptographically authenticates modules, preventing unauthorized code from loading when enforcement is enabled.
•Secure Boot extends trust from firmware through kernel to modules, creating a verified chain of boot.
•Mandatory Access Controls (SELinux, AppArmor) provide additional layers restricting module operations by context.
•Operational practices matter—blacklisting, auditing, capability restriction, and integrity monitoring reduce risk.
•Defense in depth combines multiple barriers: root access, signing, Secure Boot, MAC, syscall filtering, and lockdown.
•Balance flexibility and security according to your environment—development and production have different needs.

Module security is not optional:

Module Complete

5 / 5