Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/deelerdev/linux/llms.txt

Use this file to discover all available pages before exploring further.

The Linux kernel offers multiple overlapping layers of security. Some of these — like the capability system and namespaces — have been present for decades. Others, like kernel lockdown mode and hardware tag-based KASAN, are relatively recent additions. Understanding how these layers interact helps you build a defence-in-depth posture that is appropriate for your workload.

​
Linux Security Modules (LSM)

The Linux Security Module framework provides a set of hooks at security-relevant points in the kernel. Pluggable security modules attach to those hooks and enforce their own policy. The framework requires CONFIG_SECURITY=y and is enabled by default in most distribution kernels. Multiple LSMs can be stacked simultaneously. The active modules are listed in /sys/kernel/security/lsm. 
cat /sys/kernel/security/lsm
# Example output: lockdown,capability,landlock,yama,selinux

​
SELinux

SELinux enforces mandatory access control based on labels attached to every process, file, and socket. It is the default LSM on Fedora, RHEL, and Android. 
# Check the current SELinux mode
getenforce                # Enforcing, Permissive, or Disabled

# Switch to permissive mode for debugging (no reboot required)
sudo setenforce 0

# View AVC denials in the audit log
ausearch -m avc -ts recent
To enable SELinux at boot, ensure your kernel has CONFIG_SECURITY_SELINUX=y and add security=selinux selinux=1 to your kernel command line if it is not the compile-time default.

​
AppArmor

AppArmor enforces per-program profiles that restrict what files, capabilities, and network operations a process can use. It is the default LSM on Ubuntu and Debian. 
# Check AppArmor status
sudo aa-status

# List all loaded profiles
sudo apparmor_status

# Set a profile to complain mode (log violations, do not enforce)
sudo aa-complain /etc/apparmor.d/usr.bin.firefox

​
TOMOYO

TOMOYO is a pathname-based MAC implementation. It uses a learning mode to build policy automatically by observing normal program behaviour. Enable it with CONFIG_SECURITY_TOMOYO=y.

​
Landlock

Landlock is an unprivileged sandboxing mechanism that lets processes restrict their own access to the filesystem using a set of rules. Unlike SELinux or AppArmor, it does not require system-wide policy or root privileges to activate.

​
seccomp and syscall filtering

seccomp (secure computing mode) allows a process to restrict the set of system calls it is allowed to make. It is widely used by container runtimes, browsers, and other sandboxed applications. 
/* Example: allow only read, write, exit, and sigreturn */
#include <linux/seccomp.h>
#include <linux/filter.h>
#include <sys/prctl.h>

prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
Most applications use the more flexible BPF filter mode (SECCOMP_MODE_FILTER), which lets you write fine-grained per-syscall policy. Tools like libseccomp provide a higher-level API for building these filters without writing BPF directly.
Container runtimes such as Docker and Podman ship a default seccomp profile that blocks roughly 50 dangerous syscalls. You can view and customise these profiles to tighten or relax restrictions.

​
Kernel self-protection

The kernel protects itself through a combination of compile-time hardening options and hardware-enforced restrictions. The Documentation/security/self-protection.rst file in the kernel source describes the full design.

​
KASLR

Kernel Address Space Layout Randomisation randomises the physical and virtual address at which the kernel is loaded. This defeats attacks that rely on hardcoded kernel addresses. 
# Enable at boot (on by default when CONFIG_RANDOMIZE_BASE=y)
# To disable temporarily for debugging:
nokaslr

​
Stack protection

CONFIG_STACKPROTECTOR inserts a canary value between local variables and the saved return address on every stack frame. If a stack buffer overflow overwrites the canary the kernel panics before the corrupted return address is used. CONFIG_STACKPROTECTOR_STRONG extends protection to all functions that have arrays, take the address of local variables, or call alloca().

​
Strict memory permissions

CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX enforce that:
  • Kernel code (.text) is executable but not writable.
  • Read-only data (.rodata) is neither writable nor executable.
  • Writable data (.data) is not executable.
This prevents an attacker who has gained arbitrary write access from redirecting execution into injected shellcode.

​
SMEP and SMAP (x86)

