The shell layer and the What it is not section disagree.
Proposed approach:
Shell layer: Command and argument inspection. Features a built-in denylist for known exfiltration patterns and an allowlist mode for tighter constraints.
What it is not:
Not a detection engine (we enforce least-privilege, we don't scan-and-score).
A denylist of known exfiltration patterns is a detection engine. It is the same thing the document criticises Clampd for, at smaller scale. The Problem section makes the criticism explicitly:
Detection-first tools: Optimize for blocking known bad patterns (like an antivirus) rather than enforcing least-privilege.
Beyond the inconsistency, command pattern matching does not hold up. If the denylist catches curl --data-binary @file, then base64 file | curl -d @-, python3 -c "...", sh ./deploy.sh, curl "$URL" -d "@$F", a renamed binary, or anything reading the file in one command and sending it in the next all walk past it. Shell is a language with unbounded ways to express the same effect, so an argument denylist is a speed bump, and its main cost is that it reads as protection.
The allowlist mode mentioned in the same bullet is the version that matches the stated principle, and the network layer already gets this right (deny by default, explicit egress allowlist).
Two coherent options:
- Drop the denylist. Shell is allowlist only: a set of permitted command names with argument constraints, everything else goes to Review. Consistent with least privilege, and consistent with the network layer.
- Keep it as defence in depth and say so. Frame it as a convenience layer that catches the careless case, state plainly that it is bypassable, and make sure no profile relies on it for a security property.
The second is defensible. What is not defensible is a denylist doing load bearing work in a document that says it is not a detection engine.
Note that the default blocklist in the network layer ("pastebins and cloud metadata IPs") has the same shape and deserves the same treatment. Blocking 169.254.169.254 is worth doing, but egress deny by default already covers it, and listing pastebins invites the reader to think the list is the protection.
What would help: pick one of the two options, and adjust either the shell bullet or the What it is not bullet so they agree.
Raised during the public review window (closes 2026-09-19).
The shell layer and the What it is not section disagree.
Proposed approach:
What it is not:
A denylist of known exfiltration patterns is a detection engine. It is the same thing the document criticises Clampd for, at smaller scale. The Problem section makes the criticism explicitly:
Beyond the inconsistency, command pattern matching does not hold up. If the denylist catches
curl --data-binary @file, thenbase64 file | curl -d @-,python3 -c "...",sh ./deploy.sh,curl "$URL" -d "@$F", a renamed binary, or anything reading the file in one command and sending it in the next all walk past it. Shell is a language with unbounded ways to express the same effect, so an argument denylist is a speed bump, and its main cost is that it reads as protection.The allowlist mode mentioned in the same bullet is the version that matches the stated principle, and the network layer already gets this right (deny by default, explicit egress allowlist).
Two coherent options:
The second is defensible. What is not defensible is a denylist doing load bearing work in a document that says it is not a detection engine.
Note that the default blocklist in the network layer ("pastebins and cloud metadata IPs") has the same shape and deserves the same treatment. Blocking
169.254.169.254is worth doing, but egress deny by default already covers it, and listing pastebins invites the reader to think the list is the protection.What would help: pick one of the two options, and adjust either the shell bullet or the What it is not bullet so they agree.
Raised during the public review window (closes 2026-09-19).