bug(sandbox): GNU Make cannot launch recipes with unchanged UID/GID

[drew]

User Story

I need coding agents in OpenShell sandboxes to run GNU Make builds. The Ubuntu 24.04 reproduction below fails even for a recipe that only runs true.

Problem Statement

GNU Make cannot launch ordinary recipes in a non-root OpenShell sandbox. It reports Operation not permitted for the recipe command, although running that command directly succeeds. The reported reproduction uses OpenShell 0.1.2 sandbox and supervisor images with a gateway built from the current checkout.

The child seccomp filter unconditionally denies setresuid and setresgid. Make calls these before executing a recipe to reset its effective IDs to its existing real IDs. For a workload whose real, effective, and saved IDs already match, these calls preserve its identity.

Impact / Why This Matters

Coding agents cannot build Make-based projects in affected sandboxes. Patching the runtime locally is a possible workaround, but maintaining a custom runtime for a standard build tool is insufficient.

Acceptance Criteria

• The minimal Make recipe succeeds at workload startup and through openshell sandbox exec as a non-root user.
• Identity-preserving setresuid and setresgid calls succeed when each argument is the established workload ID or the unchanged sentinel.
• Attempts to select another real, effective, or saved UID/GID remain denied, including root.
• Changing supplementary groups remains denied.

Reproduction Steps

1. Build a workload image from this Dockerfile:

   FROM ubuntu:24.04
   RUN apt-get update && apt-get install -y make python3 \
       && useradd -u 10001 -m sandbox
   WORKDIR /sandbox
   USER sandbox

2. Create a persistent sandbox on a Docker-backed OpenShell gateway:

   openshell sandbox create --from openshell/make-repro:ubuntu24-user10001 --name make-repro --detach

3. Run the minimal recipe:

   openshell sandbox exec --name make-repro --no-tty -- sh -c 'id; /usr/bin/true; printf "all: ; @true\n" > /tmp/Makefile; make -f /tmp/Makefile'

Environment

• Sandbox and supervisor runtime: OpenShell 0.1.2
• Workload: Ubuntu 24.04, GNU Make, non-root UID 10001
• Compute driver: Docker
• Gateway in the reported reproduction: current checkout, 0.1.3-dev

Logs

make: true: Operation not permitted
make: *** [/tmp/Makefile:1: all] Error 127
make status: 2

[aetherxeg-source]

A useful sandbox-policy distinction here is:

"credential syscall requested != credential authority increased"

An identity-preserving "setresuid/setresgid" call and an identity-changing call use the same syscall but have different security semantics.

Rather than treating syscall identity as the entire authorization decision, the policy could evaluate the requested transition:

"current credentials + requested credentials -> effective identity transition"

and allow only the no-op/identity-preserving subset.

The regression matrix should include every argument position independently:

• unchanged real/effective/saved ID;
• "-1" sentinel;
• transition to another non-root ID;
• transition to root;
• supplementary-group mutation.

The important invariant is:

"permitted syscall effect <= existing identity authority"

This preserves the security boundary while avoiding denial of software that performs defensive identity normalization without gaining privilege.

Related reference implementation / design work: AETHER X GLOBAL ExecSurface — https://github.com/AETHERXGLOBAL/execsurface