Course contentsShow
← Linux
Lesson 1556 of 1,81913. Containerization Primitives and NamespacesFree lesson

Linux Security Modules (LSM) Framework

Understand how security modules sit between kernel objects and user-space requests.

In this lesson, you will learn how the Linux Security Modules (LSM) framework acts as a mandatory gatekeeper that sits between user-space requests and the internal kernel objects they seek to access.

The Interceptor Pattern

By this stage in your journey, you have explored deep observability through eBPF and tracing, and you’ve managed resource boundaries via namespaces and cgroups. LSM takes this a step further. While standard Linux permissions (like UGO/rwx) are discretionary and managed by the object owner, LSM provides a Mandatory Access Control (MAC) layer.

The LSM framework is implemented as a set of "hooks" placed strategically throughout the kernel’s core code—right at the point where a system call is about to perform an operation on a kernel object (such as a file, socket, or process). When a user-space process requests an action, the kernel executes these hooks before the operation proceeds.

Hooking into the Kernel

Think of these hooks as security checkpoints. If you have a module like SELinux or AppArmor loaded, the kernel will execute the corresponding LSM callback. If the policy defined in the module returns an error (like -EACCES), the kernel aborts the action immediately, regardless of what the file permissions might say.

For example, consider the inode_permission hook:

/* Pseudocode illustration of an LSM hook location */
int inode_permission(struct inode *inode, int mask) {
    /* 1. Standard filesystem permission checks (DAC) happen here */
    
    /* 2. LSM hook check */
    return security_inode_permission(inode, mask);
}

When security_inode_permission is invoked, the kernel consults the registered LSM. If the security policy forbids the process from touching that specific inode, the kernel prevents the access. This happens regardless of whether the user is root or a regular user within a container namespace.

Because these modules are integrated directly into the kernel’s control flow, they provide a robust mechanism for enforcing fine-grained security policies on containerized workloads, ensuring that even if a process is running as root inside a namespace, it remains bound by the security restrictions imposed by the host's LSM policy.

Key Takeaway: The LSM framework inserts security checkpoints into the kernel's critical code paths, allowing mandatory security policies to override standard permissions before an action on a kernel object is completed.