Skip to content

feat(safe-exec): harden curl validation and add security posture framework - #10

Open
pshickeydev wants to merge 1 commit into
traust-security:mainfrom
pshickeydev:fix/safe-exec-curl-hardening
Open

pshickeydev wants to merge 1 commit into
traust-security:mainfrom
pshickeydev:fix/safe-exec-curl-hardening

Conversation

@pshickeydev

Copy link
Copy Markdown

Summary

  • Harden validation of target-derived commands and make execution policy explicit through restricted, baseline, and privileged postures, with high, medium, and low aliases.
  • Allow consumers to supply engagement-specific destinations and scope preserved environment variables to selected pipeline segments, without requiring static deployment host lists.

Behavior

Curl validation walks options rather than matching a fixed flag set. Unvetted options are denied, URL operands are limited to HTTP(S), and execution disables automatic curl configuration loading. Execution also separates leading environment assignments from argv and preserves caller-supplied hosts when recovering validated segments.

Postures can be configured file-wide through defaults.posture or per profile:

Posture Curl destination policy
restricted Explicit hosts required; redirects denied; pipeline profiles require keep_env_heads
baseline Public destinations permitted; non-global IP literals and internal hostname forms require explicit allowance; redirects denied
privileged Backward-compatible defaults; an empty host list permits any destination

curl_allowed_hosts and call-time allowed_hosts are combined. keep_env_heads controls which pipeline segments receive preserved or explicitly supplied environment values.

These are command-validation controls, not a network sandbox: hostname policy does not establish DNS ownership or constrain sockets opened by arbitrary child tools.

Compatibility and rollout

  • No contracts change is required: the released configuration model accepts these additional fields. Engine semantics validate posture values.
  • Includes the version and changelog update for the next engine release.
  • Land and tag this first. Consumer #26 adds engagement authorization, scoped discovery, and structured HTTP execution; its dependency pin and lockfile must be updated after the tag exists.
  • Estate #6 adopts restricted validation and must land after the compatible consumer is deployed.

Verification

Previously recorded engine verification: 216 tests passed in tests/test_safe_exec.py, Ruff clean, and release gates clean. Consolidating this PR into one signed commit did not change its tree. The consumer's subsequent regression runs used this engine checkout.

Description prepared with AI assistance.


Recreated from #8. The source fork was deleted and re-forked as part of a repository
cleanup, which auto-closed the original PR and left its head ref unrecoverable. Branch
content is byte-identical to #8 at dd556b6.

Disclosure: this footer was drafted by an AI assistant (Claude). The PR description above
is the original author's text, restored verbatim from a pre-deletion backup.

Harden command validation and scope credential exposure so deployments
can restrict network destinations while retaining explicit policy choices.
@pshickeydev
pshickeydev requested a review from a team as a code owner September 21, 2026 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant