#8567: fix: Sandbox browser runs Chromium as root with --no-sandbox

## Fix Summary The sandbox browser image launches Chromium with `--no-sandbox` and does not drop root privileges. This disables Chromium’s security sandbox while running as root, materially weakening the browser’s isolation boundary; if a browser exploit occurs, the impact is significantly worse. Because sandbox containers mount agent workspaces, this increases the risk of workspace tampering and broader compromise of the OpenClaw runtime. ## Issue Linkage Fixes #8566 ## Security Snapshot - CVSS v3.1: 9.6 (Critical) - CVSS v4.0: 9.4 (Critical) ## Implementation Details ### Files Changed - `Dockerfile.sandbox-browser` (+4/-0) - `scripts/sandbox-browser-entrypoint.sh` (+0/-1) ### Technical Analysis The sandbox browser image launches Chromium with `--no-sandbox` and does not drop root privileges. This disables Chromium’s security sandbox while running as root, materially weakening the browser’s isolation boundary; if a browser exploit occurs, the impact is significantly worse. Because sandbox containers mount agent workspaces, this increases the risk of workspace tampering and broader compromise of the OpenClaw runtime. ## Validation Evidence - Command: `--no-sandbox` - Status: failed ## Risk and Compatibility non-breaking; compatibility impact was not explicitly documented in the original PR body. ## AI-Assisted Disclosure AI-assisted: Codex CLI This fix was generated with AI assistance (Codex CLI). <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR hardens the sandbox-browser container by creating a dedicated non-root user and switching the image to run as that user, and by removing Chromium’s `--no-sandbox` flag so Chromium’s internal sandbox can be used. Changes are confined to the sandbox browser image (`Dockerfile.sandbox-browser`) and its entrypoint (`scripts/sandbox-browser-entrypoint.sh`), which is responsible for starting Xvfb/Chromium and exposing the CDP/VNC/noVNC ports. <h3>Confidence Score: 3/5</h3> - Reasonably safe security hardening, but there is a realistic runtime permission/config risk with the new non-root user setup. - The security intent is sound (drop root, re-enable Chromium sandbox) and the diff is small, but the entrypoint still writes to a fixed HOME under `/tmp`, which may not be writable/owned by the unprivileged user in all runtimes and could cause Chromium startup failures. CI/test status isn’t verifiable here due to missing `pnpm` in the review environment. - scripts/sandbox-browser-entrypoint.sh (HOME/permissions assumptions), Dockerfile.sandbox-browser (user creation assumptions) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->