Skip to content

thirdshift setup: check that Security sessions can sandbox target code on this machine #608

Closed

Description

@JacobStephens2

This was generated by AI during triage.

Problem

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?

Activity

  1. JacobStephens2 commented on Oct 10, 2026

    @JacobStephens2
    OwnerAuthor

    This was generated by AI during triage.

    Update: fixed on the thirdshift host (Ubuntu 24.04). Two steps were needed after apt install bubblewrap:

    1. 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>
      }
      
    2. 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.

  2. JacobStephens2 commented on Oct 21, 2026

    @JacobStephens2
    OwnerAuthor

    This was generated by AI during triage.

    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. 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.

    Out of scope:

  3. added
    ready-for-agentFully specified, ready for an AFK agent
    in-progressA Claim: thirdshift has taken this issue
    and removed
    needs-triageMaintainer needs to evaluate this issue
    ready-for-agentFully specified, ready for an AFK agent
    on Oct 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions