NVIDIA / NVIDIA/OpenShell

openshell-gateway fails on Ubuntu 24.04: user namespace creation denied by AppArmor (apparmor_restrict_unprivileged_userns=1)

Open
#1,895 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area:build area:gateway os:linux state:stale topic:compatibility
Dominant language
Rust
Stars
8.7k
Forks
1.3k
Avg merge
2d 11h
Merged PRs (30d)
253

Description

Summary

On Ubuntu 24.04, openshell-gateway.service (the systemd --user unit shipped by the
openshell package) cannot create a usable user namespace: AppArmor transitions the
unconfined gateway process into the stock unprivileged_userns profile and then denies
CAP_SYS_ADMIN inside the namespace. As a result the gateway's sandbox setup fails and no
sandboxed command can run.

This is the Ubuntu 24.04 default kernel.apparmor_restrict_unprivileged_userns=1 behavior,
and OpenShell currently ships nothing to accommodate it.

Environment

  • Ubuntu 24.04, kernel 6.17.0-35-generic, x86_64
  • openshell 0.0.40-1 (from the .deb)
  • kernel.apparmor_restrict_unprivileged_userns = 1 (distro default)

Symptom

The consuming sandbox client fails when setting up the namespace, with:

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

Root cause (kernel audit evidence)

At the moment of failure, dmesg / the audit log shows the gateway being launched and its
user-namespace creation transitioned, immediately followed by a CAP_SYS_ADMIN denial:

apparmor="AUDIT"  operation="userns_create" class="namespace"
    info="Userns create - transitioning profile" profile="unconfined"
    comm="(-gateway)" execpath="/usr/lib/systemd/systemd-executor"
    target="unprivileged_userns"
apparmor="DENIED" operation="capable" class="cap"
    profile="unprivileged_userns" capability=21 capname="sys_admin"

Two contributing factors:

  1. Unconfined → unprivileged_userns transition. Because the gateway runs with no
    AppArmor profile, Ubuntu 24.04's apparmor_restrict_unprivileged_userns=1 transitions it
    into the restrictive unprivileged_userns stub on userns_create, which strips
    CAP_SYS_ADMIN — exactly what's needed to write setgroups and set up the sandbox
    mounts.

  2. PrivateTmp=true on a user service compounds it. openshell-gateway.service sets
    PrivateTmp=true. For a systemd --user (unprivileged) manager, honoring PrivateTmp
    requires creating a mount namespace, which in turn forces creation of a user
    namespace
    at service launch — so the gateway hits the restriction even before its own
    logic runs.

Note that the documented Ubuntu 24.04 remedy of adding an AppArmor profile for
/usr/bin/bwrap does not help here, because the binary creating the failing namespace
is systemd-executor launching the gateway unit — not bwrap.

Suggested fixes (any one unblocks it; ship-side preferred)

  1. Ship an AppArmor profile for the gateway binary that grants userns, so it isn't
    transitioned into unprivileged_userns. e.g.:

    # /etc/apparmor.d/openshell-gateway
    abi <abi/4.0>,
    include <tunables/global>
    profile openshell-gateway /usr/bin/openshell-gateway flags=(unconfined) {
      userns,
      include if exists <local/openshell-gateway>
    }
    
  2. Drop / make optional the namespace-requiring directive in the user unit (e.g.
    PrivateTmp=true) so systemd --user doesn't need a user namespace just to launch the
    gateway. The gateway's persistent state already lives under StateDirectory, not
    /tmp.

  3. Document the Ubuntu 24.04 requirement and detect/log it clearly at startup, since the
    downstream error (setgroups / CAP_SYS_ADMIN) is opaque and points users at the wrong
    component (bubblewrap).

Workaround used

Removing the package (apt remove openshell) and falling back to the other sandbox runtime
present on the host restored command execution. The global AppArmor restriction was left
untouched, confirming the gateway's namespace setup was the failing element rather than the
kernel policy needing to be disabled.

Additional notes

A per-host setup may have two agent-sandbox runtimes installed at once (OpenShell plus
another). When OpenShell's gateway is broken as above, it can break sandboxed command
execution on the host. Clearer startup diagnostics (suggestion 3) would make this much
faster to attribute.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting the packaged openshell-gateway.service, especially its systemd --user settings and PrivateTmp=true, then review how the gateway package installs related files. Reproduce the failure on Ubuntu 24.04 with apparmor_restrict_unprivileged_userns=1 and compare the audit log with gateway startup. Done means the gateway starts and sandboxed commands run, with either a shipped policy, adjusted unit, or clear startup diagnostics.

Written by the indexing model from the issue text.

Assessment

Tech stack
ubuntu
Domain
infrastructure, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.