fix: prevent command executors from bypassing security policy#2013
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds command-name normalization helpers, detects common interpreter/utility "command executors", marks them high-risk in command_risk_level, rejects them early in is_args_safe, and updates is_command_allowed to use the basename helper. Tests ensure executors remain blocked even with custom allowlists. ChangesCommand Executor Blocking in Security Policy
sequenceDiagram
participant Caller as "Caller"
participant Policy as "SecurityPolicy"
participant Basename as "command_basename"
participant Normalize as "normalize_executable_name"
participant ExecCheck as "is_command_executor"
participant Risk as "command_risk_level"
participant Args as "is_args_safe"
Caller->>Policy: submit command line
Policy->>Basename: extract basename
Basename->>Normalize: normalize (lowercase, strip .exe)
Normalize->>ExecCheck: check executor list / python variants
ExecCheck->>Risk: flag High risk if executor
Risk->>Args: cause early rejection if executor
Args->>Policy: return allowed/denied
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/openhuman/security/policy.rs`:
- Around line 193-201: The is_python_command function misses Windows
pythonw<version> names (e.g., pythonw3, pythonw3.12); update the suffix check in
is_python_command (after calling normalized_command_name) to treat a suffix that
starts with a digit OR starts with 'w' followed by a digit as a versioned python
variant. Concretely, in is_python_command replace the current
strip_prefix("python")...is_some_and(|ch| ch.is_ascii_digit()) logic with a
predicate that returns true when the first suffix char is a digit OR when the
first char == 'w' and the second char is a digit, so python3, python312,
pythonw3, pythonw3.12, etc. are all detected.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dcd2b1cd-0a81-4c51-a352-482c97c62675
📒 Files selected for processing (2)
src/openhuman/security/policy.rssrc/openhuman/security/policy_tests.rs
Summary
allowed_commands.xargs,awk,perl, python-family commands such aspython,python3, andpython3.12,ruby,bash,sh, andenvas high-risk command executors..exesuffixes before policy checks.Problem
Issue #1923 identifies that the command allowlist can be weakened if dangerous command-executor tools are explicitly allowlisted. Tools such as
xargs,awk,perl, Python-family interpreters,ruby, shell binaries, andenvcan execute arbitrary commands or code, so allowing them by command name alone creates policy bypass paths.Solution
src/openhuman/security/policy.rs.CommandRiskLevel::High.allowed_commandslist.Submission Checklist
cargo llvm-cov -p openhumanwas attempted but did not complete successfully before final report generation.## Related- N/A: no coverage-matrix feature ID.Closes #NNNin the## RelatedsectionImpact
This is a Rust core security-policy hardening change. It affects command validation for CLI/RPC/agent flows that call
SecurityPolicy::is_command_allowed()orvalidate_command_execution().No migration or frontend behavior changes are expected. Custom configurations that previously allowed these interpreter/bridge commands will now have them blocked by policy.
Related
AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
fix/security-command-interpreter-policyc2f70bb0ccaeb8af85effc7ea2e4e6fa8a1e4554Validation Run
pnpm --filter openhuman-app format:check— no app workspace changes.pnpm typecheck— no TypeScript changes.cargo test --manifest-path Cargo.toml --lib openhuman::security::policy::tests:: -- --nocapturecargo fmt --check --manifest-path Cargo.toml;cargo check --manifest-path Cargo.toml --libapp/src-taurichanges.cargo llvm-cov test -p openhuman --manifest-path Cargo.toml --lib --lcov --output-path lcov-core.info -- openhuman::security::policy::tests::;diff-cover lcov-core.info --compare-branch=origin/main --fail-under=80— passed, 100% changed-line coverage.Validation Blocked
command:cargo llvm-cov -p openhuman --lcov --output-path lcov-core.infoerror:Full core coverage run attempted but did not complete successfully before final report generation.impact:Focused Rust policy tests and focused diff coverage passed; full CI coverage should be relied on for merged all-target coverage.Behavior Changes
allowed_commands.Parity Contract
git status,find . -name, pipes between safe commands, and env-var prefixes for safe commands remain allowed.SecurityPolicyguard path.Duplicate / Superseded PR Handling
Summary by CodeRabbit