Fix Linux sandbox masking for root-owned canonical executables #256

New issue

Closed

opened 2026-07-24 05:33:44 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-24 05:33:44 +00:00

Member

Reproduction

On Linux with Ward v0.798 and cli-guard v0.103.0, a ward exec verb whose entry command is make fails before the child starts:

sandbox: ensure canonical entry make: open /usr/bin/make: permission denied

The same audited verb succeeds with CLIGUARD_NO_SANDBOX=1.

Cause

installToolShim calls touch(tool.canonical) before maskWithShim. For an existing root-owned /usr/bin/make, touch requires write access and returns EACCES, even though the existing path is already a valid bind-mount target.

Expected

The Linux sandbox should mask an existing canonical executable without requiring the invoking user to write to that executable. A regression test should cover a non-symlink executable in a root-owned directory.

Acceptance

ward exec can jail a verb backed by a root-owned canonical executable.
Grandchild gate routing remains enforced.
The explicit no-sandbox compatibility switch is no longer required for this case.

## Reproduction On Linux with Ward v0.798 and cli-guard v0.103.0, a `ward exec` verb whose entry command is `make` fails before the child starts: ```text sandbox: ensure canonical entry make: open /usr/bin/make: permission denied ``` The same audited verb succeeds with `CLIGUARD_NO_SANDBOX=1`. ## Cause `installToolShim` calls `touch(tool.canonical)` before `maskWithShim`. For an existing root-owned `/usr/bin/make`, `touch` requires write access and returns `EACCES`, even though the existing path is already a valid bind-mount target. ## Expected The Linux sandbox should mask an existing canonical executable without requiring the invoking user to write to that executable. A regression test should cover a non-symlink executable in a root-owned directory. ## Acceptance * `ward exec` can jail a verb backed by a root-owned canonical executable. * Grandchild gate routing remains enforced. * The explicit no-sandbox compatibility switch is no longer required for this case.

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-07-29 03:45:29 +00:00

coilyco-ops commented

2026-08-01 17:22:22 +00:00

Author

Member

Confirmed again on kai-server with Ward v0.866.0 and a Bash-backed infrastructure verb: sandbox: ensure canonical entry bash: open /usr/bin/bash: permission denied. The child script never started. Infrastructure is using a narrow direct-executable declaration for the new retention verb (infrastructure#721) so incident relief can proceed without CLIGUARD_NO_SANDBOX. The underlying root-owned canonical executable bug remains here and affects existing Bash-backed Ward verbs.

coilyco-ops added

and removed

labels

2026-08-05 10:25:56 +00:00

coilyco-ops referenced this issue from a commit

2026-08-14 05:25:17 +00:00