diff --git a/docs/security/THREAT_MODEL.md b/docs/security/THREAT_MODEL.md index 8d15d13df1c24..d3f9adb9cd1f3 100644 --- a/docs/security/THREAT_MODEL.md +++ b/docs/security/THREAT_MODEL.md @@ -43,7 +43,7 @@ containerd treats Class 2 input as untrusted content, on par with registry image A security boundary bypass is a containerd vulnerability when attacker-influenced Class 2 content lets a tenant gain privilege, or obtain information, beyond what the Kubelet explicitly requested for that Pod, including a request for one Pod yielding state belonging to another. Misconfiguration or authorization bypass at the orchestrator (a tenant obtaining Kubelet-level write permission, or a Kubelet bug that escalates a Pod) remains Class 1 and outside containerd's responsibility. Public examples of Class 2 boundary failures include image-unpack path traversal (STORE-001), insecure image-config volume handling (CRI-002 / CVE-2022-23648), image-config values re-derived into a host sink (CRI-004), and checkpoint-metadata re-trust (CRI-005). -### 2.3. Security Scope and Expectations +### 2.3 Security Scope and Expectations containerd defines its security scope along the following six primary architectural boundaries: #### 1. gRPC API Socket Boundary @@ -72,12 +72,13 @@ containerd defines its security scope along the following six primary architectu * **In-Scope:** Ensuring containerd does not itself weaken the kernel-enforced isolation (namespaces, cgroups) between co-located workloads beyond what the CRI client requested. * **Out-of-Scope:** Enforcing lateral isolation when the orchestrator explicitly requests shared namespaces (e.g., shared network/IPC/PID inside a Kubernetes Pod). Lateral isolation otherwise depends on the host kernel, which is a TCB dependency (see boundary #4). -### 2.4. Security Exclusions (Non-Vulnerabilities) +### 2.4 Security Exclusions (Non-Vulnerabilities) containerd does not consider the following classes of issues to be vulnerabilities. Exploiting these is treated as a hardening opportunity rather than a bypass of containerd security boundaries: 1. **Secrets Leakage in Component Errors:** containerd does not control the contents of error messages generated by external or TCB components (e.g., remote registries, third-party NRI plugins). If an external component includes sensitive data (such as credentials or tokens) in its error returns, and containerd propagates this error string back to the orchestrator (Kubelet), this is not a containerd vulnerability. containerd makes a *best-effort* attempt to redact known-sensitive data in errors and logs it generates itself — for example masking userinfo and query-parameter values in registry URLs and dropping the `Authorization` header — but this coverage is **not comprehensive and offers no guarantees**: not every error path is sanitized. containerd does not attempt to filter the contents of errors that originate outside its own boundary. 2. **Orchestrator-Authorized Privileges:** containerd executes container specifications exactly as requested by its clients, including the CRI client (Kubelet). If a client configures a Pod with broad host access (e.g., `--privileged`, host volume mounts, or shared namespaces), any host-level compromise originating from that workload is an orchestrator security configuration issue, not a containerd vulnerability. 3. **Root/Socket Access Equivalence:** Access to the containerd Unix socket (`containerd.sock`), shim socket, or NRI socket is equivalent to root access on the host. Any exploit vector that requires direct write access to the socket or host-level root privileges to execute does not bypass a security boundary and is not classified as a vulnerability. +4. **Unreachable code and simulated or unit test flaws:** Flaws in internal functions that cannot be reached or executed in a running containerd daemon, and reports whose proof-of-concept is limited to isolated unit or integration tests against internal functions, or function simulations without demonstrating runtime security impact (see [TRIAGE_GUIDE.md](./TRIAGE_GUIDE.md#1-proof-of-concept-poc-requirements)). --- @@ -122,6 +123,9 @@ The Trusted Computing Base (TCB) includes all components that are critical to th ### 4.0 Severity and Likelihood Methodology The **Severity** and **Likelihood** ratings in this section are qualitative guidelines for weighing the threats below; they are **not** the authoritative rating of any individual report. For a reported vulnerability, containerd maintainers and security advisors set the final severity rating (Critical / High / Moderate / Low) and coordinate disclosure during triage; confirmed vulnerabilities are published in a [GitHub Security Advisory (GHSA)](https://github.com/containerd/containerd/security). See [TRIAGE_GUIDE.md](./TRIAGE_GUIDE.md) for how reports are triaged and rated. +Vulnerability reports must demonstrate a reachable code path in a running containerd daemon and demonstrate security impact. Reports relying on isolated unit or integration tests against internal functions or simulated function calls do not qualify as vulnerabilities. See [TRIAGE_GUIDE.md](./TRIAGE_GUIDE.md#1-proof-of-concept-poc-requirements) for proof-of-concept requirements. + + We evaluate security threats using a qualitative risk assessment framework based on **Severity** and **Likelihood**: #### Severity Levels diff --git a/docs/security/TRIAGE_GUIDE.md b/docs/security/TRIAGE_GUIDE.md index 4d0b77927813c..eaedacdc28910 100644 --- a/docs/security/TRIAGE_GUIDE.md +++ b/docs/security/TRIAGE_GUIDE.md @@ -3,13 +3,34 @@ This guide outlines how containerd maintainers and security advisors triage incoming security reports. > [!NOTE] -> To **report** a security vulnerability, use the [containerd Security Advisories portal](https://github.com/containerd/containerd/security). This guide describes how maintainers triage and evaluate reports *after* submission. +> To **report** a security vulnerability, use the [containerd Security Advisories portal](https://github.com/containerd/containerd/security). This guide describes how maintainers evaluate reports after submission. Reports must include a proof-of-concept (PoC) against a running containerd daemon demonstrating security impact (see [PoC requirements](#1-proof-of-concept-poc-requirements)). -## 1. Security Boundaries and Threat Model +## 1. Proof-of-concept (PoC) requirements + +To qualify as a vulnerability, incoming reports must include a reproducible proof-of-concept (PoC) that demonstrates security impact on a running containerd daemon. + +### 1.1. End-to-end execution against a running daemon +Reporters must demonstrate the vulnerability by executing an exploit against a live, running `containerd` daemon using standard operational paths, such as the CRI/Kubelet interface, `ctr`, or official client APIs. The PoC must exercise reachable code paths under realistic execution conditions. + +### 1.2. Incomplete PoCs and non-qualifying submissions +Submissions with incomplete PoCs do not satisfy the PoC requirement. Examples of non-qualifying submissions include: +* Unit or integration tests written against isolated internal functions in the containerd codebase. +* Standalone scripts or test harnesses that simulate or mock internal containerd functions in narrowly scoped tests. +* Flaws in internal functions where no reachable execution path exists from an operational client entry point in a running daemon. + +### 1.3. Demonstrable security impact +The PoC must demonstrate security impact (such as container escape, unauthorized host access, privilege escalation beyond the client specification, or daemon denial of service) consistent with containerd's threat model. Theoretical findings, static analysis reports, and code hygiene suggestions without demonstrated runtime security impact do not qualify as security vulnerabilities. + +### 1.4. LLM-assisted and automated reports +Reports generated with Large Language Models (LLMs) or automated static analysis tools must meet the same standards: +* LLM-assisted reports often generate false-positive function analysis, synthetic unit tests, or unreachable exploit claims. +* Submissions generated using LLMs or automated tools must include a manually verified end-to-end PoC against a running containerd daemon demonstrating security impact. + +## 2. Security Boundaries and Threat Model The primary security boundary for containerd is the **container isolation boundary**. A vulnerability is typically defined as a flaw that allows an attacker to bypass this boundary (e.g., container escape). -### 1.1. Root-Equivalence +### 2.1. Root-Equivalence containerd considers access to its primary APIs to be **equivalent to root access on the host**. This includes: @@ -17,52 +38,54 @@ containerd considers access to its primary APIs to be **equivalent to root acces **Triage Impact:** Reports that require access to these sockets to exploit are often classified as **bugs or hardening items** rather than vulnerabilities, unless they lead to an unexpected elevation of privilege beyond what an authorized client should be able to achieve. For example, if an authorized CRI client can write arbitrary files to the host filesystem, this is considered "by design" because a CRI client can already create privileged containers with full host access. -### 1.2. Trusted vs. Untrusted Input +### 2.2. Trusted vs. Untrusted Input containerd distinguishes between input from trusted sources (e.g., authorized API clients, trusted registries) and untrusted sources (e.g., malicious container images, untrusted users in a container). * **Image Unpacking:** Vulnerabilities in image unpacking (e.g., path traversal) are treated as high-priority vulnerabilities because containerd is expected to safely handle potentially malicious images from remote registries. * **Metadata:** Oversized metadata fields (labels, extensions) are treated as Denial of Service (DoS) vulnerabilities if they can lead to resource exhaustion of the daemon. -### 1.3. Triage Criteria for Architectural Boundaries +### 2.3. Triage Criteria for Architectural Boundaries When assessing incoming security reports, containerd maintainers follow the architectural boundaries defined in [THREAT_MODEL.md, Section 2.3 (Security Scope and Expectations)](./THREAT_MODEL.md#23-security-scope-and-expectations): * **Socket Access Reports:** Reports requiring direct, local access to `containerd.sock` are closed as **Non-Vulnerabilities** (unless they bypass the Kubelet CRI translation layer). * **Stack Escape Reports:** Escapes originating from flaws in `runc` or the Linux kernel are referred upstream and closed as **TCB dependencies**. * **Third-Party Plugin Reports:** Flaws in CNI or NRI plugins are referred to their respective plugin maintainers, as all plugins run inside the TCB. * **Error Leakage Reports:** Registry token or credential leaks inside error messages are triaged as **Hardening opportunities**, not vulnerabilities. -## 2. CVSS Scoring Stance +## 3. CVSS Scoring Stance containerd follows a specific philosophy when calculating CVSS scores to ensure consistency and accuracy. -### 2.1. Attack Vector (AV) and Privileges Required (PR) +### 3.1. Attack Vector (AV) and Privileges Required (PR) containerd CVSS scoring distinguishes between direct socket access and transitive orchestrator access: * **Direct Socket Access:** If an exploit needs direct, local access to the containerd socket (restricted to root or admin GIDs), the Base AV is **Local (L)** and Privileges Required is **High (H)**. * **Transitive Orchestrator Access:** If the exploit is triggered transitively by an unprivileged tenant through standard orchestrator APIs (e.g., a Kubernetes Pod Spec) or registry actions (e.g., image pulls), the Base AV is **Network (N)** and Privileges Required are typically **Low (L)** (reflecting the tenant's authorized orchestrator privileges). -### 2.2. Scope (S) +### 3.2. Scope (S) We carefully consider whether a vulnerability results in a **Scope Change (C)**. * A container escape that allows access to the host typically constitutes a Scope Change. * Violating orchestrator-enforced security constraints (e.g., bypassing Kubernetes `runAsNonRoot` or `readOnlyRootFilesystem` policies) or causing persistent orchestrator management failures (e.g., preventing Pod termination) constitutes a Scope Change. * Host-level Denial of Service or resource exhaustion does **not** change scope (S:U); this impact is captured strictly under **Availability: High (A:H)**. -### 2.3. User Interaction (UI) +### 3.3. User Interaction (UI) * **None (UI:N):** If the attacker possesses standard orchestrator credentials to trigger the vulnerable action directly (e.g., deploying their own Pod). * **Required (UI:R):** If the attack relies on inducing an administrator or other user to pull a compromised image, run a payload, or configure optional features. -## 3. Triage Process +## 4. Triage Process -1. **Reproduce:** Empirically reproduce the reported issue. +1. **Reproduce:** Empirically reproduce the reported issue using the provided end-to-end PoC against a running daemon. 2. **Assess Boundary:** Determine if a documented security boundary was crossed. 3. **Check TCB:** Identify if the flaw is in containerd itself or a TCB component (e.g., runc, Linux kernel). 4. **Assign Severity:** Use the component-first CVSS stance to determine the Base Score. 5. **Coordinate:** If a vulnerability is confirmed, follow the security policy for coordinated disclosure, including opening a GHSA and notifying relevant stakeholders (e.g., Kubernetes SRC). -## 4. Common Non-Vulnerabilities +## 5. Common Non-Vulnerabilities -* **Attacks requiring root/socket access:** As noted in 1.1, these are generally not considered vulnerabilities. +* **Attacks requiring root/socket access:** As noted in 2.1, these are generally not considered vulnerabilities. * **Issues in `--net=host` mode:** Sharing host namespaces is inherently insecure. While we implement hardening (e.g., moving to path-based Unix sockets for shims), we do not guarantee isolation when namespaces are shared. * **Vulnerable Dependencies:** Vulnerabilities in dependencies are only considered containerd vulnerabilities if they are **exploitable** through containerd's usage of that dependency. +* **Unit or integration test repros and simulated code execution:** Reports where the proof-of-concept is limited to unit tests, integration tests, or function simulations rather than an end-to-end exploit against a running daemon (see Section 1). +* **Unreachable internal function flaws:** Flaws in internal functions that cannot be reached or triggered through operational daemon APIs or client interfaces.