linux-command-guard
v1.0.1Blocks destructive Linux commands by enforcing allowlist execution, denylist checks, regex detection, protected paths, and approval for risky actions.
⭐ 0· 48·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Benign
high confidencePurpose & Capability
Name/description (allowlist-first Linux command guard) aligns with the included Python package, rule files, and tests. All required files and logic relate to parsing commands, applying allowlist/denylist/regex/protected-path checks, and reporting decisions; there are no unrelated credentials, binaries, or endpoints requested.
Instruction Scope
SKILL.md directs the agent to run this policy before executing shell commands and describes the intended flow. The runtime code only reads local rule files bundled with the package and does not access external endpoints, unrelated system files, or environment variables beyond normal execution. The instructions are not open-ended and do not tell the agent to exfiltrate data or inspect unrelated config.
Install Mechanism
No install spec is provided; the skill is instruction-only at the registry level but includes a local Python package (no remote downloads, no installers). The project is self-contained and uses only local rule files and tests—no high-risk download or extract steps are present.
Credentials
The skill requests no environment variables, credentials, or external config paths. All rule data is stored in packaged text files, which is proportionate to the stated purpose.
Persistence & Privilege
Skill flags are default (always: false, user-invocable: true). The skill does not attempt to persist beyond its package files or modify other skills. Note: model invocation is allowed by default (disable-model-invocation is false) — this is platform default and not itself a red flag.
Assessment
This skill appears coherent and implements an allowlist-first command-checker as described. Before installing or enabling it: 1) Verify your agent integration actually calls this check before executing shell commands (a policy file alone does nothing unless invoked). 2) Do not rely on this as the sole defense — run agents non-root in sandboxes/microVMs with resource and network limits. 3) Review and lock the allowlist and approval_required lists to match your security posture (the default allowlist is intentionally small). 4) Test the packaged rules in a controlled environment to ensure regex and tokenization behave as you expect (there is a stray backtick line in regex_rules.txt that is benign but worth validating against your Python RE engine). 5) If you need stronger guarantees, couple this with OS-level controls (seccomp/AppArmor/SELinux) and a manual approval workflow for the binaries marked as high-risk.Like a lobster shell, security has layers — review code before you run it.
latestvk97bm5n711gdmm6f5zta2rk57583y4xd
License
MIT-0
Free to use, modify, and redistribute. No attribution required.