Linux Security Modules (LSM)

LSM implements security by inserting hooks at critical points in the kernel where a user-space object (file, task, socket) is about to be accessed. Before the kernel proceeds with the operation, it calls the LSM framework, which passes the request to the loaded security module (e.g., SELinux, AppArmor) for a policy decision.

• Example Hooks: file_open, inode_permission, task_kill, socket_bind.
• The module evaluates the request against its internal policy and returns an allow or deny decision.
• This design centralizes security logic without scattering checks throughout the kernel source code.

Historically, only one LSM could be active at boot time. Modern kernels support LSM stacking, allowing multiple security modules to be loaded simultaneously. Hooks are processed in a defined order, with each module getting a chance to make a decision.

• Key Use Case: Combining a comprehensive MAC system like SELinux with a simpler, path-based module like AppArmor for specific applications.
• The final decision is a logical AND; all modules must allow the action for it to proceed.
• This enables defense-in-depth by layering distinct security models.

LSM modules often need to store security state (labels, contexts) associated with kernel objects like tasks, inodes, and files. The framework provides opaque security blobs—pointers to module-specific data structures—attached to these kernel objects.

• The kernel allocates and manages the pointer storage, but the module manages the actual data.
• Example: SELinux stores a security context (e.g., user_u:role_r:type_t) in the inode's security blob.
• This mechanism isolates module data, preventing interference between stacked modules.

LSM hooks integrate with and extend the traditional Linux Capabilities model. While capabilities are a form of discretionary access control (DAC) granting privileges to processes, LSM modules can make finer-grained decisions.

• A hook can override a capability check. For instance, a process might have the CAP_NET_BIND_SERVICE capability, but SELinux policy could still deny a specific socket_bind operation.
• This allows policies to enforce rules that are more specific than broad privilege flags.

Beyond files and processes, LSM provides hooks for regulating network operations. This allows security modules to implement policies for sockets, packets, and network interfaces.

• Socket Hooks: Control creation (socket_create), binding (socket_bind), and connecting (socket_connect) based on security context.
• Packet Hooks: Authorize transmission/reception of individual packets (socket_sendmsg, socket_recvmsg).
• Netfilter Integration: Modules like SELinux can label packets via secmark for consistent policy enforcement across the network stack.

A core function of LSM modules is to assign and manage security labels on all system objects. These persistent labels are the basis for access decisions.

• Filesystem Labeling: Labels are stored in extended attributes (e.g., security.selinux) on supported filesystems.
• Dynamic Translation: Modules provide rules to assign initial labels to new objects (e.g., a process inherits its parent's label, a new file gets its creating process's label).
• Tools: Userspace utilities (e.g., chcon, aa-status) allow administrators to query and modify these labels according to policy.

Mandatory Access Control (MAC) is a security policy where access decisions are made by a central authority based on system-wide rules, not user discretion. It is the primary security model implemented by LSMs.

• Contrasts with DAC: Unlike Discretionary Access Control (DAC), where owners control permissions, MAC policies are enforced uniformly.
• LSM's Role: The LSM framework provides the hooks in the kernel (e.g., for file operations, task creation) that MAC implementations like SELinux use to enforce their policies.
• Example Policy: A MAC rule might state "the web server process (subject) cannot write to the database configuration file (object)," regardless of file ownership.

SELinux is a prominent, label-based LSM implementation developed by the NSA. It enforces MAC using security contexts attached to all subjects (processes) and objects (files, ports).

• Core Mechanism: Every process and system resource has a security context (e.g., user:role:type:level). Access is allowed only if explicitly granted by a policy rule.
• Policy Types: Primarily uses a Type Enforcement (TE) model, where rules define allowed interactions between types (e.g., httpd_t can read httpd_log_t).
• Modes: Operates in Enforcing (blocks violations), Permissive (logs only), or Disabled states. It is the default LSM on Red Hat Enterprise Linux, Fedora, and Android.

AppArmor is a pathname-based LSM that confines individual applications to a defined set of resources. It uses human-readable profiles instead of system-wide labels.

• Path-Based Security: Rules specify filesystem paths (e.g., /etc/nginx/** r, /var/log/nginx/* w) the application can access.
• Ease of Use: Profiles are simpler to write and audit than SELinux policies, making it popular for application containment.
• Deployment: Default LSM on Ubuntu, SUSE Linux Enterprise, and many other distributions. It is often used to sandbox network-facing daemons like Nginx or MySQL.

Seccomp is a Linux kernel feature that restricts the system calls a process can make, providing a strict sandbox. It is often used in conjunction with LSMs for defense-in-depth.

• Operation Modes: Seccomp-bpf allows filtering of system calls using Berkeley Packet Filter (BPF) rules to allow, log, or kill based on call arguments.
• Narrowing Attack Surface: While an LSM controls access to resources, seccomp controls which kernel interfaces (syscalls) are available at all.
• Common Use: Heavily utilized by container runtimes (like Docker and Kubernetes) to limit the kernel API available to containerized workloads.

Linux Capabilities split the omnipotent power of the root user into distinct units, allowing processes to be granted specific privileges without full superuser access. LSMs can further restrict capability use.

• Granular Privileges: Examples include CAP_NET_BIND_SERVICE (bind to ports < 1024) and CAP_SYS_ADMIN (broad admin rights).
• Interaction with LSM: An LSM can veto the effective use of a capability. A process might have CAP_DAC_OVERRIDE but an SELinux policy could still deny a file write.
• Hardening Practice: Dropping unnecessary capabilities is a fundamental container and daemon hardening step, reducing the impact of a compromise.

Linux Namespaces are a kernel feature that isolates and virtualizes system resources for a collection of processes, providing a form of lightweight virtualization. They are the foundational isolation mechanism for containers.

• Types of Isolation: Key namespaces include PID (process IDs), Network (interfaces, routing), Mount (filesystem hierarchy), and User (UID/GID mapping).
• Synergy with LSM: Namespaces provide isolation boundaries, while an LSM like AppArmor enforces access control within those boundaries. For example, a container can have its own network namespace and be confined by an AppArmor profile.
• Container Foundation: Tools like Docker and LXC combine namespaces, cgroups, and LSMs to create secure, isolated runtime environments.