<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=624259) </details> <!--IssueSummary end--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=624259) </details> ## Rollout issue for `duo_workflow_nono_sandbox` This issue tracks the rollout of the `duo_workflow_nono_sandbox` feature flag, which enables the nono (Landlock-based) sandbox for Duo Agent Platform ambient flow execution. **Feature issue:** https://gitlab.com/gitlab-org/gitlab/-/issues/605838 **MR:** https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331 ### Prerequisites from AppSec review AppSec raised the following in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331#note_3760245705. These should be resolved before the flag is enabled beyond internal test projects, because each one affects whether the sandbox is a real security boundary rather than a best-effort one. - [x] **Fail closed when the sandbox binary is missing.** ~~Today, if `nono` is not on PATH the command runs unsandboxed with only a warning.~~ **Updated 2026-09-17:** this is now done for the nono path - `wrap_command_nono` `exit 1`s both when `nono` is absent from PATH and when the pre-check fails (https://gitlab.com/gitlab-org/gitlab/-/commit/c29f17d1d1edf2124b863a44e15da410a2b9506f, at AppSec's request in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331#note_3812424596; the earlier 4d9860ff added the pre-check as fail-open). The `srt` path still runs unsandboxed with only a warning. What remains open here is the *install* half - where the binary comes from and whether it can be trusted - which is now split out into the substitution blocker below. Adopt the pattern used for `glab` in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/226948: use an embedded version, or install at a pinned version with a checksum or signature check, and fail closed if the install or a sandbox self-check fails. Provide an explicit opt-out (for example `SKIP_SANDBOX`) set by instance or runner config for customers where this breaks. Note that installing via `setup_script` is not sufficient, since `setup_script` is project-controlled and a project could skip or swap the sandbox it is meant to run inside. Tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/624831. - [ ] **Landlock is unavailable on GitLab.com hosted Linux runners. Hard blocker on enabling the flag for any project using them.** Confirmed 2026-09-23 with a `setup_script` probe on `saas-linux-small-amd64` (https://gitlab.com/gitlab-org/duo-workflow/test-project-playground/aherczeg/-/jobs/16682036255 is the failing run). The Container-Optimized OS host kernel (`5.15.154+`) is built without Landlock: `/proc/config.gz` has `# CONFIG_SECURITY_LANDLOCK is not set`, `landlock` is absent from `/sys/kernel/security/lsm`, and `landlock_create_ruleset` returns `ENOSYS`. Seccomp is `0` (privileged), so it is not a filter. The nono pre-check therefore fails and every flow exits 1. No image, `agent-config.yml` or Rails change can fix this; it needs a host kernel with `CONFIG_SECURITY_LANDLOCK=y`. Earlier successes were all on Ubuntu 6.x kernels (Colima, GDK), which ship Landlock enabled. Until resolved, nono is only viable on self-managed or private runners, and SRT remains the only working sandbox on hosted runners. Runner team issue: TBD. - [ ] **Customer-facing opt-out before default enablement. Hard blocker on default enablement.** The nono path now fails closed, and its only opt-out today is the `duo_workflow_nono_sandbox` flag itself, which is project-actor-scoped and set by GitLab staff (or the instance admin on self-managed). A project or runner owner cannot opt out. AppSec accepted fail-closed with an opt-out "if needed" (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331#note_3812424596); once nono is the default, a job whose image or kernel cannot run it exits 1 and nothing short of the flag unblocks it. Needs the explicit instance- or runner-level opt-out (for example `SKIP_SANDBOX`) described in the item above and https://gitlab.com/gitlab-org/gitlab/-/work_items/624831. Split out because that requirement previously sat only inside a ticked item. - [ ] **Build a sandbox enforcement test framework.** No test anywhere currently confirms that a sandbox enforces the policy it is given; existing coverage only asserts on generated shell strings and config JSON, so `srt` enforcement has never been verified either. Run a probe corpus (read `~/.ssh`, write outside the workspace, reach a non-allowlisted domain, and the allowed-case counterparts) against both `srt` and `nono` and confirm nono behaves the same or better. Tracked in https://gitlab.com/gitlab-org/duo-workflow/default-docker-image/-/work_items/21. - [x] **Fail closed on an empty egress allowlist.** nono only switches to default-deny once at least one `--allow-domain` is passed, so an empty computed allowlist would have run with unrestricted egress and no proxy. This differs from `srt`, which treats an empty `allowedDomains` as "allow nothing". Fixed in https://gitlab.com/gitlab-org/gitlab/-/commit/18b6a582876f211290b06d6cbcb9176382cfd309: `wrap_command_nono` now errors and exits when the allowlist is empty. - [ ] **Confirm non-HTTP egress behaviour under nono.** Not verifiable from the Rails side; depends on nono runtime behaviour. Should be established by the probe corpus above. - [ ] **Confirm RFC1918 handling.** nono reportedly allows private address ranges by default, which may differ from `srt`. This is a potentially meaningful gap for internal network reachability and should be pinned down before broad rollout. - [ ] **Honour or retire `allow_all_unix_sockets` under nono. Hard blocker on default enablement.** Raised by `@romaneisner` in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331#note_3832857696. `computed_domains` translates the network policy only, so this setting is silently inert on the nono path. The drift is very likely a **loosening, not a tightening**: Landlock's network rules cover TCP bind/connect only, so nothing in the nono policy restricts Unix sockets, and the setting's restrictive default (`false`) stops being honoured. The setting has been GA since 18.11 and is documented as a security control with an explicit warning, so this silently breaks a documented promise for every project once the flag is on. **Evidence added 2026-09-17:** a real job trace reports `kernel Landlock V4 - degraded: IoctlDev, Scoping`. Landlock *scoping* is the mechanism that covers abstract-namespace Unix sockets, and it is unavailable on this kernel - so abstract Unix socket IPC is unrestricted there regardless of what the setting says. That is the first concrete datapoint for what was previously a "very likely" claim. It does not settle filesystem-bound sockets, which the probe corpus still needs to cover. The unix-socket arm of the escape tests was never run (only the mount and process-subtree arms were), and the "confirm non-HTTP egress behaviour" item above will not cover it, since Unix sockets are local IPC rather than egress. Add a unix-socket probe to https://gitlab.com/gitlab-org/duo-workflow/default-docker-image/-/work_items/21. The decision owed before default-on is map-it-or-deprecate-it: the toggle is currently exposed through the admin and group AI settings UI, the GraphQL `DuoSettings` type and mutation, the REST `Ai::Settings` entity, `Ai::DuoSettings::ChangesAuditor`, and `duo_agent_config.json`, so retiring it is not a one-line change either. - [ ] **Use a platform-provided nono binary the project cannot substitute. Hard blocker on default enablement.** Raised by `@mkozono` in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252331#note_3819039833 and deferred at the time without being recorded anywhere that could gate the flag. **Distinct from the "binary is missing" item above:** this is the present-but-hostile case. The job is built as one ordered script, so the project's `setup_script` runs before the sandbox block *in the same shell*, and both `command -v nono` and the `nono run` invocations resolve through `PATH`. A project-supplied binary that exits 0 on the `-- true` pre-check and then execs the command unsandboxed satisfies every check the Rails side makes. Observed in a real trace: the job script itself runs `export PATH="$HOME/.local/bin:$PATH"` and `export PATH="/tmp/bin:$PATH"` immediately before the sandbox block. Fix is to invoke nono by an absolute path the image owns; it cannot be done from Rails alone. The unpinned `curl -fsSL https://nono.sh/install.sh | sh` currently used for testing is acceptable only until this lands. - [ ] **Reject nono below v0.74.0. Hard blocker on default enablement.** Releases before [v0.74.0](https://github.com/nolabs-ai/nono/releases/tag/v0.74.0) carry a demonstrated domain-allowlist bypass, and the pre-check exercises no network so it cannot detect it. The evaluation in https://gitlab.com/gitlab-org/gitlab/-/work_items/605838 was done against 0.71.0; a 2026-09-17 trace ran 0.78.0, unpinned. A version floor is only meaningful once the binary itself is trusted, so this pairs with the item above. - [ ] **Decide on `--strict-broker-path` after enumerating the writable `PATH` entries.** A real trace warns `4 PATH entries sandbox-writable (-v to show, --strict-broker-path to fail closed)`. `/tmp` is granted `r+w` (it carries `TMPDIR`, the npm cache and `GITLAB_LSP_STORAGE_DIR`) and `/tmp/bin` is prepended to `PATH` by the glab install step, so the agent can write a binary into a directory it will then execute from. Run `nono run -v` with the real policy to list the four before deciding: if they are all legitimate, passing `--strict-broker-path` fails every job closed and the fix belongs in the image rather than in the emitted flags. Pair with https://gitlab.com/gitlab-org/duo-workflow/default-docker-image/-/work_items/21. - [ ] **Fix sandbox-provider telemetry before rolling out.** duo-cli logs `[SandboxAvailability] Sandbox available: platform=linux, provider=srt, version=unknown` while the process is demonstrably running under nono. Every nono job will be recorded as SRT, which makes the rollout unreadable: regressions cannot be attributed to the flag, and the "monitor for regressions" step below has no usable signal. Needs an issue in the CLI/LSP repo, linked back here. ### Rollout plan 1. Enable for internal test projects whose executor image is confirmed to ship `nono` (a missing binary now fails every ambient job with `exit 1`) 2. Monitor for regressions 3. Enable broadly on GitLab.com 4. Remove flag after successful rollout