Seccomp

The original and most restrictive mode, introduced in Linux 2.6.12. In this mode, the process is only permitted to make four essential system calls: read, write, _exit, and sigreturn. Any attempt to call another system call results in the termination of the process via a SIGKILL signal.

• Purpose: Provides a simple, absolute sandbox for highly trusted code that requires minimal kernel interaction.
• Limitation: Its inflexibility makes it unsuitable for most real-world applications, which led to the development of the filter mode.

The modern, programmable mode introduced via the seccomp() syscall with the SECCOMP_SET_MODE_FILTER flag and the prctl() syscall with PR_SET_SECCOMP. It allows the definition of custom filter programs using Berkeley Packet Filter (BPF) rules to allow, log, or kill specific system calls.

• BPF Programs: Filters are small programs that inspect each system call number and arguments, returning an action (e.g., ALLOW, ERRNO, KILL, TRAP, LOG).
• Flexibility: Enables fine-grained policies, such as allowing open() but only for specific file paths or with certain flags.

A BPF filter returns a 32-bit value that dictates the kernel's action for the intercepted system call. The high 16 bits specify the action, and the low 16 bits are action-specific data.

• SECCOMP_RET_ALLOW: The system call executes normally.
• SECCOMP_RET_ERRNO: Blocks the call; the low 16 bits are returned as the errno value to the process.
• SECCOMP_RET_KILL: Terminates the process immediately with a SIGSYS signal.
• SECCOMP_RET_TRAP: Sends a SIGSYS signal to the process, allowing it to catch and handle the violation.
• SECCOMP_RET_LOG: Allows the call but logs it for auditing. Used when monitoring is more important than blocking.
• SECCOMP_RET_TRACE: Delegates the decision to a ptrace tracer, if present.

Seccomp Filter mode leverages a restricted, in-kernel virtual machine originally designed for network packet filtering: the Berkeley Packet Filter (BPF). A seccomp-BPF program is loaded into the kernel, where it safely evaluates each system call.

• Safety: BPF programs are guaranteed to terminate and cannot perform loops or access arbitrary kernel memory.
• Inspection Capabilities: The program can examine the system call number, architecture identifier, and up to six 64-bit arguments. This allows for argument-based filtering (e.g., checking the prot argument of mmap).
• Program Structure: Typically written using helper macros from <linux/seccomp.h> and <linux/filter.h> or via libraries like libseccomp.

Introduced in Linux 5.0, the SECCOMP_RET_USER_NOTIF action enables a supervisor process to handle system call violations on behalf of a sandboxed process (the target).

• Mechanism: When a filtered syscall is encountered, the kernel notifies a userspace supervisor via a file descriptor. The supervisor can inspect the call, modify its arguments or return value, and instruct the kernel to proceed or fail it.
• Use Case: Enables complex security policies that require runtime context unavailable to the static BPF filter, such as dynamic pathname resolution or user-based access decisions.
• Tooling: Used by sandboxes like Landlock and systemd-service managers to implement advanced confinement policies.

Sandboxing is a general security mechanism for isolating running programs by restricting their access to system resources like the filesystem, network, and other processes. Seccomp is a specific Linux kernel implementation of sandboxing focused on the system call interface. Other sandboxing techniques include:

• Namespaces: Isolate global system resources (e.g., PID, network, mount) for a process.
• Capabilities: Split root privileges into distinct units to limit process power.
• Chroot: Change the apparent root directory for a process, restricting filesystem access. Seccomp provides a stricter, more granular layer of control than these methods by operating at the kernel boundary.

Linux Security Modules (LSM) is a framework in the Linux kernel that allows for the implementation of mandatory access control (MAC) security models. While Seccomp filters system calls, LSMs like SELinux and AppArmor enforce policies on how objects (files, sockets, processes) can be accessed by subjects. They operate at a higher level:

• SELinux: Uses labels and complex policies defined by system administrators.
• AppArmor: Uses path-based profiles that are often easier to configure. Seccomp and LSMs are complementary; Seccomp restricts the kernel's entry points (syscalls), while LSMs govern the kernel's internal operations once a syscall is allowed.

The Principle of Least Privilege is a foundational computer security concept stating that every user, process, or program should be granted the minimum levels of access—or permissions—necessary to perform its intended function. Seccomp is a direct technical enforcement of this principle at the kernel interface. By defining a strict allowlist of permitted system calls, developers can ensure an AI agent or any process cannot perform privileged operations outside its narrow task, such as arbitrarily spawning processes (fork, execve) or modifying kernel modules. This drastically reduces the attack surface.

Extended Berkeley Packet Filter (eBPF) is a technology in the Linux kernel that allows sandboxed programs to run in a privileged kernel context. While both eBPF and Seccomp are used for security and observability, they serve different purposes:

• Seccomp: Restricts which syscalls a process can make.
• eBPF: Allows safe, dynamic extension of kernel functionality for networking, tracing, and security monitoring. Notably, eBPF programs can be used to implement sophisticated Seccomp-BPF filters, where the filtering logic is defined using a BPF program, offering more dynamic control than a simple static allowlist.

The WebAssembly System Interface (WASI) is a modular, capability-based system interface for WebAssembly (Wasm) runtimes. It provides a sandboxed set of APIs for securely accessing operating system features like files and networks. WASI and Seccomp share the goal of isolation:

• WASI: Defines a portable, high-level API for Wasm modules. The host runtime (e.g., Wasmtime) is responsible for safely implementing these APIs, often using Seccomp and other OS features underneath.
• Seccomp: A lower-level Linux kernel feature that enforces isolation by filtering the raw syscalls a process can make. In an AI agent context, tool execution could be compiled to Wasm and run in a WASI runtime, which itself may use Seccomp for an additional layer of kernel-level containment.

A Trusted Execution Environment (TEE) is a secure area of a main processor that guarantees code and data loaded inside are protected with respect to confidentiality and integrity. Technologies include Intel SGX, AMD SEV, and ARM TrustZone. TEEs and Seccomp operate at different layers:

• TEE (Hardware): Provides cryptographic isolation and memory encryption, protecting against a compromised host OS or hypervisor.
• Seccomp (OS Kernel): Protects the host kernel from a malicious or compromised user-space process. For maximum security in AI agent tool execution, a sensitive function could run inside a hardware TEE, and the TEE's runtime itself could employ Seccomp to further restrict its own syscall surface.