docs(security): Add API key hardening guide#11622
Conversation
Provides a workaround for protecting API keys from agent access using Linux user isolation. Agent can use APIs via wrapper scripts but cannot see the actual credentials. Addresses concern raised in openclaw#10659
| sudo -u secretsuser tee /home/secretsuser/scripts/myapi.sh << 'ENDSCRIPT' | ||
| #!/bin/bash | ||
| set -euo pipefail | ||
| source /home/secretsuser/.env |
There was a problem hiding this comment.
Sudoers bypass via interpreter
The sudoers example whitelists /home/secretsuser/scripts/myapi.sh, but that can typically be bypassed by executing the same file through an allowed interpreter (e.g. sudo -u secretsuser /bin/bash /home/secretsuser/scripts/myapi.sh ...), which defeats the allowlist intent if /bin/bash is already allowed by default. Consider documenting the need for sudoers to match the command line strictly (or use sudoers command aliases with arguments / NOEXEC, and ensure the agent user cannot run an arbitrary interpreter as secretsuser).
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/security/api-key-hardening.md
Line: 63:66
Comment:
**Sudoers bypass via interpreter**
The sudoers example whitelists `/home/secretsuser/scripts/myapi.sh`, but that can typically be bypassed by executing the same file through an allowed interpreter (e.g. `sudo -u secretsuser /bin/bash /home/secretsuser/scripts/myapi.sh ...`), which defeats the allowlist intent if `/bin/bash` is already allowed by default. Consider documenting the need for `sudoers` to match the command line strictly (or use `sudoers` command aliases with arguments / `NOEXEC`, and ensure the agent user cannot run an arbitrary interpreter as `secretsuser`).
How can I resolve this? If you propose a fix, please make it concise.| sudo -u secretsuser /home/secretsuser/scripts/myapi.sh GET "users/me" | ||
|
|
||
| # This should fail: | ||
| cat /home/secretsuser/.env | ||
| # Permission denied |
There was a problem hiding this comment.
Test command contradicts whitelist
Step 6 tests running the script with sudo -u secretsuser ..., but Step 5 only configures NOPASSWD for sudo /home/secretsuser/scripts/myapi.sh (no -u secretsuser in the example). As written, a user without broader sudo rights will get prompted for a password (or fail) when running the test command. Either update the test to sudo /home/secretsuser/scripts/myapi.sh ... (matching the sudoers line) or update the sudoers example to explicitly allow sudo -u secretsuser /home/.../myapi.sh usage.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docs/security/api-key-hardening.md
Line: 108:112
Comment:
**Test command contradicts whitelist**
Step 6 tests running the script with `sudo -u secretsuser ...`, but Step 5 only configures `NOPASSWD` for `sudo /home/secretsuser/scripts/myapi.sh` (no `-u secretsuser` in the example). As written, a user without broader sudo rights will get prompted for a password (or fail) when running the test command. Either update the test to `sudo /home/secretsuser/scripts/myapi.sh ...` (matching the sudoers line) or update the sudoers example to explicitly allow `sudo -u secretsuser /home/.../myapi.sh` usage.
How can I resolve this? If you propose a fix, please make it concise.- Add note about never whitelisting interpreters (/bin/bash, etc.) - Clarify that only exact script paths are allowed - Add interpreter bypass to attack vectors table
bfc1ccb to
f92900f
Compare
|
Thanks for your submission however we are closing your PR as stale, if you need to re-open please review contributing guide and if you feel like its required re-open under a new PR. Ensure you have addressed all checks, conflicts and issues. Thanks. |
Summary
Adds a guide to
docs/security/explaining how to protect API keys from agent access using Linux user isolation.The Problem
Agents have filesystem access and can accidentally (or be tricked into) exposing API keys stored in
.envfiles. Rules-based protection ('please don't read this') is not sufficient — agents can forget, make mistakes while debugging, or be manipulated via prompt injection.The Solution
This guide shows how to:
This is a hard technical block enforced by the kernel, not agent discipline.
Context
This guide provides a working solution today while native masked secrets support is being considered.
Greptile Overview
Greptile Summary
Adds a new security doc at
docs/security/api-key-hardening.mddescribing a Linux user-isolation pattern for keeping API keys out of an agent’s readable filesystem while still allowing API usage via whitelistedsudo-run wrapper scripts. The guide walks through creating a dedicated “secrets” user, placing secrets in a root-owned home directory, creating wrapper scripts that source the secrets, and configuring a sudoers allowlist so the agent can execute only those scripts.Confidence Score: 3/5
(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!
Context used:
dashboard- CLAUDE.md (source)dashboard- AGENTS.md (source)