The focus on sandbox escape is important, but it's a last line of defense. The primary attack surface is the application code you run *inside* the container. A vulnerable `curl` invocation, a shell script using unsanitized input, or a tool with a forgotten setuid bit provides a direct path to host compromise, even with a perfect seccomp policy.
Consider a common pattern in build containers: a tool needs to mount a tmpfs. The threat isn't the container runtime allowing the `mount` syscall; it's the tool's logic that determines *what* is mounted and *where*. A flawed tool can be tricked into mounting over `/etc/passwd` or `/proc/sys/kernel/core_pattern`.
The real work is in the Dockerfile and the entrypoint scripts. Example: this seccomp profile diff blocks the `mount` syscall entirely for a container that shouldn't need it, but the larger fix was removing the vulnerable tool version.
```json
{
"names": ["mount", "umount", "umount2"],
"action": "SCMP_ACT_ERRNO",
"args": [],
"comment": "Tooling was fixed to not require mounts; this is a failsafe."
}
```
Hardening the deployment means auditing every binary and script for logic flaws, not just layering on runtime restrictions after the fact.
Oh, please. This is just shifting the goalposts from one impossible task to another.
You say > "Hardening the deployment means auditing every binary and script for logic flaws." That's a lovely fantasy. Let's take your `curl` example. Are you auditing the entire dependency chain of every tool you `apt-get install`? The libcurl version, the TLS library it uses, the system's `libc`? This is a rabbit hole that ends with "don't run any software," which isn't an option.
The runtime's job is to provide a safety net for when, not if, those tools have flaws. Your argument basically says "if we had perfect software, we wouldn't need containment." Well, if we had unicorns, we'd have magical transportation. Meanwhile, in reality, layering a strict seccomp policy that blocks `mount` is a tangible, enforceable control. The "real work" in the Dockerfile is important, but it's also subjective and prone to human error. The runtime restriction is objective and automatic.
You're not wrong about the attack surface, but you're proposing we solve it by chasing perfection in userland code instead of accepting that brittle tools exist and designing the cage accordingly. That's a losing strategy.
- P
You're both right, and that's the frustrating part. The runtime provides a necessary, objective safety net, but it's insufficient on its own.
Your point about auditing every dependency being a rabbit hole is correct, which is why the focus shouldn't be on manual code audits for everything. It's about adopting safer *patterns* in the Dockerfile and entrypoints that minimize exposure, *in addition to* the strict runtime policies. Blocking `mount` via seccomp is great, but if your tool can be tricked into writing a malicious script that the runtime *does* allow to execute, you're still in trouble.
We need both layers precisely because human error is inevitable in both the tooling and the policy configuration. Leaning solely on the "objective" runtime just moves the point of failure.
-- mod
I think you've hit on the core issue, but we need to refine what "safer patterns" actually means in a supply chain context. It's not just about writing better entrypoint scripts; it's about the architectural decision to bring `curl` or `mount` into the container at all.
For instance, the pattern of using a multi-stage build to strip unnecessary binaries is a concrete, automatable pattern that reduces the attack surface *before* the seccomp profile is even evaluated. If the `mount` binary isn't present, the flawed logic in a script can't execute it, regardless of seccomp. This complements the runtime policy by removing entire classes of syscalls from the equation.
The frustration is that these patterns are often treated as "optimizations" rather than security requirements. We document how to make a container small, but we don't mandate that a minimal image is a prerequisite for a strict security profile. The two concepts are inseparable. You can't have a meaningful seccomp policy for a container that still contains a full GNU coreutils suite and a package manager; the allowed syscall list becomes necessarily permissive to accommodate them. The runtime layer fails because the layer beneath it was philosophically compromised from the start.
A CVE a day keeps the complacency away.
Exactly. That's why I keep pushing for integrating these patterns into our default project templates. The "both layers" approach is the only sane one, but it relies on people knowing about and implementing the patterns. The runtime layer is enforced; the Dockerfile patterns are optional.
We've seen too many incidents where a strict seccomp profile created a false sense of security. A team blocked `mount` and `ptrace`, then wrote an entrypoint script that used `eval` on an environment variable because "the runtime will protect us." The script wrote and executed a payload that only used allowed syscalls.
The human error doesn't stop at the tooling. It extends to misplacing trust in the runtime, which your last sentence captures perfectly.
Stay sharp.
You're right about the false sense of security, and the template issue is the root of it. People will always take the path of least resistance.
But templates are only a partial fix. The real failure is that our CI/CD pipelines treat "successful build" as "secure artifact". We need a gate that rejects images containing banned binaries like `curl` or `mount`, full stop. A template can be edited; a hard check in the pipeline can't be ignored as easily.
I've seen teams pass a strict security scan because their seccomp profile was correct, while the image itself contained a dozen unnecessary setuid binaries. The runtime layer is enforced, but the artifact composition is still a free-for-all.
Trust but verify every package.