Supervisor Mode Execution Prevention (SMEP) prevents the kernel from executing code in userspace pages. Supervisor Mode Access Prevention (SMAP) prevents the kernel from accessing userspace pages except through explicit copy_to_user / copy_from_user calls. Both are enforced in hardware by the CPU and are enabled automatically when the CPU supports them. No kernel configuration option is required; the kernel detects and activates them at boot. 
# View all active CPU vulnerability mitigations
grep -r . /sys/devices/system/cpu/vulnerabilities/

# Example output:
# /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Enhanced / Automatic IBRS; IBPB: conditional; RSB filling; PBRSB-eIBRS: SW sequence; BHI: BHI_DIS_S
# /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
CONFIG_MODULE_SIG requires that kernel modules carry a cryptographic signature. CONFIG_MODULE_SIG_FORCE rejects unsigned modules entirely, preventing an attacker with root access from loading malicious kernel code.
# Sign a module manually
scripts/sign-file sha256 signing_key.pem signing_cert.pem my_module.ko

# Check whether a module is signed
modinfo my_module.ko | grep sig

​
Capability system

Linux divides the privileges traditionally associated with root into discrete capabilities. A process only needs the specific capability required for each operation, reducing the blast radius if it is compromised. Commonly used capabilities:
CapabilityGrants
CAP_SYS_ADMINA wide range of administrative operations; treat with caution
CAP_NET_ADMINConfigure network interfaces, routing, and firewall rules
CAP_SYS_PTRACEptrace() any process
CAP_SYS_MODULELoad and unload kernel modules
CAP_DAC_OVERRIDEBypass file permission checks
CAP_CHOWNChange file ownership
CAP_SETUID / CAP_SETGIDChange process user/group identity
CAP_NET_BIND_SERVICEBind to ports below 1024
# View capabilities of a running process
cat /proc/<pid>/status | grep Cap

# Decode the hex capability mask
capsh --decode=0000000000003000

# Drop all capabilities except those explicitly needed (example with capsh)
capsh --drop=cap_sys_admin --

​
Namespaces and isolation

Linux namespaces partition global kernel resources so that processes inside a namespace see only their own isolated view. They are the foundation of containers.
NamespaceIsolates
pidProcess ID number space
netNetwork interfaces, routing, firewall rules
mntFilesystem mount tree
utsHostname and NIS domain name
ipcSystem V IPC, POSIX message queues
userUser and group ID number spaces
cgroupcgroup root directory
timeBoot and monotonic clock offsets
# Run a command in a new set of namespaces
unshare --pid --net --mount --fork /bin/bash

# List the namespaces a process belongs to
ls -la /proc/<pid>/ns/
Unprivileged user namespaces (CONFIG_USER_NS=y) expand the attack surface because they allow non-root users to create isolated environments. Many distributions limit their use via sysctl kernel.unprivileged_userns_clone.

​
Kernel lockdown mode

Lockdown is an LSM that restricts what even the root user can do in order to protect kernel integrity. It has two levels:
  • integrity: Prevents modifications that would allow userspace to change kernel code (e.g., /dev/mem writes, unsigned modules, ACPI table overrides).
  • confidentiality: Additionally prevents reading kernel memory from userspace.
# Check the current lockdown level
cat /sys/kernel/security/lockdown

# Enable lockdown at boot via kernel parameter
lockdown=integrity
lockdown=confidentiality
On systems with UEFI Secure Boot, many distributions automatically set lockdown to integrity to ensure the signed kernel cannot be modified at runtime.

​
Reporting security vulnerabilities

The Linux kernel project handles security issues through a private disclosure process before going public.
1

Read the security policy

The full policy and list of security contacts is in Documentation/process/security-bugs.rst in the kernel source, and published at kernel.org/doc/html/latest/process/security-bugs.html.
2

Send an encrypted report

Email the security team at security@kernel.org. Use the PGP key published on the kernel.org security page to encrypt sensitive details. Do not post to public mailing lists until a fix is available.
3

Coordinate disclosure

Work with the security team to agree on a disclosure timeline. The team will notify downstream distributions so they can prepare patches before public announcement.

Build docs developers (and LLMs) love

Get started for freeTalk to us