Problem
The security model relies on .devcontainer/ being mounted read-only inside the container, preventing a compromised process from injecting malicious mounts or commands into devcontainer.json that execute on the host during rebuild.
However, if someone adds --cap-add=SYS_ADMIN to runArgs, the container can remount .devcontainer/ read-write, defeating this protection. Nothing currently prevents this.
Proposed fix
Add a check_no_sys_admin() function to install.sh that runs before cmd_up and cmd_rebuild:
check_no_sys_admin() {
local workspace="${1:-.}"
local dc_json="$workspace/.devcontainer/devcontainer.json"
[[ -f "$dc_json" ]] || return 0
if jq -e \
'.runArgs[]? | select(test("SYS_ADMIN"))' \
"$dc_json" >/dev/null 2>&1; then
log_error "SYS_ADMIN capability detected in runArgs."
log_error "This defeats the read-only .devcontainer mount."
exit 1
fi
}
Then call it in cmd_up and cmd_rebuild after check_devcontainer_cli.
Already done in trailofbits/skills devcontainer-setup plugin.
Problem
The security model relies on
.devcontainer/being mounted read-only inside the container, preventing a compromised process from injecting malicious mounts or commands into devcontainer.json that execute on the host during rebuild.However, if someone adds
--cap-add=SYS_ADMINtorunArgs, the container can remount.devcontainer/read-write, defeating this protection. Nothing currently prevents this.Proposed fix
Add a
check_no_sys_admin()function to install.sh that runs beforecmd_upandcmd_rebuild:Then call it in
cmd_upandcmd_rebuildaftercheck_devcontainer_cli.Already done in
trailofbits/skillsdevcontainer-setup plugin.