T06 · System Persistence
Error
- Location
- SKILL.md:24
- Finding
- Persistent System-Wide Xvfb Service Exceeds Minimum Required Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 24–37 **Vulnerability Type**: Persistent system service registration **Risk Level**: High ### Vulnerable Code ```bash sudo apt install -y xvfb sudo tee /etc/systemd/system/xvfb.service << 'EOF' [Unit] Description=X Virtual Frame Buffer After=network.target [Service] Type=simple ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24 Restart=always [Install] WantedBy=multi-user.target EOF sudo systemctl enable --now xvfb ``` ### Technical Analysis The Skill instructs the user to use `sudo` to create a root-owned systemd unit under `/etc/systemd/system` and then enable it at boot. The `WantedBy=multi-user.target` setting causes Xvfb to start in future boot sessions, while `Restart=always` causes systemd to relaunch the process whenever it exits. Xvfb is relevant to the declared Threads browser-automation functionality on a headless host. However, installing an always-running, system-wide boot service is not the least-privileged mechanism needed to provide a display for an individual browser session. A session-bound `xvfb-run` invocation, an explicitly managed process, a transient unit, or a user-scoped service would meet the functional requirement with less persistence and lower privileges. The behavior is disclosed in the documentation, and the package is installed from the operating system’s configured package repository. The audited content does not contain a hidden payload, malicious replacement binary, or remote code retrieval. The vulnerability is therefore the unnecessary persistent privileged configuration itself, rather than evidence that Xvfb is malicious. ### Attack Path 1. A user follows the headless-server setup instructions and grants `sudo` access. 2. The instructions install Xvfb and write a root-owned service definition to `/etc/systemd/system/xvfb.service`. 3. `sudo systemctl enable --now xvfb` immediately starts the service and registers it for execution on subsequent ...[truncated 1418 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Prefer a session-bound virtual display that terminates with the browser process: ```bash xvfb-run -a openclaw gateway ``` Adapt the invocation to the actual OpenClaw startup command rather than registering a boot service. 2. If separate lifecycle management is required, use a user-scoped or transient service instead of writing to `/etc/systemd/system`. Do not enable it at boot unless continuous operation is explicitly requested by the user. 3. Avoid `Restart=always` for an optional browser dependency. If restart behavior is necessary, use a bounded policy such as `Restart=on-failure` with start-rate limits. 4. Clearly separate the optional headless-host setup from ordinary Skill usage and obtain explicit user approval before making persistent or privileged system changes. 5. Provide complete rollback instructions for systems where the service was installed: ```bash sudo systemctl disable --now xvfb sudo rm -f /etc/systemd/system/xvfb.service sudo systemctl daemon-reload sudo systemctl reset-failed ``` 6. Also document removal of the related user-level OpenClaw Gateway display override when it is no longer needed: ```bash rm -f ~/.config/systemd/user/openclaw-gateway.service.d/display.conf systemctl --user daemon-reload systemctl --user restart openclaw-gateway ``` 7. If persistent deployment remains supported, document the security boundary, service lifetime, fixed-display implications, package source assumptions, and exact cleanup procedure. ]]>