bug(sandbox): child processes cannot add restrictive seccomp filters

[SidShaytay]

User Story

I use OpenShell v0.1.2 on Fedora for coding agents in Podman containers and microVMs. I need guest Chromium to test project apps with its own sandbox enabled alongside OpenShell confinement.

Problem Statement

OpenShell blocks seccomp(SECCOMP_SET_MODE_FILTER), so child processes cannot use this interface to add security restrictions beyond those established for the initial process spawned by OpenShell.

Linux normally allows this stacking: a child can add restrictions, but it cannot remove the inherited restrictions. The source comment describes the operation as replacing the active filter, whereas Linux stacks filters.

Source: https://github.com/NVIDIA/OpenShell/blob/v0.1.2/crates/openshell-sandbox/src/sandbox/linux/seccomp.rs#L263-L272
Kernel semantics: https://docs.kernel.org/userspace-api/seccomp_filter.html

Impact / Why This Matters

This obstructs application-level sandboxing and pressures users to disable browser defenses or move browsing to a host browser with broader access. Restrictive filter stacking should let applications retain their own defenses inside OpenShell.

Chromium’s user-namespace requirements are a separate compatibility concern; fixing this restriction alone does not establish complete browser compatibility. Related broader issue: #1039.

Acceptance Criteria

• A child can install an additional restrictive seccomp filter through a supported interface.
• Inherited syscall denials, filesystem controls, network policy and no_new_privs remain enforced.
• Child filters cannot take over OpenShell’s network notification handling; regression tests cover this boundary.
• Documentation distinguishes filter stacking from separate namespace requirements.

Reproduction Steps

Source-based finding; an isolated live syscall reproduction has not yet been attached.

1. Review v0.1.2 build_filter_rules() at the source link above: it returns EPERM for seccomp operation SECCOMP_SET_MODE_FILTER, regardless of filter contents.
2. In an OpenShell-launched child with no_new_privs enabled, attempt to install a valid additional filter using that syscall.
3. Expected: the additional filter is installed while inherited restrictions remain active. The current rule instead rejects the call.

Notification-based mediation requires separate safety analysis; this is not a request to permit unrestricted notification listeners.

Suggested UX (if applicable)

No specific new configuration or CLI is requested. Legitimate child filter installation should work through a documented, supported path without disabling OpenShell confinement.

Environment

• OpenShell: v0.1.2
• Host: Fedora 44 Silverblue, Linux x86_64
• Runtimes: rootless Podman and microVM
• Evidence: source review of v0.1.2; no isolated syscall reproduction claimed.

Logs

[aetherxeg-source]

The security invariant here is:

"additional restriction != authority to weaken inherited restriction"

Seccomp stacking has a useful monotonicity property: a child adding a filter should only reduce its effective syscall set.

If OpenShell supports this, the verification point should test the resulting authority rather than only the presence of "SECCOMP_SET_MODE_FILTER".

A regression could:

1. establish outer filter F0;
2. have the child install restrictive F1;
3. verify a syscall denied by F0 remains denied;
4. verify a syscall newly denied by F1 is denied;
5. attempt notification/listener configurations that could interfere with OpenShell mediation and reject unsupported variants explicitly.

The desired relation is:

"effective_authority(F0 + F1) ⊆ effective_authority(F0)"

That makes the compatibility concession measurable without weakening the original confinement claim.

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