T09 · Insecure Skill Coding Practices
- Location
scripts/configure_official_cli.sh:62- Finding
Shell Injection Through Unsafely Generated Wrapper Script
- Content
View full analysis
"$WRAPPER_PATH" < "$CONFIG_FILE" <- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is purpose-aligned but needs review because its root-run setup scripts can make broad system changes, create an unsafe wrapper, and modify vault notes during verification.
Review this skill before installing on any important host. Use only a carefully chosen vault path, clear privileged environment variables such as WRAPPER_PATH and OBSIDIAN_USER, avoid running verification unless you accept a write to the daily note, and prefer a version that validates paths, safely creates the wrapper, and verifies the downloaded package.
scripts/configure_official_cli.sh:62Shell Injection Through Unsafely Generated Wrapper Script
scripts/configure_official_cli.sh:62Unrestricted Privileged File Overwrite Through WRAPPER_PATH
scripts/install_official_obsidian.sh:41Downloaded Debian Package Is Installed as Root Without Integrity Verification
The skill claims to set up a safer headless model with a dedicated non-root user, ACL-restricted vault access, Xvfb adaptation, and a stable wrapper, but the analyzed behavior reportedly does not actually enforce those controls. This mismatch is dangerous because operators may trust the documented safety properties and run a workflow as root or in an incompletely configured state, exposing sensitive vault data or causing insecure system changes under false assumptions.
The skill clearly instructs shell execution as root and references multiple installation/configuration scripts, but it declares no explicit tool scope such as allowed-tools or permissions. That creates an authorization gap where an agent may invoke shell commands without a formally constrained execution boundary, increasing the risk of unintended or over-privileged command execution in a high-impact system-modifying workflow.
The script, when run as root, recursively changes ACLs on a user-supplied vault path, modifies /root traversal permissions when the vault is under /root, writes a config file, and installs an executable wrapper under /usr/local/bin without any confirmation, scoping checks, or warning to the operator. In this headless Obsidian setup context these actions are expected, but they still create real risk because a mis-specified VAULT_PATH or wrapper path can silently broaden access to sensitive files or overwrite system binaries.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
set -euo pipefail
if [[ ${EUID:-$(id -u)} -ne 0 ]]; then
echo "Run as root." >&2
exit 1
fi
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
set -euo pipefail
if [[ ${EUID:-$(id -u)} -ne 0 ]]; then
echo "Run as root." >&2
exit 1
fi
This shell script runs as root and makes system-level changes by updating packages, installing dependencies, and creating a new local user account. Although it prints status messages after some actions, there is no prior disclosure or confirmation warning that these privileged changes will be made to the host system.
The verification script performs a real write to the user's vault by appending a marker to the daily note, which modifies user data during what appears to be a validation step. In this skill context, the behavior is likely intended as an end-to-end test, but it is still unsafe because it changes persistent note content without explicit consent, dry-run support, or cleanup.
The verification sequence includes a write operation, obs daily:append content="skill verification", but the skill does not warn that verification will modify user vault contents. In a notes or knowledge-management context, silent data mutation can damage trust, pollute records, or alter sensitive files unexpectedly, even if the change seems minor.