↓ Skip to main content
Le Site de François
  1. Index/

AppArmor (Application Armor)

Linux Kernel Security Mac Lsm Ubuntu Containers

AppArmor (Application Armor) is a Mandatory Access Control (MAC) system implemented as a major LSM (Linux Security Module), developed originally by Immunix and now maintained by Canonical. It is the default MAC system on Ubuntu, Debian, and their derivatives, and the default container confinement mechanism for containerd and Docker on those distributions. Where SELinux assigns security labels to every object on the system and enforces policy based on label interactions, AppArmor takes a fundamentally different approach: it confines programs by filesystem path. A profile for nginx lists the specific file paths that nginx is allowed to read, write, and execute, the network operations it may perform, and the Linux capabilities it may use — anything not listed is denied. No relabelling of the filesystem is required and no extended attributes are set: AppArmor’s confinement decisions are made purely from the path of the file being accessed and the identity of the confined process. This path-based model makes AppArmor profiles far simpler to read, write, and audit than SELinux policy, and eliminates the mislabelled-file failure mode that is the most common SELinux operational problem.

An AppArmor profile is a text file, typically stored in /etc/apparmor.d/, that specifies confinement rules for a single program identified by its executable path. Profile syntax covers: file rules (path patterns, optionally using globbing, with a permission set — r read, w write, x execute, m memory-map, k lock, l link — for example /var/log/nginx/** rw); capability rules (which Linux capabilities the process may use, e.g. capability net_bind_service); network rules (address families and socket types permitted, e.g. network inet tcp); signal rules (which signals the confined process may send and to which domains); and mount rules (which filesystem mounts are permitted). Profile transitions allow a confined process to execute a child process in a different profile, or to transition to a sub-profile for fine-grained control over helper programs. Profiles operate in one of two modes: enforce (violations are blocked and logged to the kernel audit subsystem, visible via dmesg and journalctl) and complain (violations are logged but not blocked, used to profile new applications and tune profiles before enforcement). AppArmor profiles are loaded into the kernel via apparmor_parser and the status of all loaded profiles is visible via aa-status.

In Kubernetes and container environments, AppArmor profiles must be pre-loaded on each node — they are not distributed with the workload manifest — and are referenced in a pod spec via securityContext.appArmorProfile (Kubernetes 1.30+, previously via annotation). Container runtimes ship a built-in docker-default / cri-containerd.apparmor.d profile that blocks the most dangerous operations (writes to /proc/sys, mount, ptrace of processes outside the container, several dangerous capabilities) while permitting everything a typical containerised application needs; this profile is applied automatically unless overridden. Custom profiles on Kubernetes nodes are typically deployed via a DaemonSet or the Security Profiles Operator. The fundamental limitation of AppArmor’s path-based model is bind mounts and overlayfs: a file accessed via a different path than the profile expects — common with container volume mounts and overlay filesystem upper layers — may not match the profile’s path rules and will either be incorrectly allowed or denied. SELinux does not have this problem because its labels are stored on the inode, not derived from the path. In practice, this means AppArmor profiles for containers require careful attention to the paths the container runtime constructs inside the overlay filesystem (/run/containerd/..., overlay upper dirs) to avoid both over-permission and spurious denials. BPF LSM can be stacked alongside AppArmor on the same system to add programmatic per-workload policy on top of AppArmor’s profile-based confinement without replacing it.

Related

SELinux (Security-Enhanced Linux)

Linux Kernel Security Mac Lsm Rhel Containers
SELinux (Security-Enhanced Linux) is a Mandatory Access Control (MAC) implementation developed by the NSA and released as open source in 2000, merged into the mainline Linux kernel in 2.6 via the LSM framework in 2003. Its defining characteristic is default deny: unlike the standard Linux Discretionary Access Control model (file permission bits), where anything not explicitly forbidden is permitted, SELinux refuses all access that is not explicitly allowed by policy. Every process and every object — every file, socket, pipe, device node, and IPC object — carries a security context (also called a label) of the form user:role:type:level. The policy is a compiled set of rules, loaded at boot, that defines precisely which combinations of process context and object context may interact and how. An Apache web server process running in the httpd_t domain can read files labelled httpd_sys_content_t but is denied access to files labelled user_home_t or shadow_t, regardless of what Unix file permission bits say. If the web server is compromised, the attacker is confined to what httpd_t permits — typically a narrow, well-defined set of files and network operations — rather than having the full access of the user account running Apache.

LSM (Linux Security Module)

Linux Kernel Security Mac Selinux Apparmor
Linux Security Modules (LSM) is a hook-based framework integrated into the Linux kernel since 2.6 (2003) that provides a general mechanism for implementing Mandatory Access Control (MAC) without modifying the core kernel. Its origin is the NSA’s presentation of SELinux at the 2001 Linux Kernel Summit: Linus Torvalds accepted the need for flexible access control but refused to hardcode a single security model, directing instead the development of a framework into which any security model could be plugged. The result is LSM: a set of strategically placed hook functions throughout the kernel’s execution paths — over 240 hooks in recent kernels — at points where security-relevant decisions occur: file open, process creation, capability checks, socket operations, IPC access, memory mapping, and more. Each hook is a call into the currently active security module(s), which examine the operation’s context and return allow or deny. The core kernel enforces whatever the security module decides.

Syscall (System Call)

Linux Kernel Security Os Seccomp Containers
A system call (syscall) is the formal interface through which a user-space process asks the kernel to perform a privileged operation on its behalf — opening a file, allocating memory, creating a process, establishing a network connection, sending a signal, or any other action that requires kernel mediation. User-space code runs at CPU privilege level 3 (ring 3) and cannot directly access hardware, manipulate kernel data structures, or perform I/O; the kernel runs at ring 0 with unrestricted access. A syscall is the crossing point: the process places its request in a defined register convention and issues a syscall instruction (on x86-64) that atomically switches the CPU to ring 0 and transfers control to the kernel’s syscall dispatch table. The kernel validates the request, performs the operation if permitted by standard Unix permissions and any active LSM hooks, and returns the result. From a security perspective, the syscall boundary is the complete list of what a process can ask the kernel to do — and therefore the complete list of operations that security controls like seccomp and BPF LSM can police.