apply-seccomp aborts on Ubuntu: AppArmor denies CAP_SYS_ADMIN to bwrap children, so no sandboxed command can run

[dorrogeray]

Summary

On Ubuntu hosts with the stock bwrap-userns-restrict AppArmor profile, apply-seccomp can never
obtain CAP_SYS_ADMIN, so it aborts and no sandboxed command can run at all — echo hi fails
exactly like anything else. The comment block in apply-seccomp.c anticipates this case and resolves
it with "the caller must supply CAP_SYS_ADMIN", but on Ubuntu the caller cannot supply it either.

This is reported downstream in anthropics/claude-code#43454 (open since 2026-04-04, 22 comments,
regression traced to Claude Code 2.1.92) and anthropics/claude-code#81799 (2.1.220, with an A/B
canary). There appears to be no issue for it in this repo, which is where a fix would land.

Every workaround circulating in those threads is a global AppArmor weakening, because the mechanism
has been mis-attributed. Details below.

Environment

• Ubuntu 25.10, kernel 6.17.0-41-generic
• bubblewrap 0.11.0, not setuid (mode 0755)
• kernel.apparmor_restrict_unprivileged_userns = 0, kernel.unprivileged_userns_clone = 1
• Launching process is unconfined, in the initial user namespace, with no inherited seccomp filter
  (Seccomp: 0, NoNewPrivs: 0)
• Stock /etc/apparmor.d/bwrap-userns-restrict and /etc/apparmor.d/unprivileged_userns

Symptom

apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied

Root cause

sandbox/linux-sandbox-utils.js composes the sandbox as "Stage 1: Outer bwrap … Stage 2:
apply-seccomp", with bwrapArgs.push(applySeccompCmd) — so apply-seccomp runs as bwrap's child.

vendor/seccomp-src/apply-seccomp.c (main, ~L687-699) documents the two attempts and the abort:

Two paths to get CAP_SYS_ADMIN for the unshare:
(a) The caller (bwrap) kept CAP_SYS_ADMIN in this user namespace via --cap-add. …
(b) We don't have the cap. Create a nested user namespace to get it …

