Enforce lockdown targets by exec basename across every matching binary #225

New issue

Closed

opened 2026-07-13 22:52:54 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-13 22:52:54 +00:00

Member

Problem:

security-boundary rules lose their value if they only protect one hard-coded path such as /usr/local/bin/kubectl
an agent could reach another kubectl with the same basename through PATH, an absolute path, a tool install dir, or a copied binary unless lockdown treats the target name as canonical
guardfile KDL does not require absolute exec paths, and authoring absolute paths in KDL creates false confidence that the specific path is the security boundary

Existing evidence:

exec guardfiles already parse bare executables, for example: exec kubectl
shim generation already normalizes absolute-path names to basename and dedupes them
SECURITY.md states wrapped tools must be routed through the gate by name or absolute path

Required behavior:

lockdown protected targets are keyed by target exec basename, not a single absolute path
absolute-path invocations to any matching basename are denied or rerouted through the guard as appropriate
PATH invocations to any matching basename are denied or rerouted through the guard as appropriate
if canonical absolute paths are still needed for integrity checks, keep them as optional verification metadata, not as the identity of the protected target
doctor output should distinguish identity (basename target) from integrity hints (expected real paths)

Acceptance criteria:

tests prove a lockdown target named kubectl applies to /usr/local/bin/kubectl, /opt/homebrew/bin/kubectl, and a PATH-discovered kubectl shim/copy
tests prove an absolute-path invocation cannot bypass the lockdown target when the basename matches
docs say KDL exec may use bare executable names and should prefer them unless a wrapper intentionally pins a specific artifact
SECURITY.md or matching security-claim tests cover the basename-wide invariant

This is a security-boundary issue, not a style cleanup.

cli-guard lockdown rules must not depend on one absolute binary path. A protected target like kubectl, aws, gh, docker, or tailscale should be identified by executable name / basename and enforced across every matching binary path an agent can reach. Problem: - security-boundary rules lose their value if they only protect one hard-coded path such as /usr/local/bin/kubectl - an agent could reach another kubectl with the same basename through PATH, an absolute path, a tool install dir, or a copied binary unless lockdown treats the target name as canonical - guardfile KDL does not require absolute exec paths, and authoring absolute paths in KDL creates false confidence that the specific path is the security boundary Existing evidence: - exec guardfiles already parse bare executables, for example: exec kubectl - shim generation already normalizes absolute-path names to basename and dedupes them - SECURITY.md states wrapped tools must be routed through the gate by name or absolute path Required behavior: - lockdown protected targets are keyed by target exec basename, not a single absolute path - absolute-path invocations to any matching basename are denied or rerouted through the guard as appropriate - PATH invocations to any matching basename are denied or rerouted through the guard as appropriate - if canonical absolute paths are still needed for integrity checks, keep them as optional verification metadata, not as the identity of the protected target - doctor output should distinguish identity (basename target) from integrity hints (expected real paths) Acceptance criteria: - tests prove a lockdown target named kubectl applies to /usr/local/bin/kubectl, /opt/homebrew/bin/kubectl, and a PATH-discovered kubectl shim/copy - tests prove an absolute-path invocation cannot bypass the lockdown target when the basename matches - docs say KDL exec may use bare executable names and should prefer them unless a wrapper intentionally pins a specific artifact - SECURITY.md or matching security-claim tests cover the basename-wide invariant This is a security-boundary issue, not a style cleanup.

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-07-13 22:53:27 +00:00

Use bare kubectl exec target in ward KDL guardfile #513

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-13 23:02:23 +00:00

Enforce lockdown targets by exec basename across every matching binary #226

coilyco-ops commented

2026-07-13 23:06:31 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA)

The implementation felt straightforward once the basename identity split was traced through doctor, hook, and docs. Confidence is high. Surprise: the godoc snapshot and doc-size guards needed a small cleanup after the comment changes.

Follow-up: PR #226 is open and green.

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA) The implementation felt straightforward once the basename identity split was traced through doctor, hook, and docs. Confidence is high. Surprise: the godoc snapshot and doc-size guards needed a small cleanup after the comment changes. Follow-up: PR #226 is open and green. </details>