T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:70
- Finding
- Shell Sandbox Omits Network and Resource Isolation Controls## Vulnerability Details **File Location**: `SKILL.md`, lines 70-81 **Vulnerability Type**: Inconsistent sandbox isolation and unrestricted execution configuration **Risk Level**: High ### Vulnerable 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.sh ``` ## Security Guidelines 1. **Mount Minimization**: **Never** mount sensitive host directories (e.g., `/etc`, `~/.ssh`, or `/`) into the sandbox. Mount only the specifically designated `.sandbox` or task-related directory. 2. **Network Isolation**: By default, include `--network none` in the command to prevent the code from exfiltrating data or initiating unwanted network requests, unless network access is functionally necessary for the test. 3. **Privileges**: Never use `--privileged` mode or run containers mapped directly to the root user of the host if preventable. ``` ### 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]
- Remediation
- ## Remediation Suggestions Apply consistent isolation controls to every runtime example. At minimum, update the shell command to include: - `--network none` to disable outbound and inbound container networking by default. - `--memory="512m"` and `--cpus="1.0"` to constrain resource consumption. - `--pids-limit` to mitigate fork bombs and uncontrolled process creation. - `--cap-drop ALL` to remove unnecessary Linux capabilities. - `--security-opt no-new-privileges` to 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 `tmpfs` for 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.sh ``` If 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.