Path (b) can itself fail on hosts where unprivileged user namespaces are gated by an LSM (Ubuntu
24.04's AppArmor restriction, for example) … In that case we abort: the caller must supply CAP_SYS_ADMIN.

Ubuntu strips capabilities from bwrap's children deliberately. From the shipped profile:

bwrap is allowed access to user namespaces and capabilities within the user namespace, but its
children do not have capabilities, blocking bwrap from being able to be used to arbitrarily
by-pass the user namespace restrictions.

Implemented as allow pix /** -> &bwrap//&unpriv_bwrap, where unpriv_bwrap carries
audit deny capability. (A sibling profile, unprivileged_userns, applies the same denial to
unconfined processes that create a user namespace, so the standalone path is covered too.)

Why path (a) is not available as an escape hatch either

• AppArmor mediates the capable() check per profile. A capability present in the kernel
  capability set is still refused, so having the caller pass --cap-add CAP_SYS_ADMIN does not help.
• In an AppArmor stack the effective permission is the intersection, and deny always wins. No
  profile attached to the helper can restore the capability, and local/* includes cannot override a
  deny in the parent profile.
• kernel.apparmor_restrict_unprivileged_userns is not the relevant knob — it governs whether
  userns creation is blocked, not the capability-stripping profile transition. It is already 0 on
  this host and the failure persists. Nearly every downstream comment points at this sysctl, which is
  why those threads never converged.

The misleading part

bwrap --unshare-user <cmd> succeeds standalone on the same host, because /usr/bin/bwrap has its
own profile granting allow capability. Only its children are stripped. So the host looks fully
capable of unprivileged userns work while apply-seccomp fails.

Confirmed workaround

Setting network.allowAllUnixSockets skips Stage 2 entirely; the capability is never requested and
the rest of the sandbox arms normally (filesystem allow/deny and --unshare-net isolation verified
working afterwards). The cost is exactly the feature that stage provides: Unix-socket filtering.

Approaches that do not work

Approach	Outcome
apparmor_restrict_unprivileged_userns=0	Already 0; wrong knob
flags=(unconfined) AppArmor profile on the helper	Stacked with the denying profile; deny wins
local/unpriv_bwrap / local/unprivileged_userns overrides	Cannot override a parent deny
setuid bwrap to obtain the capability	bubblewrap 0.11.2 (CVE-2026-41163) deprecates setuid, defaults -Dsupport_setuid=false, and plans removal
enableWeakerNestedSandbox: true	No effect
Substituting a pre-7f650392 apply-seccomp	Argv contract changed once the BPF filter was baked in; also discards io_uring blocking (7ee4ac60) and the USER_NOTIF observer (1640f71f, 5ce6b3e5)

Proposal

The code already falls back (a) → (b). A third step would turn a hard failure into graceful
degradation: when neither path yields the capability, apply the seccomp filter without the nested
PID/mount namespace — the pre-7ee4ac60 behaviour — and log that io_uring blocking and the violation
observer are unavailable, instead of die().

That keeps Unix-socket filtering working on every LSM-restricted host (i.e. all of Ubuntu 24.04+),
where today the entire sandbox refuses to start. If silently reducing isolation is undesirable,
gating it behind an explicit opt-in, or emitting a one-time warning, would still be a large
improvement over a total outage.

Related: anthropics/claude-code#44180 asks for Unix-socket filtering that does not depend on the
seccomp helper, which would address this from the other direction.

---

Diagnosed empirically on the affected host with Claude Code; every claim above was verified against
the running system or the source rather than inferred.

[snowgameschool]

Confirming this on one host: Ubuntu 24.04.4, kernel 6.8.0, Claude Code 2.1.212, kernel.apparmor_restrict_unprivileged_userns=1, with bwrap-userns-restrict enabled at /etc/apparmor.d/ and loaded (aa-status lists bwrap and unpriv_bwrap). Same error, on every Bash invocation I tried, with no payload output or side effect.

network.allowAllUnixSockets: true made Bash commands start executing, as reported here. Posting what I measured afterwards, because on this host the socket exposure was more concrete than I expected, and one configuration that narrowed it.

Five socket nodes under /run that I found visible after the workaround

Enumerated from inside the sandbox with ls, after applying the workaround:

/run/user/<uid>/bus
/run/user/<uid>/gnupg/S.gpg-agent
/run/systemd/notify
/run/dbus/system_bus_socket
/run/snapd.socket

This was an inventory of the /run paths relevant to the rule below, not an exhaustive inventory of filesystem socket paths elsewhere on the host. For scale, /proc/net/unix on the host had 83 pathname entries. I found no Docker, Podman, containerd or LXD socket in the inventory I checked, and SSH_AUTH_SOCK was unset.

/run/dbus/system_bus_socket is the host system-bus endpoint, through which clients may reach host services — including privileged ones — subject to D-Bus policy and service-specific authorization. /run/snapd.socket is snapd's host API when snapd is active. I did not want either endpoint reachable from the sandbox, and I did not test any API call through either, so I am reporting reachability rather than privilege. On this host snapd and snapd.socket were both inactive, which is why a host-side connect to /run/snapd.socket returned ECONNREFUSED rather than connecting; /run/dbus/system_bus_socket was live, with dbus-daemon listening.

Configuration tested on this host

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "allowAllUnixSockets": true },
    "filesystem": {
      "denyRead": ["/home/<user>", "/run"],
      "allowRead": ["/home/<user>/work", "/run/systemd/resolve/stub-resolv.conf"],
      "allowWrite": ["/home/<user>/work"]
    }
  }
}

Three things that cost me time:

• Denying only the directories I first enumerated was incomplete. My first attempt denied /run/user and /run/systemd; /run/dbus/system_bus_socket and /run/snapd.socket were still visible as srw-rw-rw- from inside. I then tested the broader /run deny above, which made pathname lookup fail for all five in my ls check.

• Adding /var/run broke the sandbox. It is a symlink to /run, and bwrap then fails with Can't mount tmpfs on /newroot/var/run: No such file or directory. Nothing ran at all — fail-closed, but total.

• Denying /run alone made /etc/resolv.conf unreadable. On this host it is a symlink to ../run/systemd/resolve/stub-resolv.conf, which is this host's configuration and a recommended systemd-resolved mode, so the deny takes the resolver config with it. The narrow allowRead above restores reading it. Worth checking what else lives in that directory on your host: on mine it also contains io.systemd.Resolve (mode srw-rw-rw-) and io.systemd.Resolve.Monitor, which is why I allowed the single file rather than the directory. With the file-level allow in place, an ls of that directory from inside the sandbox showed only stub-resolv.conf, so those two socket nodes remained absent from the sandbox's directory lookup.

  Note this fixes reading the resolver config, not name resolution as a whole — the sandbox's own network policy governs whether a lookup can complete, and that is separate from the filesystem deny. I did not untangle the two beyond confirming the file became readable again.

Measurements

I first checked these paths with ls, which only establishes that a pathname lookup failed. Since AF_UNIX pathname connection resolves through the VFS, ls returning ENOENT does not by itself establish that the socket is unreachable. So I ran an actual connect(2) probe with a positive control — a socket the script creates in the workspace, to show the probe itself works.

Host, outside the sandbox:

POSITIVE  workspace ctl.sock          -> CONNECTED
          /run/dbus/system_bus_socket -> CONNECTED
          /run/snapd.socket           -> ECONNREFUSED (111)
          /run/user/<uid>/bus         -> CONNECTED

Same script, same host, run inside the sandbox with the configuration above:

POSITIVE  workspace ctl.sock          -> CONNECTED
          /run/dbus/system_bus_socket -> ENOENT (2)
          /run/snapd.socket           -> ENOENT (2)
          /run/user/<uid>/bus         -> ENOENT (2)

The positive control connects in both, so a non-connection inside is a real syscall result rather than a broken probe. The only variable between the "visible as srw-rw-rw-" state above and this one was the denyRead value, so on this host the difference is attributable to that setting rather than to the sockets being absent from the namespace to begin with. Only these three paths received a connect(2) probe; the other two were checked with ls only.

Inherited descriptors, from /proc/self/fd symlink targets in the probe process:

fd 0 -> /dev/null
fd 1 -> (task output file)
fd 2 -> (task output file)
fd 3 -> /usr/bin/claude

None socket-backed, in that process at that moment.

The network namespace handle inside the sandbox differed from the host's (net:[4026532239] vs net:[4026531840]), so the probe process remained in a different network namespace. Linux scopes abstract AF_UNIX names by network namespace, so that prevents a fresh lookup of an abstract name bound only in the host namespace. It does not establish anything about egress filtering. denyRead provides no filesystem-path control over connection to a known abstract-socket address, because abstract addresses have no VFS pathname.

I also counted /proc/net/unix inside the sandbox and got zero pathname entries, but that file is network-namespace-specific, so I am not offering it as evidence of anything about the /run deny.

What this is and is not

This is a host-specific path-hiding configuration, not restored Unix-socket filtering. What I measured is that connect(2) through those three pathnames returns ENOENT. That does not cover:

• abstract-namespace sockets, if network isolation is ever absent or shared
• already-open or inherited descriptors — pathname masking does not revoke an existing open file description
• a descriptor received via SCM_RIGHTS over any socket that remains reachable
• a bind-mount or hard-link alias resolving to the same socket inode from outside the denied trees
• any socket path outside the denied trees

I also did not test general usability with /run denied beyond a workspace read and write plus the resolver-config check above. /run holds more than sockets, so a workflow needing other session state may need narrower rules than mine. I would rerun the inventory after host service or package changes.

One note on verification method

My first attempt at checking this was to ask the agent whether it could read a credential file. It declined before making any filesystem call, so no OS enforcement was exercised and the result said nothing about the boundary. What worked was placing a harmless file of random size in the same denied directory and asking for its byte count: the lookup succeeded on the host and returned ENOENT inside the sandbox. The connect(2) probe above came from the same lesson — the agent's willingness to attempt something is not the boundary being tested.

[snowgameschool]

Confirming this on one host: Ubuntu 24.04.4, kernel 6.8.0, Claude Code 2.1.212, kernel.apparmor_restrict_unprivileged_userns=1, with bwrap-userns-restrict enabled at /etc/apparmor.d/ and loaded (aa-status lists bwrap and unpriv_bwrap). Same error, on every Bash invocation I tried, with no payload output or side effect.

network.allowAllUnixSockets: true made Bash commands start executing, as reported here. Posting what I measured afterwards, because on this host the socket exposure was more concrete than I expected, and one configuration that narrowed it.

Five socket nodes under /run that I found visible after the workaround

Enumerated from inside the sandbox with ls, after applying the workaround:

/run/user/<uid>/bus
/run/user/<uid>/gnupg/S.gpg-agent
/run/systemd/notify
/run/dbus/system_bus_socket
/run/snapd.socket

This was an inventory of the /run paths relevant to the rule below, not an exhaustive inventory of filesystem socket paths elsewhere on the host. For scale, /proc/net/unix on the host had 83 pathname entries. I found no Docker, Podman, containerd or LXD socket in the inventory I checked, and SSH_AUTH_SOCK was unset.

/run/dbus/system_bus_socket is the host system-bus endpoint, through which clients may reach host services — including privileged ones — subject to D-Bus policy and service-specific authorization. /run/snapd.socket is snapd's host API when snapd is active. I did not want either endpoint reachable from the sandbox, and I did not test any API call through either, so I am reporting reachability rather than privilege. On this host snapd and snapd.socket were both inactive, which is why a host-side connect to /run/snapd.socket returned ECONNREFUSED rather than connecting; /run/dbus/system_bus_socket was live, with dbus-daemon listening.

Configuration tested on this host

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "allowAllUnixSockets": true },
    "filesystem": {
      "denyRead": ["/home/<user>", "/run"],
      "allowRead": ["/home/<user>/work", "/run/systemd/resolve/stub-resolv.conf"],
      "allowWrite": ["/home/<user>/work"]
    }
  }
}

Three things that cost me time:

• Denying only the directories I first enumerated was incomplete. My first attempt denied /run/user and /run/systemd; /run/dbus/system_bus_socket and /run/snapd.socket were still visible as srw-rw-rw- from inside. I then tested the broader /run deny above, which made pathname lookup fail for all five in my ls check.

• Adding /var/run broke the sandbox. It is a symlink to /run, and bwrap then fails with Can't mount tmpfs on /newroot/var/run: No such file or directory. Nothing ran at all — fail-closed, but total.

• Denying /run alone made /etc/resolv.conf unreadable. On this host it is a symlink to ../run/systemd/resolve/stub-resolv.conf, which is this host's configuration and a recommended systemd-resolved mode, so the deny takes the resolver config with it. The narrow allowRead above restores reading it. Worth checking what else lives in that directory on your host: on mine it also contains io.systemd.Resolve (mode srw-rw-rw-) and io.systemd.Resolve.Monitor, which is why I allowed the single file rather than the directory. With the file-level allow in place, an ls of that directory from inside the sandbox showed only stub-resolv.conf, so those two socket nodes remained absent from the sandbox's directory lookup.

  Note this fixes reading the resolver config, not name resolution as a whole — the sandbox's own network policy governs whether a lookup can complete, and that is separate from the filesystem deny. I did not untangle the two beyond confirming the file became readable again.

Measurements

I first checked these paths with ls, which only establishes that a pathname lookup failed. Since AF_UNIX pathname connection resolves through the VFS, ls returning ENOENT does not by itself establish that the socket is unreachable. So I ran an actual connect(2) probe with a positive control — a socket the script creates in the workspace, to show the probe itself works.

Host, outside the sandbox:

POSITIVE  workspace ctl.sock          -> CONNECTED
          /run/dbus/system_bus_socket -> CONNECTED
          /run/snapd.socket           -> ECONNREFUSED (111)
          /run/user/<uid>/bus         -> CONNECTED

Same script, same host, run inside the sandbox with the configuration above:

POSITIVE  workspace ctl.sock          -> CONNECTED
          /run/dbus/system_bus_socket -> ENOENT (2)
          /run/snapd.socket           -> ENOENT (2)
          /run/user/<uid>/bus         -> ENOENT (2)

The positive control connects in both, so a non-connection inside is a real syscall result rather than a broken probe. The only variable between the "visible as srw-rw-rw-" state above and this one was the denyRead value, so on this host the difference is attributable to that setting rather than to the sockets being absent from the namespace to begin with. Only these three paths received a connect(2) probe; the other two were checked with ls only.

Inherited descriptors, from /proc/self/fd symlink targets in the probe process:

fd 0 -> /dev/null
fd 1 -> (task output file)
fd 2 -> (task output file)
fd 3 -> /usr/bin/claude

None socket-backed, in that process at that moment.

The network namespace handle inside the sandbox differed from the host's (net:[4026532239] vs net:[4026531840]), so the probe process remained in a different network namespace. Linux scopes abstract AF_UNIX names by network namespace, so that prevents a fresh lookup of an abstract name bound only in the host namespace. It does not establish anything about egress filtering. denyRead provides no filesystem-path control over connection to a known abstract-socket address, because abstract addresses have no VFS pathname.

I also counted /proc/net/unix inside the sandbox and got zero pathname entries, but that file is network-namespace-specific, so I am not offering it as evidence of anything about the /run deny.

What this is and is not

This is a host-specific path-hiding configuration, not restored Unix-socket filtering. What I measured is that connect(2) through those three pathnames returns ENOENT. That does not cover:

• abstract-namespace sockets, if network isolation is ever absent or shared
• already-open or inherited descriptors — pathname masking does not revoke an existing open file description
• a descriptor received via SCM_RIGHTS over any socket that remains reachable
• a bind-mount or hard-link alias resolving to the same socket inode from outside the denied trees
• any socket path outside the denied trees

I also did not test general usability with /run denied beyond a workspace read and write plus the resolver-config check above. /run holds more than sockets, so a workflow needing other session state may need narrower rules than mine. I would rerun the inventory after host service or package changes.

One note on verification method

My first attempt at checking this was to ask the agent whether it could read a credential file. It declined before making any filesystem call, so no OS enforcement was exercised and the result said nothing about the boundary. What worked was placing a harmless file of random size in the same denied directory and asking for its byte count: the lookup succeeded on the host and returned ENOENT inside the sandbox. The connect(2) probe above came from the same lesson — the agent's willingness to attempt something is not the boundary being tested.