You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
thirdshift setup: check that Security sessions can sandbox target code on this machine #608
The thirdshift-security-audit skill won't execute target code unless OS-enforced isolation is available: no external network, a scratch-only writable area, a dummy HOME and so on ("If every control cannot be enforced, do not execute target code"). When the host can't provide that, every Security review that needs a proof-of-concept ends incomplete, and every Security run will presumably hit the same limit. Nothing tells the operator this before a Run fails.
This happened on the thirdshift host for #596 / PR #605 (see #607 for the misleading Cause text). The host is Ubuntu 24.04:
bwrap was not installed. bubblewrap 0.9.0 is now installed via apt.
kernel.apparmor_restrict_unprivileged_userns = 1 (Ubuntu's default since 23.10). unshare --user --map-root-user and unshare --net fail with Operation not permitted.
Even with bubblewrap installed, bwrap --unshare-user … fails with setting up uid map: Permission denied, and --unshare-all fails with loopback: Failed RTM_NEWADDR: Operation not permitted. Ubuntu 24.04 ships no AppArmor profile for /usr/bin/bwrap (later releases add one), so bwrap stays unusable until the operator adds a profile granting it userns, or relaxes the sysctl.
Request
thirdshift setup should check whether Security runs and Security reviews on this machine can actually sandbox target code, and say what is missing and how to fix it.
Open questions for triage
What exactly should the check probe? A real attempt (for example, bwrap --unshare-all --ro-bind / / true) is more trustworthy than looking for binaries, because the binary can exist and still fail, as it does here.
Which sandbox tools count? Only bwrap, or the skill's "equivalent platform capabilities" too (for example, macOS sandbox-exec)? What is the guidance on macOS?
Should the check only warn, or should it also offer to install or configure anything? Changing the AppArmor policy needs root and weakens a kernel hardening default, so printing the commands is probably safer than doing it.
Should it run only when Security is enabled in the User config, and should a Run's preflight also warn before spending a session?
Should the probe live next to the skill's own requirements, so the two can't drift apart?
Update: fixed on the thirdshift host (Ubuntu 24.04). Two steps were needed after apt install bubblewrap:
An AppArmor profile at /etc/apparmor.d/bwrap:
abi <abi/4.0>,
include <tunables/global>
profile bwrap /usr/bin/bwrap flags=(unconfined) {
userns,
include if exists <local/bwrap>
}
Loading it with sudo apparmor_parser -r /etc/apparmor.d/bwrap.
Result of the probe bwrap --unshare-all --die-with-parent --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp …:
runs (exit 0), with uid mapped;
no network (a curl to github.com fails);
the host home is read-only (touch gives Read-only file system);
the tmpfs /tmp is writable.
Installing the package alone was not enough, which supports making the setup check a real probe rather than a command -v bwrap. The same probe fits as a suggested check. Note that /sys/class/net inside still lists the host's interfaces because /sys is bind-mounted, so test network isolation by actually trying to connect, not by listing interfaces.
Category: enhancement Summary: Setup checks, by trying it, that Security sessions can sandbox target code on this machine
Current behavior:
The Security audit skill runs target code only inside OS-enforced isolation: no network, writes only to a scratch area, a throwaway HOME. If any control can't be enforced, it doesn't run target code, and reports the missing capability as a blocker. On Ubuntu 24.04, bubblewrap isn't installed by default. Even once installed, AppArmor's restriction on unprivileged user namespaces stops it until a profile grants it userns. Nothing warns the operator before a Security review or Security run ends incomplete. The thirdshift host needed bubblewrap installed and an AppArmor profile for /usr/bin/bwrap with userns, loaded with apparmor_parser -r; this issue's comments give the profile.
Desired behavior:
When the User config that Setup writes has security.review or security.fix on, Setup runs a sandbox probe on Linux and prints one result line. The probe starts a real bwrap sandbox and checks, by trying, that:
the sandbox starts;
a network connection from inside it fails;
the host home is read-only inside it;
a scratch directory is writable.
On failure, the line says which check failed. Setup then prints the commands that fix the usual causes, without running them or asking for root: installing bubblewrap, and the AppArmor profile above with its load command. Setup still writes the User config. With both settings off, no probe runs. On macOS, Setup says the probe isn't available there.
Key interfaces:
Setup's flow, after the answers that set security.review and security.fix.
The Security audit skill's list of isolation requirements. Keep the probe's checks and that list in one place, or test that they match, so they can't drift apart.
Acceptance criteria:
On a machine where bwrap works, Setup with security.review on prints a passing probe line.
With bwrap missing from PATH, or with a stand-in bwrap that fails, Setup names the failed check and prints the fix commands. It then finishes and writes the User config.
With both settings off, no probe runs.
The probe changes nothing on the host, needs no root, and finishes within seconds. It tests network isolation by connecting, not by listing interfaces.
Activity
JacobStephens2 commentedon Oct 10, 2026
Update: fixed on the
thirdshifthost (Ubuntu 24.04). Two steps were needed afterapt install bubblewrap:/etc/apparmor.d/bwrap:sudo apparmor_parser -r /etc/apparmor.d/bwrap.Result of the probe
bwrap --unshare-all --die-with-parent --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp …:touchgivesRead-only file system);/tmpis writable.Installing the package alone was not enough, which supports making the setup check a real probe rather than a
command -v bwrap. The same probe fits as a suggested check. Note that/sys/class/netinside still lists the host's interfaces because/sysis bind-mounted, so test network isolation by actually trying to connect, not by listing interfaces.JacobStephens2 commentedon Oct 21, 2026
Agent Brief
Category: enhancement
Summary: Setup checks, by trying it, that Security sessions can sandbox target code on this machine
Current behavior:
The Security audit skill runs target code only inside OS-enforced isolation: no network, writes only to a scratch area, a throwaway HOME. If any control can't be enforced, it doesn't run target code, and reports the missing capability as a blocker. On Ubuntu 24.04, bubblewrap isn't installed by default. Even once installed, AppArmor's restriction on unprivileged user namespaces stops it until a profile grants it
userns. Nothing warns the operator before a Security review or Security run ends incomplete. Thethirdshifthost needed bubblewrap installed and an AppArmor profile for/usr/bin/bwrapwithuserns, loaded withapparmor_parser -r; this issue's comments give the profile.Desired behavior:
When the User config that Setup writes has
security.revieworsecurity.fixon, Setup runs a sandbox probe on Linux and prints one result line. The probe starts a real bwrap sandbox and checks, by trying, that:On failure, the line says which check failed. Setup then prints the commands that fix the usual causes, without running them or asking for root: installing bubblewrap, and the AppArmor profile above with its load command. Setup still writes the User config. With both settings off, no probe runs. On macOS, Setup says the probe isn't available there.
Key interfaces:
security.reviewandsecurity.fix.Acceptance criteria:
security.reviewon prints a passing probe line.Out of scope:
thirdshift doctor(makethirdshift doctorwhich can be run to check the health / setup / proper configuration of thirdshift #905).