[SECURITY] No command pattern denylist — agents can execute destructive operations unchecked

[h-network]

Problem Statement

NemoClaw sandboxes rely on filesystem and network policies (via OpenShell Landlock/seccomp) to contain agent actions. However, there is no command-level filtering — agents can execute arbitrary commands within the sandbox, including destructive operations like:

• rm -rf /sandbox/*
• dd if=/dev/zero of=/dev/sda
• chmod -R 777 /
• curl with encoded/obfuscated payloads
• Shell injection via backticks, $(), or pipe chains

Impact

An agent that is prompt-injected or behaves unexpectedly can destroy all writable data within the sandbox before any policy layer intervenes. Filesystem policies restrict WHERE the agent can write, but not WHAT commands it runs in writable areas.

Proposed Design

Implement a zero-latency deterministic pattern denylist that evaluates every command before execution:

DENY_PATTERNS = [
    r"rm\s+(-[rf]+\s+)?/",           # recursive delete from root
    r"dd\s+if=",                       # raw disk operations
    r"chmod\s+(-R\s+)?[0-7]{3}\s+/",  # recursive permission changes
    r"mkfs\.",                          # filesystem formatting
    r">\s*/dev/",                       # writing to devices
    r"\|\s*sh\b",                       # piping to shell
    r"curl.*\|\s*(bash|sh)",           # download and execute
]

This runs BEFORE any LLM-based verification, at zero token cost, with zero variance. Same input, same decision, every time. Should be implemented as a pre-execution hook in the sandbox runtime.

Alternatives Considered

PR #794 implements credential redaction in CLI output, which addresses secret leakage in logs. This proposal is distinct — it targets command execution filtering before the command runs, not output sanitization after. They operate at different points in the execution pipeline and are complementary.

Category

enhancement: feature

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request

[h-network]

The following issues compliment the initial list and should be considered to be combined :

• 809
• 808
• 807

[wscurran]

✨ Thanks for submitting this suggestion with a detailed analysis, it addresses a security concern that could improve the security of NemoClaw, which could prevent destructive operations.

---

Possibly related open PRs:
#119 security: fix command injection in Telegram bridge,
#871 security: enforce process limit to prevent fork bombs in sandbox,
#870 feat(security): add prompt injection scanner module

[prekshivyas]

The writable surface this issue is concerned about was significantly reduced in #1121 (Landlock read-only /sandbox, DAC-protected .nemoclaw parent). The remaining writable paths (/tmp, .openclaw-data, .nemoclaw/{state,staging}) are scoped to agent runtime state that's ephemeral by design.

A regex command denylist would be trivially bypassable (encoding, indirection, non-shell languages) and high-maintenance. The Landlock + DAC layering already constrains blast radius at the kernel level, which is the right layer for this.

cc: @cv

[prekshivyas]

The residual risk is the agent destroying its own workspace data within the writable paths. Given that sandboxes are designed to be ephemeral and recreatable, and that a regex denylist is straightforward to bypass via encoding, indirection, or non-shell languages (python3 -c, node -e), the maintenance cost outweighs the security benefit. A determined attacker who can prompt-inject the agent can trivially evade string matching.

I'd recommend closing this now that the kernel-level protections cover the threat model. If workspace durability becomes a concern in the future, periodic snapshots (which already exist in the plugin) are a more robust approach than command filtering.

cc: @cv