Lerwee Docker Lwops Deployer

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:42 AM UTC
• Version: 1.0.0

Overview

This skill is a real Docker deployment helper, but it can make privileged host changes and start a privileged remote container even when the request looks read-only.

Review this carefully before installing. Use only on an isolated host where privileged containers and Docker service changes are acceptable. Do not follow the NOPASSWD: ALL guidance, avoid exposing the published ports to untrusted networks, and require an explicit deploy action with a pinned and verified image before running it.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads

Findings (6)

T03 · Remote Payload Retrieval and Execution

Error

• Location: lib/docker-utils.sh:201
• Finding: Unpinned Remote Container Image Executed with Host-Equivalent Privileges<![CDATA[ ## Vulnerability Details **File Location**: `lib/system-utils.sh:103-113`, `lib/docker-utils.sh:201-215`, `lib/docker-utils.sh:228-260` **Vulnerability Type**: Untrusted remote payload execution with excessive container privileges **Risk Level**: Critical ### Vulnerable Code ```bash get_image_name() { local arch="$1" case "$arch" in x86_64) echo "swr.cn-south-1.myhuaweicloud.com/cloud-lwops/lwops_rocky8_x86_image:latest" ;; aarch64) echo "swr.cn-south-1.myhuaweicloud.com/cloud-lwops/lwops_rocky8_arm_image:latest" ;; *) echo "" ;; esac } ``` ```bash docker_pull() { local image="$1" if [ -z "$image" ]; then return 1 fi if sudo docker pull "$image"; then return 0 else return 1 fi } ``` ```bash if sudo docker run -d \ --name "$container_name" \ --privileged \ -p "${host_port1}:80" \ -p "${host_port2}:8081" \ --hostname "$container_name" \ -v /sys/fs/cgroup:/sys/fs/cgroup:${cgroup_mode} \ "$image" \ /usr/sbin/init; then ``` ### Technical Analysis The Skill pulls images through the mutable `latest` tag rather than a content-addressed digest. The effective payload can therefore change after the Skill has been reviewed. No image signature, digest, provenance, or expected identity is verified before execution. The downloaded image is then run with `--privileged`. Privileged containers receive all Linux capabilities, broad device access, relaxed security restrictions, and a substantially enlarged kernel attack surface. The host cgroup hierarchy is also mounted into the container. In cgroup v2 environments, `execute.sh:241-245` selects `rw`, allowing the remote image to modify host cgroup state: ```bash local cgroup_mode="ro" if [ "$cgroup_version" = "v2" ]; then cgroup_mode="rw" fi ``` This combination effectively treats an externally controlled, mutable containe ...[truncated 1196 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin each image to a reviewed immutable digest, for example: ```bash image="registry.example/repository/image@sha256:EXPECTED_DIGEST" ``` 2. Verify image signatures and provenance using an appropriate mechanism such as Cosign or Docker Content Trust. 3. Remove `--privileged`. 4. Run the application as a non-root container user. 5. Start with `--cap-drop=ALL` and add only individually documented capabilities that are strictly required. 6. Add `--security-opt=no-new-privileges:true`. 7. Retain the default seccomp and AppArmor/SELinux restrictions. 8. Use a read-only container filesystem where possible. 9. Do not mount the host cgroup hierarchy. If compatibility absolutely requires access, expose the smallest possible read-only subset and document why it is necessary. 10. Refuse deployment if the expected digest or signature cannot be verified. ]]>

T06 · System Persistence

Warning

• Location: lib/docker-utils.sh:181
• Finding: Docker Service Is Persistently Enabled Without Explicit Consent<![CDATA[ ## Vulnerability Details **File Location**: `lib/docker-utils.sh:181-195` **Vulnerability Type**: Unnecessary system service persistence **Risk Level**: Medium ### Vulnerable Code ```bash ensure_docker_running() { if ! sudo systemctl is-active --quiet docker; then sudo systemctl start docker || { return 1 } fi sudo systemctl enable docker >/dev/null 2>&1 return 0 } ``` ### Technical Analysis The Skill enables Docker as a boot-time system service every time it ensures that Docker is running. Starting Docker for the current deployment does not inherently require modifying the host's persistent startup configuration. This operation is performed without a dedicated option or explicit confirmation. It also suppresses all output from `systemctl enable`, preventing users from seeing whether the persistence operation succeeded or failed. Docker is a privileged system daemon. Keeping it enabled after the Skill run permanently increases the host's attack surface, particularly when the deployment was intended only for temporary development or testing. ### Attack Path 1. A user invokes the Skill for a one-time deployment or status-related request. 2. Execution reaches `ensure_docker_running`. 3. The Skill runs `sudo systemctl enable docker`. 4. Docker is registered to start automatically on future boots. 5. The privileged daemon continues to exist across sessions and reboots even after the immediate task is complete. ### Impact Assessment The operation creates persistent system-level state and causes a privileged daemon to survive the Skill run. This may: - Increase long-term host attack surface. - Violate temporary or ephemeral deployment expectations. - Conflict with host administration policies. - Leave Docker active after the Skill itself is removed. - Permit Docker-managed containers configured with restart policies elsewhere to return after reboot. The persistence is related to the deployment function ...[truncated 128 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove automatic execution of `systemctl enable docker`. 2. Start Docker only for the current session when required. 3. Provide a separate explicit option such as `--enable-docker-at-boot`. 4. Obtain clear user confirmation before making a persistent startup change. 5. Report the persistence operation and its result instead of suppressing all output. 6. Document how to reverse the operation: ```bash sudo systemctl disable docker ``` 7. If the Skill installed Docker solely for temporary use, offer a complete cleanup procedure covering the package, repository configuration, service state, containers, and images. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: execute.sh:43
• Finding: Natural-Language Intent Is Ignored and Read-Only Requests Trigger Deployment<![CDATA[ ## Vulnerability Details **File Location**: `execute.sh:43-50`, `execute.sh:160-256`, `INSTALL.md:180-203` **Vulnerability Type**: Missing operation validation and unsafe default behavior **Risk Level**: High ### Vulnerable Code ```bash local input="" if [ $# -eq 0 ]; then input=$(cat) else input="$1" fi ``` The `input` variable is never subsequently parsed or used to select an operation. Execution proceeds into installation and deployment: ```bash if ! ensure_docker_installed; then exit 1 fi if ! ensure_docker_running; then exit 1 fi ``` ```bash if ! docker_pull "$image"; then exit 1 fi ``` ```bash if ! docker_start_container "$CONTAINER_NAME" "$image" "$host_port1" "$host_port2" "$cgroup_mode"; then exit 1 fi ``` The installation guide presents the following as a test: ```bash ./wrapper.sh "{}" ``` It also states that a request to check whether Docker is installed will check the environment, while the implementation continues into image retrieval and deployment. ### Technical Analysis The Skill declares support for multiple operations, including environment checks, status queries, information retrieval, initial deployment, and redeployment. However, the implementation has only one effective operation: deploy unless the fixed container is already running. There is no intent parser, operation allowlist, explicit deployment flag, or confirmation boundary. Consequently, nominally harmless requests can cause package installation, repository changes, persistent service enablement, remote image execution, network publication, and replacement of an existing stopped container. This is a dangerous violation of least astonishment and least privilege. Read-only requests should never silently transition into privileged state-changing operations. ### Attack Path 1. A user follows the documented validation command `./wrapper.sh "{}"` or asks only to check the Docker environment. 2. The wrapper forwards the value to `execute.s ...[truncated 776 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Define a strict operation schema, such as: - `status` - `check-docker` - `container-info` - `deploy` - `redeploy` - `stop` - `remove` 2. Default ambiguous or empty input to a read-only help or status operation. 3. Require an explicit deployment or redeployment operation before making changes. 4. Require confirmation before: - Installing packages. - Adding package repositories or trust keys. - Enabling services. - Deleting an existing container. - Starting a privileged or externally reachable workload. 5. Keep status and information paths free of side effects. 6. Reject unsupported or malformed input rather than silently deploying. 7. Correct `README.md`, `INSTALL.md`, and `SKILL.md` so their examples precisely match implementation behavior. 8. Add automated tests proving that status, check, empty, and malformed requests cannot perform deployment. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: INSTALL.md:323
• Finding: Documentation Recommends Permanent Root-Equivalent Account Access<![CDATA[ ## Vulnerability Details **File Location**: `INSTALL.md:323-336`, `README.md:317-322`, `execute.sh:155` **Vulnerability Type**: Excessive and persistent privilege grant **Risk Level**: High ### Vulnerable Code and Guidance The installation guide recommends an unrestricted passwordless sudo rule: ```bash echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USER sudo chmod 440 /etc/sudoers.d/$USER ``` It also offers Docker group membership: ```bash sudo usermod -aG docker $USER newgrp docker ``` The runtime error guidance similarly proposes: ```bash echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USER ``` ### Technical Analysis `NOPASSWD: ALL` allows the affected user and every process running as that user to execute arbitrary commands as root without authentication. This is not limited to Docker installation or management and substantially exceeds the permissions needed by the Skill. Membership in the Docker group is also normally root-equivalent because a Docker user can mount the host filesystem into a container, start privileged containers, or otherwise use the Docker API to obtain host control. Both changes persist beyond the Skill invocation. Recommending them as routine troubleshooting or automation solutions converts a temporary authorization requirement into a permanent system-wide privilege grant. ### Attack Path 1. A user encounters the Skill's permission error. 2. The user follows the documented recommendation. 3. The user's account receives unrestricted passwordless sudo or Docker daemon access. 4. A later malicious process, compromised application, shell script, or account takeover executes under that user. 5. The attacker invokes unrestricted sudo or creates a Docker container with host filesystem access. 6. The attacker obtains root-level host control without an additional authentication boundary. ### Impact Assessment The granted privileges permit complete host compromise, including: - Arbitrary ...[truncated 401 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `NOPASSWD: ALL` recommendation from all documentation and runtime messages. 2. Do not present Docker group membership as a least-privilege alternative. 3. Prefer interactive, operation-specific sudo authorization. 4. If non-interactive automation is essential, create a dedicated service account and a tightly constrained sudoers policy permitting only reviewed commands with fixed arguments. 5. Avoid allowing arbitrary `docker run`, `docker exec`, shell execution, package-manager commands, or writable file paths through the sudo policy. 6. Use a dedicated constrained deployment service or rootless container runtime where feasible. 7. Include revocation instructions for users who previously followed the guidance: ```bash sudo rm -f /etc/sudoers.d/USERNAME sudo gpasswd -d USERNAME docker ``` 8. Validate sudoers changes with `visudo -c` before installation. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: lib/docker-utils.sh:252
• Finding: Container Services Are Published on All Host Network Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `lib/docker-utils.sh:252-260` **Vulnerability Type**: Unrestricted network service exposure **Risk Level**: High ### Vulnerable Code ```bash if sudo docker run -d \ --name "$container_name" \ --privileged \ -p "${host_port1}:80" \ -p "${host_port2}:8081" \ --hostname "$container_name" \ -v /sys/fs/cgroup:/sys/fs/cgroup:${cgroup_mode} \ "$image" \ /usr/sbin/init; then ``` ### Technical Analysis Docker port publication without a host bind address normally binds the selected ports to all available host interfaces, represented by `0.0.0.0` and potentially `::`. The Skill describes local development and testing as primary use cases, but it does not default to loopback-only access. It also does not verify application authentication, TLS, firewall policy, or whether remote network access was requested. This exposure is especially significant because the service runs inside a privileged, externally downloaded container. A remotely exploitable application flaw can therefore have a substantially greater impact than it would in a properly isolated container. The label `"https"` in output does not establish TLS; the generated URL uses `http://` for port 8081. ### Attack Path 1. The user deploys the container on a workstation or server connected to a shared or routable network. 2. Docker publishes the selected ports on all host interfaces. 3. Another network peer scans or discovers the ports. 4. The peer accesses an unauthenticated, weakly authenticated, or vulnerable LwOps endpoint. 5. If the service is compromised, attacker-controlled code runs inside a privileged container with host cgroup access. 6. The attacker may then attempt host compromise using the excessive container privileges. ### Impact Assessment Potential consequences include: - Unauthorized remote access to the monitoring application. - Exposure of application or monitoring data. - Exploitation of vulnerabilitie ...[truncated 348 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Bind services to loopback by default: ```bash -p "127.0.0.1:${host_port1}:80" -p "127.0.0.1:${host_port2}:8081" ``` 2. Require an explicit option and user confirmation before binding to non-loopback interfaces. 3. Allow users to configure a specific trusted bind address. 4. Verify that authentication is enabled before permitting remote exposure. 5. Configure TLS correctly for services described as HTTPS. 6. Document firewall rules and expected network trust boundaries. 7. Consider a reverse proxy with authentication, TLS, request limits, and access logging. 8. Report the exact addresses on which Docker published each port. ]]>

T09 · Insecure Skill Coding Practices

Note

• Location: lib/lock-utils.sh:8
• Finding: Predictable Shared Temporary Lock Permits Local Deployment Denial of Service<![CDATA[ ## Vulnerability Details **File Location**: `lib/lock-utils.sh:8-31`, `lib/lock-utils.sh:34-73`, `lib/lock-utils.sh:78-80` **Vulnerability Type**: Unsafe predictable temporary file handling **Risk Level**: Low ### Vulnerable Code ```bash LOCK_DIR="/tmp/docker-lwops-deployer" LOCK_FILE="$LOCK_DIR/deploy.lock" LOCK_TIMEOUT=300 ``` ```bash init_lock() { if [ ! -d "$LOCK_DIR" ]; then mkdir -p "$LOCK_DIR" || { return 1 } fi return 0 } ``` ```bash acquire_lock() { init_lock || return 1 if ( set -o noclobber; echo "$$" > "$LOCK_FILE" ) 2>/dev/null; then return 0 else return 1 fi } ``` ```bash release_lock() { rm -f "$LOCK_FILE" 2>/dev/null return 0 } ``` ### Technical Analysis The lock uses a globally predictable path beneath `/tmp`. The code does not create the directory with restrictive permissions, verify directory ownership, reject symbolic links, or ensure that the lock being removed belongs to the current process. A local user can pre-create the directory or lock file. A live PID belonging to an unrelated process can cause the Skill to report that deployment is in progress. Directory ownership and permission manipulation can also prevent legitimate lock creation. The audit did not confirm a reliable privileged arbitrary-file overwrite through this code because the lock is created before privileged Docker operations and `noclobber` is used. The confirmed issue is local denial of service and unreliable lock ownership. ### Attack Path 1. A local attacker creates `/tmp/docker-lwops-deployer/deploy.lock`. 2. The attacker writes the PID of a long-running process into the file. 3. A victim invokes the Skill. 4. `get_lock_status` or `acquire_lock_with_timeout` sees the process as active. 5. The Skill refuses deployment or waits until timeout. 6. The attacker recreates the file as needed to maintain the denial of service. ### Impact Assessment The vulnerability can: - ...[truncated 374 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Use `flock` rather than a manually managed PID file. 2. Store per-user locks under `$XDG_RUNTIME_DIR`, which should be owned by the invoking user and unavailable to other users. 3. For a system-wide lock, create a dedicated root-owned runtime directory during installation with restrictive permissions. 4. Open the lock file safely and hold the descriptor for the full operation: ```bash exec 9>"$XDG_RUNTIME_DIR/docker-lwops-deployer.lock" flock -n 9 || exit 1 ``` 5. Verify ownership and mode before using any existing lock directory. 6. Do not remove a lock merely because a PID appears inactive; PID reuse can make PID-file checks unreliable. 7. Ensure cleanup only releases the lock held by the current process. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (136)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**手动卸载**：
```bash
rm -rf ~/.openclaw/skills/docker-lwops-deployer
```

### 3. 清理配置（可选）

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

**手动卸载**：
```bash
rm -rf ~/.openclaw/skills/docker-lwops-deployer
```

### 3. 清理配置（可选）

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The document explicitly recommends granting the current user `NOPASSWD: ALL` sudo access, which is a major privilege expansion unrelated to the narrow need of deploying a local Docker container. If followed, any process running as that user can execute arbitrary root commands without authentication, greatly increasing the blast radius of compromise.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: Recommending passwordless sudo without a strong warning normalizes a dangerous configuration that effectively removes an important privilege boundary. In the context of an automation skill, this makes accidental or malicious command execution as root significantly easier.

Chaining Abuse

High

• Category: Tool Misuse

Content

1. **配置 sudo 无密码**（推荐用于自动化）：
```bash
echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USER
sudo chmod 440 /etc/sudoers.d/$USER
```

• Confidence: 98% confidence
• Finding: The pipeline writes an unrestricted sudoers rule directly into `/etc/sudoers.d/$USER` using elevated privileges, creating a powerful chained privilege-escalation setup. In this deployment-skill context, chaining shell output into privileged file creation is especially dangerous because it normalizes persistent root-equivalent access for convenience.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

3. **如果确认没有其他部署**，手动删除锁：
```bash
rm -f /tmp/docker-lwops-deployer/deploy.lock
```

4. **检查是否有僵尸进程**：

• Confidence: 85% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The README documents running the container with --privileged and mounting /sys/fs/cgroup with read-write access under cgroup v2, but does not provide a strong security warning about the host-compromise risk. In this context, these settings materially reduce container isolation and can enable container escape or broad host manipulation if the image is compromised or misbehaves.

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

### 容器配置

- **容器名称**: `lwops_rocky8_image_8.1`
- **启动参数**: `--privileged`（特权模式）
- **cgroup 挂载**: `/sys/fs/cgroup:/sys/fs/cgroup:ro`（v1）或 `:rw`（v2）
- **启动命令**: `/usr/sbin/init`

• Confidence: 99% confidence
• Finding: The README explicitly documents running the service container with --privileged. In a deployment skill pulling remote images, this is especially dangerous because it grants the container near-host-level access and greatly increases the consequences of a malicious or compromised image.

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

**解决方案**:
1. 检查 Docker 日志：`sudo docker logs lwops_rocky8_image_8.1`
2. 检查 cgroup 版本兼容性
3. 确保使用 `--privileged` 参数

### 问题 4：无法访问容器服务

• Confidence: 96% confidence
• Finding: The troubleshooting guidance tells users to ensure --privileged is used, reinforcing an insecure deployment pattern instead of minimizing privileges. This normalizes a high-risk configuration and can lead users to weaken isolation unnecessarily to make the container work.

Chaining Abuse

High

• Category: Tool Misuse

Content

**解决方案**:
1. 使用 sudo 运行命令
2. 将用户添加到 sudo 组：`sudo usermod -aG sudo $USER`
3. 配置 sudo 无密码：`echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USER`

## 📚 相关文档

• Confidence: 99% confidence
• Finding: The piped command writes a NOPASSWD sudoers rule, combining shell piping with privileged file modification to establish durable elevated access. This is not just documentation of admin behavior; it is a direct instruction to weaken privilege boundaries in a way that could be abused by any later code execution under that user account.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The skill appears to act mainly as a wrapper around another script while presenting itself as a transparent one-click Docker deployment tool. That indirection reduces auditability and can conceal privileged or destructive operations from users, making trust decisions based on the README unsafe.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The skill appears to act mainly as a wrapper around another script while presenting itself as a transparent one-click Docker deployment tool. That indirection reduces auditability and can conceal privileged or destructive operations from users, making trust decisions based on the README unsafe.

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

### 容器配置

- **容器名称**：`lwops_rocky8_image_8.1`
- **启动参数**：`--privileged`（特权模式）
- **cgroup 挂载**：`/sys/fs/cgroup:/sys/fs/cgroup:ro`（v1）或 `:rw`（v2）
- **启动命令**：`/usr/sbin/init`

• Confidence: 98% confidence
• Finding: The skill specifies running the container with --privileged, which grants broad device and kernel-interface access and sharply reduces Docker isolation. Combined with cgroup mounting and an externally sourced image, this can expose the host to container escape, persistence, or full-system compromise if the container is malicious or exploited.

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

**解决方案**：
1. 检查 Docker 日志：`docker logs lwops_rocky8_image_8.1`
2. 检查 cgroup 版本兼容性
3. 确保使用 `--privileged` 参数

### 问题 4：无法访问容器服务

• Confidence: 96% confidence
• Finding: The troubleshooting guidance tells users to ensure --privileged is used, normalizing an unsafe configuration as the default fix. This increases the chance that users deploy an overprivileged container even when a narrower, safer configuration might work, amplifying host-compromise risk.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

if ! acquire_lock_with_timeout 300; then
        local suggestions='[
            "检查是否有僵尸进程占用锁",
            "手动删除锁文件: rm -f /tmp/docker-lwops-deployer/deploy.lock",
            "等待几分钟后重试"
        ]'
        output_error "LockTimeout" "获取部署锁超时，可能存在死锁" "$suggestions"

• Confidence: 95% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Chaining Abuse

High

• Category: Tool Misuse

Content

output_progress "检查权限..."

    if ! require_root; then
        local suggestions='["使用 sudo 运行此脚本", "将用户添加到 sudo 组: sudo usermod -aG sudo \$USER", "配置 sudo 无密码: echo \"\$USER ALL=(ALL) NOPASSWD: ALL\" | sudo tee /etc/sudoers.d/\$USER"]'
        output_error "PermissionDenied" "需要 sudo 权限来安装和管理 Docker" "$suggestions"
        exit 1
    fi

• Confidence: 96% confidence
• Finding: The script recommends piping a sudoers rule into 'sudo tee' to grant the current user passwordless root access for all commands. This is a classic privilege-expansion pattern that can permanently lower system security and greatly increase the blast radius of any later account compromise.

Credential Access

High

• Category: Privilege Escalation

Content

}

    # 添加 Docker 官方 GPG 密钥
    sudo mkdir -p /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg || {
        echo "无法添加 Docker GPG 密钥"
        return 1

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

}

    # 添加 Docker 官方 GPG 密钥
    sudo mkdir -p /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg || {
        echo "无法添加 Docker GPG 密钥"
        return 1

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

}

    # 添加 Docker 官方 GPG 密钥
    sudo mkdir -p /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg || {
        echo "无法添加 Docker GPG 密钥"
        return 1

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Chaining Abuse

High

• Category: Tool Misuse

Content

# 添加 Docker 官方 GPG 密钥
    sudo mkdir -p /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg || {
        echo "无法添加 Docker GPG 密钥"
        return 1
    }

• Confidence: 86% confidence
• Finding: Piping network-fetched content directly into a privileged command bypasses an opportunity to validate the downloaded material before it affects system trust configuration. In this context the content becomes a repository signing key, so compromise of the source or transport could enable installation of attacker-controlled packages later.

Chaining Abuse

High

• Category: Tool Misuse

Content

# 设置 Docker 仓库
    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null || {
        echo "无法设置 Docker 仓库"
        return 1
    }

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

echo "正在为 Arch Linux 系统安装 Docker..."

    # 安装 Docker
    sudo pacman -S --noconfirm docker || {
        echo "无法安装 Docker"
        return 1
    }

• Confidence: 85% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

# 启动容器
    if sudo docker run -d \
        --name "$container_name" \
        --privileged \
        -p "${host_port1}:80" \
        -p "${host_port2}:8081" \
        --hostname "$container_name" \

• Confidence: 98% confidence
• Finding: The script launches the container with --privileged and additionally mounts /sys/fs/cgroup from the host, effectively collapsing many container isolation boundaries. In a deployment tool that may pull mutable remote images, this creates a realistic path to host compromise or container escape if the image is malicious or later becomes compromised.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation says the skill will automatically install Docker if absent, but does not clearly foreground that this performs privileged package installation and system-level changes. Users may invoke the skill without understanding it can modify repositories, packages, services, and daemon state on the host.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The uninstall section includes forceful deletion commands such as `docker rm -f`, `docker rmi`, and `rm -rf` without an explicit warning about data loss or irreversible removal. Users may destroy containers, images, and local skill files without realizing recovery may be difficult or impossible.

Static analysis

Detected: suspicious.destructive_delete_command

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

• Code: suspicious.destructive_delete_command
• Location: INSTALL.md:280