T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:70- Finding
Shell Sandbox Omits Network and Resource Isolation Controls
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 70-81
Vulnerability Type: Inconsistent sandbox isolation and unrestricted execution configuration
Risk Level: HighVulnerable Code
bash ### 3. Bash/Shell Verification Test shell scripts in a generic Alpine environment. ```bash docker run --rm -v "$(pwd)/.sandbox:/app" -w /app alpine sh script.shSecurity Guidelines
- Mount Minimization: Never mount sensitive host directories (e.g.,
/etc,~/.ssh, or/) into the sandbox. Mount only the specifically designated.sandboxor task-related directory. - Network Isolation: By default, include
--network nonein the command to prevent the code from exfiltrating data or initiating unwanted network requests, unless network access is functionally necessary for the test. - Privileges: Never use
--privilegedmode or run containers mapped directly to the root user of the host if preventable.
text ### Technical Analysis The shell verification command executes potentially untrusted scripts without the network and resource restrictions used in the Python and Node.js examples. It omits `--network none`, `--memory`, and `--cpus`, despite the skill claiming that sandboxed execution uses network isolation and hard resource constraints. Docker provides default outbound networking unless networking is explicitly disabled. Consequently, a tested shell script can initiate external connections and transmit information available inside the container. The writable bind mount also exposes the host `.sandbox` directory at `/app`, allowing the script to read, overwrite, delete, or create files in that host-backed directory. The absence of memory, CPU, and process limits also allows a malicious or defective script to consume substantial host resources through the container. The `--rm` option removes the container after execution but does not prevent network access, resource exhaustion, or ...[truncated 1422 chars]- Mount Minimization: Never mount sensitive host directories (e.g.,
- Remediation
View remediation
Remediation Suggestions
Apply consistent isolation controls to every runtime example. At minimum, update the shell command to include:
--network noneto disable outbound and inbound container networking by default.--memory="512m"and--cpus="1.0"to constrain resource consumption.--pids-limitto mitigate fork bombs and uncontrolled process creation.--cap-drop ALLto remove unnecessary Linux capabilities.--security-opt no-new-privilegesto prevent privilege gains inside the container.- A non-root container user where the selected image and task permit it.
- A read-only bind mount when the tested script does not need to modify source files.
- A size-limited
tmpfsfor temporary writable data rather than a writable host directory.
For example:
bash docker run --rm \ --memory="512m" \ --cpus="1.0" \ --pids-limit="128" \ --network none \ --cap-drop ALL \ --security-opt no-new-privileges \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64m \ -v "$(pwd)/.sandbox:/app:ro" \ -w /app \ alpine sh script.shIf write access is functionally necessary, mount only a dedicated output directory as writable and validate any resulting files before using them on the host. Document any exception to network isolation explicitly instead of silently relying on Docker's default network.