Repository navigation
[Bug] ACS_OPA_PATH substitutes the policy evaluator with no integrity check #72
Description
Found by a six-perspective adversarial review of #60.
packages/agt-bridge/src/opa-path.ts:23-30 resolves the OPA binary in order: explicit $ACS_OPA_PATH, then the bundled optional dependency, then PATH. It treats the explicit value as authoritative and publishes it through raw setenv over FFI. No hash or signature is checked against the binary.
Anyone who can set an environment variable before the Guardian starts substitutes a policy evaluator that returns allow for everything, and the Guardian trusts it by design. opa-path.test.ts covers resolution order, not binary integrity.
Related portability defect in the same file: LIBC_CANDIDATES at lines 54-60 lists glibc, musl, and Darwin only. On Windows every candidate fails to dlopen and the Guardian refuses to start unless the caller pre-set the variable, which the README never mentions.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
drk-ram commentedon Oct 31, 2026
I am working on this issue in PR #344 (and the Windows OPA path portion in PR #337).
fix(agt-bridge): enforce SHA-256 binary integrity on ACS_OPA_PATH
fix(agt): support Windows OPA path publishing and repo-relative path …
fix(agt): support Windows OPA path publishing and repo-relative path …
bar-capsule commentedon Nov 4, 2026
Answering item 7 from #32 here. This attacker is out of scope. Whoever can set the Guardian's environment before it starts already controls the Guardian (its PATH, its library path through LD_PRELOAD, its configuration), so no check inside the process can stop them, and a digest read from the environment can't either. #344 still closes the case this issue describes: ACS_OPA_PATH alone can't swap in another evaluator, because the Guardian refuses to start unless the binary matches the bundled OPA or an explicit ACS_OPA_SHA256. @drk-ram, #344 fits it as written.