fix: remove no-new-privileges to allow sudo apt/dpkg

[hermclaw]

Summary

• Remove --security-opt no-new-privileges:true from the docker run invocation in src/harness.ts
• Update tests, README, and docs to reflect the change

Problem

The no-new-privileges flag prevents sudo from gaining elevated capabilities, even for commands listed in /etc/sudoers.d/harness (apt-get, apt, dpkg). This makes the sudoers configuration useless — agents can't install packages inside the container.

Root Cause

no-new-privileges:true is a Linux kernel feature that sets the PR_SET_NO_NEW_PRIVS bit, which prevents execve() from granting new privileges (including those from setuid binaries like sudo). This is incompatible with the sudoers-based package installation pattern.

Fix

Remove the no-new-privileges:true security-opt. The remaining sandboxing is still strong:

• --cap-drop=ALL --cap-add=NET_RAW — minimal capability set, drops all Linux capabilities except raw socket
• Seccomp profile — blocks socket(AF_ALG) to prevent kernel crypto API access (known container escape vector)
• User isolation — container runs as unprivileged harness user, only sees the mounted workspace

Test Plan

• All 94 e2e tests pass
• Build succeeds
• Biome lint passes on changed files

Closes #89

[hggz]

Reviewed the security tradeoff here — the diagnosis is correct and the fix is the right call, with one nuance worth recording for posterity.

The fix is sound. no-new-privileges:true sets PR_SET_NO_NEW_PRIVS, which makes execve() ignore the setuid bit. Since sudo is setuid-root, the two are fundamentally incompatible — there is no way to keep no-new-privileges and have the documented /etc/sudoers.d/harness apt/dpkg pattern work. So if sudo-based package installs are a supported workflow (#89), this flag has to go. The root-cause writeup is accurate.

One nuance for the security doc. Worth being explicit that the remaining seccomp profile (block-af-alg.json) is defaultAction: SCMP_ACT_ALLOW — it replaces Docker's default deny-by-default profile and only blocks AF_ALG socket(). So in this image no-new-privileges was carrying more weight than it would in a default-seccomp container: it was the main thing stopping a setuid path from reaching euid 0. After this change the load-bearing control becomes --cap-drop=ALL (bounding set = {NET_RAW}), which does still cap what a sudo→euid-0 process can actually do (apt can write root-owned /usr /var because the owner matches, but the empty-ish bounding set blocks capability-gated escalation). That containment is real, but I'd suggest docs/security.md call out cap-drop as the primary sandbox now, rather than leaning on "seccomp hardening" as the headline — the seccomp profile is intentionally narrow.

Non-blocking, and not mine to merge — leaving this as a comment for @capotej to make the final call as codeowner. Tests + lint look good and the docs/README updates match the code change.