The Linux kernel provides two powerful mechanisms for restricting what containerized applications can do: seccomp filters that restrict system call access, and AppArmor profiles that restrict file, capability, and network access. Both are effective. Both are underused in production environments.
The reason for underuse is the same: creating correct application-specific profiles requires detailed knowledge of what the application actually does at the kernel level. Most security teams do not have this knowledge readily available.
Runtime profiling — the same technique used for container image hardening — provides exactly this knowledge. The data that tells you which packages to remove also tells you which system calls are made. This is the connection that makes these three controls synergistic rather than separate.
What Seccomp Does (And What It Doesn’t)?
A seccomp profile is a filter applied to the system calls a process can make. Linux has several hundred system calls; most containerized applications use a small fraction of them.
Kubernetes provides a default seccomp profile that blocks a set of dangerous system calls: ptrace, keyctl, personality, and others that have limited legitimate use and high exploitation potential. This profile is a starting point.
The default profile’s limitation: it is conservative. It permits a broad set of system calls that most applications need. Application-specific seccomp profiles that allow only the system calls the specific application makes provide significantly stronger restriction.
Consider the implications: CVE-2022-0185 exploited the fsconfig system call. An application-specific seccomp profile that does not include fsconfig would have blocked this exploit regardless of whether the container’s Linux kernel was patched. This is the security value of a tight seccomp profile: it creates a second line of defense against kernel vulnerability exploitation.
What AppArmor Does (And What It Doesn’t)?
AppArmor profiles define what files a process can access, what capabilities it can exercise, and what network operations it can perform. A well-crafted AppArmor profile for a web application might:
- Allow reads from /app and /etc/ssl
- Allow writes to /tmp and /var/log/app
- Allow network connections on specific ports
- Deny everything else
Like seccomp, the challenge is creating these profiles correctly. An overly permissive profile provides false confidence. An overly restrictive profile breaks the application.
How Runtime Profiling Data Informs Both?
The execution data captured during container runtime profiling for image hardening purposes contains more information than just which packages were used. It includes:
System call patterns: Which syscalls does the application actually make? read, write, open, socket, connect, accept, epoll_wait — the actual syscall trace is captured.
File access patterns: Which files and directories does the process actually read and write?
Network operations: Which ports does the application bind to? Which IP addresses does it connect to?
This data is the precise input needed to generate application-specific seccomp and AppArmor profiles.
Instead of starting from scratch with a permissive profile and iterating based on access failures, you start from runtime observation and generate a profile that matches actual application behavior.
The Combined Hardening Model
Container hardening that integrates image component minimization with seccomp and AppArmor profile generation operates at three distinct restriction layers:
Layer 1 – Package removal: Components not executed during runtime profiling are removed from the image. This eliminates attack surface that exists in the image regardless of runtime policy.
Layer 2 – Seccomp restriction: System calls not observed during runtime profiling are blocked. This prevents kernel exploitation via syscalls the application never legitimately uses.
Layer 3 – AppArmor confinement: File access, capabilities, and network operations are restricted to those observed during runtime profiling. This limits what an attacker can access even within the container process context.
Each layer addresses a different threat vector:
- Package removal limits what tools are available
- Seccomp limits what kernel operations are possible
- AppArmor limits what resources are accessible
An attacker who compromises a container protected by all three layers faces severe constraints: no extra tools, a narrow set of permitted syscalls, and restricted access to files and network resources.
Practical Implementation
Start with the runtime profile: The profiling step produces the data that informs all three controls. Run it once, thoroughly, and extract all three data types.
Apply package removal first: Image hardening is the simplest layer to implement and produces immediate CVE reduction. Validate the hardened image with functional tests before adding runtime restrictions.
Generate the seccomp profile: From the syscall data in the runtime profile, generate a seccomp profile that allows observed syscalls and denies the rest. Test with the application; most applications have predictable syscall patterns that generate stable profiles.
Generate the AppArmor profile: From the file access and network data in the runtime profile, generate an AppArmor profile. AppArmor profiles require slightly more iteration than seccomp profiles because file access patterns can vary with application state.
Apply in audit mode first: Both seccomp and AppArmor support audit modes that log violations without blocking. Run in audit mode for a period in staging to capture any cases where the profile is too restrictive, then switch to enforce mode.
Frequently Asked Questions
What is the difference between seccomp and AppArmor for container security?
Seccomp (Secure Computing Mode) filters which Linux system calls a container process can make — if an application never calls fsconfig or ptrace, a seccomp profile can deny those syscalls entirely, blocking kernel exploits that require them regardless of patching status. AppArmor operates at a higher level, restricting which files a process can access, which capabilities it can exercise, and which network operations it can perform. In a layered container security model, seccomp limits what kernel operations are possible while AppArmor limits what resources are accessible — together they constrain the attacker’s operating environment from different angles.
How does runtime profiling help generate seccomp and AppArmor profiles?
The execution data captured during container runtime profiling contains the syscall patterns, file access patterns, and network operations the application actually performs. This data is the precise input needed to generate correct application-specific seccomp and AppArmor profiles — rather than starting from a permissive default and iterating based on violations, you start from observed behavior and generate a profile that matches it. The same profiling step that produces the package removal list for image hardening also produces the data needed for kernel-level policy enforcement, making the three controls synergistic.
What does the combined seccomp, AppArmor, and image hardening model protect against?
The combined model addresses three distinct attack surfaces: image hardening removes tools an attacker needs for post-exploitation (no shell, no networking utilities), seccomp blocks kernel operations the application never legitimately uses (preventing kernel vulnerability exploitation via restricted syscalls), and AppArmor restricts file access and network resources to those the application actually needs. An attacker who compromises a container protected by all three layers has no extra tools available, a narrow set of permitted syscalls, and restricted access to files and network — each layer addresses what the others miss.
Should seccomp and AppArmor profiles be applied in audit mode first?
Yes — both seccomp and AppArmor support audit modes that log violations without blocking. Running in audit mode in staging for a period after generating the profile from runtime data catches cases where the profile is too restrictive, typically because application behavior under certain conditions was not captured during profiling. After validating that no legitimate application actions are being denied, switch to enforce mode for production. Image hardening and functional testing should be applied before adding seccomp and AppArmor profiles, since a validated hardened image provides a stable baseline for kernel-level policy testing.
What This Combination Achieves?
Container security software that combines image hardening with kernel-level policy enforcement creates a container environment where:
- The available attack tools are minimal (image hardening)
- The available kernel interfaces are minimal (seccomp)
- The accessible resources are minimal (AppArmor)
This is not theoretical defense-in-depth. Each layer has independently prevented real attacks. CVE exploits that require specific syscalls are blocked by seccomp regardless of patching status. Data exfiltration that requires filesystem access is blocked by AppArmor regardless of what the container code does. Tools required for post-exploitation are absent from the image.
The investment in setting up all three layers pays compound security dividends because each layer addresses what the others miss.