bug(sandbox): namespace hardening prevents Chromium's guest sandbox from starting

[SidShaytay]

User Story

I use OpenShell v0.1.2 on Fedora 44 Silverblue for coding agents in rootless Podman containers and microVMs. I want agents to test project apps with Chromium inside the guest, keeping Chromium's own sandbox and OpenShell's filesystem/network confinement enabled.

Problem Statement

Chromium cannot establish its namespace sandbox under the current workload restrictions. In disposable OpenShell guests, unshare -Ur fails with Operation not permitted in both runtimes. Sandbox-enabled browser startup also failed; the microVM diagnostic was summarized as "No usable sandbox" in our investigation notes, but that browser stderr was not retained as a raw log.

The v0.1.2 source blocks CLONE_NEWUSER through clone/unshare. The child-hardening filter additionally denies unshare, namespace-bearing clone, setns, chroot, and credential-changing operations. These are deliberate hardening rules; this report requests a supported compatibility path, not blanket removal of those protections.

• Baseline filter
• Child hardening

Impact / Why This Matters

Guest browser testing is blocked unless users disable browser sandbox protections or introduce a separate browser boundary with additional state management and network enforcement. We want to preserve defense in depth and keep browser traffic governed by OpenShell.

Acceptance Criteria

• A documented, supported guest-browser workflow starts Chromium with its own namespace and seccomp sandbox layers enabled, verified through chrome://sandbox.
• OpenShell filesystem restrictions, destination policy, supervisor protection, capability limits and no_new_privs remain enforced.
• Regression tests cover the supported container and microVM paths, including attempts to escape the intended boundary.
• Unsupported runtime combinations fail clearly; no automatic fallback to --no-sandbox.

Reproduction Steps

In an existing OpenShell v0.1.2 sandbox with util-linux already present:

openshell --gateway podman sandbox exec --name <sandbox-name> -- unshare -Ur true
openshell --gateway vm sandbox exec --name <sandbox-name> -- unshare -Ur true

Both return unshare: unshare failed: Operation not permitted. These probes demonstrate the namespace restriction, not a complete browser reproduction. Our browser image has pinned Playwright CLI 0.1.22 and its matching Chromium, with chromiumSandbox:true. Launching sandbox-enabled Chromium in either OpenShell runtime failed; a separate network-disabled rootless Podman test of the same image succeeded with Chromium's namespace and seccomp protections enabled.

Environment

• OpenShell: v0.1.2
• Host: Fedora 44 Silverblue, Linux x86_64
• OpenShell runtimes tested: rootless Podman and microVM
• Guest image: Ubuntu 24.04-based; Playwright CLI 0.1.22; Chromium revision 1247

Logs

Saved test output excerpts, 2026-10-01 (host paths and unrelated tool output omitted):

Runtime: podman
Session: osh-browser-6a97d3
Created sandbox: osh-browser-6a97d3
{"browser":{"browserName":"chromium","launchOptions":{"executablePath":"/opt/playwright-browsers/chromium-1247/chrome-linux64/chrome","chromiumSandbox":true,"args":["--disable-dev-shm-usage"]}}}
unshare: unshare failed: Operation not permitted

Runtime: vm
Session: osh-browser-14ed04
Created sandbox: osh-browser-14ed04
{"browser":{"browserName":"chromium","launchOptions":{"executablePath":"/opt/playwright-browsers/chromium-1247/chrome-linux64/chrome","chromiumSandbox":true,"args":["--disable-dev-shm-usage"]}}}
unshare: unshare failed: Operation not permitted

Related Issues

#4097 covers the separate seccomp(SECCOMP_SET_MODE_FILTER) restriction. This is not a blanket ban on additional filters: our investigation recorded successful stacking through prctl(PR_SET_SECCOMP).

#1039 covers desktop/browser harnesses broadly and was closed as completed. We could not find a closing implementation reference demonstrating this particular guest Chromium workflow. #982 concerns outer Kubernetes user namespaces and explicitly retains the nested CLONE_NEWUSER block; it does not resolve this case.

[aetherxeg-source]

The compatibility boundary here should distinguish:

"nested sandbox creation != escape from outer sandbox"

A child namespace can reduce or rearrange its own authority without necessarily weakening the confinement inherited from OpenShell.

I would define the supported browser path in terms of preserved outer invariants, not syscall names alone:

"outer filesystem authority"

• "outer network authority"
• "capability ceiling"
• "no_new_privs"
• "supervisor protection"

must remain unchanged after the nested browser sandbox initializes.

A useful conformance test would capture these properties before Chromium startup, allow the supported namespace operations, and recapture them afterward.

Then add negative controls attempting to exceed each boundary.

The success criterion should therefore be:

"nested isolation established AND outer authority not expanded"

rather than simply “unshare succeeded.”

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