Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

🌿 Preview your docs: https://nvidia-preview-pr-2076.docs.buildwithfern.com/openshell

Label test:e2e applied, but pull-request/2076 is at {"messa while the PR head is 6276de3. A maintainer needs to comment /ok to test 6276de38ac92b65b0b24a68b8d09a5eed06f50d7 to refresh the mirror. Once the mirror catches up, re-run Branch E2E Checks from the Actions tab.

Some comments with help of agent

1. Central trust boundary — the workload can use the sandbox's gateway identity .
Client mTLS and the SA token render 0440 with fsGroup=sandbox_gid, the process leaf skips supervisor-identity isolation in network-only, and the 127.0.0.1:18080 forward is always open. Since the workload child also runs with sandbox_gid, it can read those credentials and reach the gateway directly.

2. nftables fence only covers TCP/UDP.
The output chain is policy accept and only rejects TCP/UDP from non-proxy_uid UIDs. ICMP (e.g. unprivileged ping sockets) and other L4 protocols fall through. CAP_NET_RAW is dropped so raw sockets aren't available, but this is a narrower egress boundary than combined mode's per-netns setup. Low severity — suggest a brief comment in generate_sidecar_bypass_ruleset noting the intentional scope.

3. processEnforcement=full does not restore network binary-identity.
supervisor_sidecar_env hard-codes NETWORK_BINARY_IDENTITY=relaxed regardless of process_enforcement, so full restores agent-container Landlock/privilege-drop but network policy stays endpoint/L7-scoped. The docs are technically accurate ("combined-mode process/filesystem controls"), but a reader could reasonably infer full ≈ combined. A one-line note that network policy remains endpoint-scoped in sidecar mode regardless of processEnforcement would prevent that.

4. Doc drift in the debug skill.
debug-openshell-cluster/SKILL.md says the sidecar runs "with primary GID 0" to read the token, but the implementation uses runAsGroup: sandbox_gid + fsGroup: sandbox_gid (which re-owns the projected volume to sandbox_gid). Please update to match.

1. Central trust boundary — the workload can use the sandbox's gateway identity .
   Client mTLS and the SA token render 0440 with fsGroup=sandbox_gid, the process leaf skips supervisor-identity isolation in network-only, and the 127.0.0.1:18080 forward is always open. Since the workload child also runs with sandbox_gid, it can read those credentials and reach the gateway directly.

Addressed this by moving the supervisor and sandbox to run with different GIDs.

Updated the other areas with clarifying comments.

Deployed this branch on an OpenShift 4.22 cluster (K8s 1.35) with supervisor.topology=sidecar and TLS + mTLS enabled (default PKI init job). The sidecar pod renders correctly, but openshell-network-init is stuck in CrashLoopBackOff:

Error:   × failed to create sidecar directory /etc/openshell-tls/proxy/client
  ╰─▶ Permission denied (os error 13)

$ oc -n openshell get pod test-sidecar
NAME           READY   STATUS                  RESTARTS
test-sidecar   0/2     Init:CrashLoopBackOff   6

Root cause

In run_network_init (crates/openshell-sandbox/src/main.rs) the ordering is:

1. prepare_sidecar_directory(sidecar_tls_dir /* /etc/openshell-tls/proxy */, proxy_uid, proxy_gid, 0o755) — this chowns the TLS dir to proxy_uid (e.g. 1337), mode 0755.
2. copy_sidecar_client_tls_if_present(...) → prepare_sidecar_directory(dest_dir /* …/proxy/client */, …) → create_dir_all.

Step 2 runs as root with capabilities.drop: ["ALL"] (the init container only adds NET_ADMIN, NET_RAW, CHOWN, FOWNER, so it has no CAP_DAC_OVERRIDE). The parent dir is now owned by uid 1337, mode 0755, so root is neither the owner nor has group-write → EACCES. Root can no longer bypass DAC checks because DAC_OVERRIDE was dropped.

Note the state dir was already changed to 0o2775 (setgid + group-write), but the TLS dir is still 0o755, and it's the one that gets a subdirectory created in it right after being chowned away from root.

@mrunalp I reproduced locally and pushed a fix. Please have a look when you get a chance!

This draft intentionally includes the prerequisite UID/GID commits from #1973 for now. We expect to rebase those out after that work lands separately.

Looks like you've rebased now since that's been merged?

Discussed with @TaylorMutch:

Suggestion: keep Landlock (and seccomp) in sidecar network-only mode — they don't need privilege

In sidecar topology the process leaf runs network-only, which currently disables Landlock, seccomp, and filesystem policy along with the genuinely privileged controls:

// crates/openshell-supervisor-process/src/process.rs:591
let prepared_sandbox = if enforcement_mode.enforces_process_controls() {
    Some(sandbox::linux::prepare(policy, workdir)?)   // Landlock ruleset prep
} else { None };

enforces_process_controls() is false for sidecar, so prepare() is skipped and no Landlock ruleset is built — same in the ssh.rs spawn paths. But most of what's gated here doesn't actually require privilege, so we're relaxing more than we need to.

Landlock is unprivileged by design

landlock_create_ruleset / add_rule / restrict_self need no capabilities — Landlock only ever removes access, so any process may self-restrict. The single precondition for restrict_self is no_new_privs, and we already set that unconditionally:

• harden_child_process() → set_no_new_privs() (sandbox/linux/seccomp.rs:126) runs in the child pre-exec outside the enforces_process_controls() gate (e.g. ssh.rs:1266), so it fires in sidecar mode too.

So the kernel prerequisite for Landlock is already satisfied in the capless agent container. It's gated off only incidentally:

1. Bundling — enforces_process_controls() lumps Landlock with drop_privileges (setuid/setgid — needs root) and the supervisor-identity mount isolation (needs CAP_SYS_ADMIN/userns). Landlock got swept up with controls that genuinely need privilege.
2. "Prepare as root" — prepare() opens Landlock PathFds "as root before drop_privileges" (sandbox/linux/mod.rs:15,21) so it can open mode-700 paths. That's an optimization for the root→user transition, not a Landlock requirement.

What it would take

• Ungate Landlock (and seccomp) from enforces_process_controls() so they apply even when we're not dropping privileges.
• Open the path FDs as the sandbox UID in the sidecar path. Paths that UID can't open are ones the workload can't reach anyway — skip them / treat open-failure as already-denied. "Open as root" is unnecessary when the workload is that UID.
• Keep the existing kernel-availability probe (log_sandbox_readiness) and degrade gracefully where Landlock/ABI is unavailable.

Seccomp is the same: filters install unprivileged under no_new_privs, so the syscall hardening can also run in the sidecar agent.

What legitimately stays out — and why it doesn't matter here

• Privilege dropping (root → sandbox uid): needs root, but in sidecar mode Kubernetes already starts the container as runAsUser=sandbox_uid, runAsNonRoot: true. Nothing to drop.
• Supervisor-identity mount isolation (hiding the SA token): needs CAP_SYS_ADMIN. Moot in sidecar mode — the credential redesign already keeps gateway creds out of the agent container (snapshot brokering).

Net effect

Re-enabling Landlock + seccomp shrinks the sidecar's "relaxed filesystem/process controls" tradeoff down to essentially just "network binary-identity is relaxed." The agent container stays capless and non-root, but the workload regains filesystem and syscall confinement.

Caveat: kernel availability

Landlock must be compiled in (CONFIG_SECURITY_LANDLOCK) and present in the active LSM list. RHEL 9 / RHCOS historically shipped without it enabled (added in later minors), so on OpenShift it may be unavailable even after ungating — in which case the availability probe should simply no-op it (as it does today), while it engages on upstream/newer kernels (k3d, GKE, etc.). Worth ungating regardless: it applies wherever the kernel supports it and degrades cleanly where it doesn't. Quick check on a target node: cat /sys/kernel/security/lsm should list landlock.