fix: fail closed on os_check grant violations - #38
Conversation
- lex.toml: switch to git deps - src/agents/*: build, explore, plan, refactor, review, spec, test agents updated - src/permissions/rules.lex, manifests.lex: permission rules and manifests - src/tools/index.lex, os_check.lex: tool index and OS check tool - src/server/web.lex: web server - src/web/index.html: updated UI Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: alpibrupa <alpibrupa@users.noreply.github.com>
Co-authored-by: alpibrupa <alpibrupa@users.noreply.github.com>
Co-authored-by: alpibrupa <alpibrupa@users.noreply.github.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Security review complete. I found one medium-confidence supply-chain issue introduced by this PR. No prior automation review threads were present, and I did not find an exploitable injection/authz issue in the added os_check path.
Sent by Cursor Automation: PR Lex
| lex-llm = { git = "https://github.com/alpibrusl/lex-llm" } | ||
| lex-agent = { git = "https://github.com/alpibrusl/lex-agent" } | ||
| lex-trail = { git = "https://github.com/alpibrusl/lex-trail" } | ||
| lex-spec = { git = "https://github.com/alpibrusl/lex-spec" } | ||
| lex-schema = { git = "https://github.com/alpibrusl/lex-schema" } | ||
| lex-os-manifest = { git = "https://github.com/alpibrusl/lex-os-manifest" } | ||
| lex-web = { git = "https://github.com/alpibrusl/lex-web" } |
There was a problem hiding this comment.
Severity: Medium. These new Git dependencies are floating: there is no tag/rev pin here and no lockfile in the repo, so builds can resolve whatever is on each dependency repo's default branch. If one dependency repo or maintainer account is compromised, attacker-controlled package code can run inside lex-code's process/tool boundary, including code that defines providers, tools, or permission-gate behavior. Pin each Git dependency to an immutable commit/tag and commit the resolver lockfile.
There was a problem hiding this comment.
Found a critical grant-bypass bug and opened a minimal fix in #39.
Bug and impact: os_check only rejected bare net for refactor/test grants. Upstream Lex treats mcp and llm_cloud as network egress effects too, so a refactor-mode file declaring [llm_cloud] or [mcp] could pass os_check even though the grant says net=none.
Root cause: the new deny list duplicated only part of the Lex trust lattice instead of covering every network-effect name.
Fix and validation: PR #39 adds a shared network-effect deny list (net, http, mcp, llm_cloud) for all network: none modes. I validated with lex 0.9.7: lex check src/tools/os_check.lex passes, a targeted fixture emits required_effects: ["llm_cloud"], and a temporary wrapper calling os_check.execute returns grant_violation for llm_cloud under refactor mode.
Sent by Cursor Automation: Quality of PR Lex
| ["net", "proc"] | ||
| } else { | ||
| if mode == "test" or mode == "refactor" { | ||
| ["net"] |
There was a problem hiding this comment.
This only forbids the bare net effect for refactor/test, but Lex's trust lattice also classifies mcp and llm_cloud as network egress effects. A refactor-mode generated file that declares [llm_cloud] or [mcp] will appear in lex check --output json as that effect name, miss this exact-match deny list, and pass despite the net=none grant. I opened #39 to reject the full network-effect set.
2 participants
Summary
os_checkreturn a tool error when refactor-mode grant violations are detected.lex check --output jsonis missing or malformsdata.required_effectsinstead of reporting a passing grant check.Validation
lex check src/tools/os_check.lexlex fmt --check src/tools/os_check.lexNote: a full
src/Lex check currently fails in unrelatedsrc/server/api.lexwith an effect-row mismatch.