fix(network): narrow additional CA review scope

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Author: jhjaggars

crates/openshell-supervisor-process/src/sandbox/linux/landlock.rs

@@ -96,77 +96,6 @@ pub struct PreparedRuleset {
     compatibility: LandlockCompatibility,
 }
 
-impl PreparedRuleset {
-    /// Try to add a read-write rule for `/dev/tty` (the controlling terminal).
-    ///
-    /// `/dev/tty` is a magic device that refers to the calling process's
-    /// controlling terminal. The supervisor process has no controlling terminal,
-    /// so `PathFd::new("/dev/tty")` fails with `ENXIO` during [`prepare`].
-    /// After the child calls `setsid()` + `TIOCSCTTY`, `/dev/tty` becomes
-    /// accessible. This method lets the child add the rule before
-    /// `restrict_self()`.
-    ///
-    /// Consumes and returns `self` because `RulesetCreated::add_rule` takes
-    /// ownership. Failures are silently ignored — `/dev/tty` is only needed
-    /// by interactive TUI programs (`prompt_toolkit`, ratatui, etc.).
-    pub fn add_dev_tty_if_available(self) -> Self {
-        let path = Path::new("/dev/tty");
-        let Ok(path_fd) = PathFd::new(path) else {
-            return self; // no controlling terminal — nothing to do
-        };
-        let abi = ABI::V2;
-        let Ok(allowed_access) = access_for_path_fd(&path_fd, AccessFs::from_all(abi), abi) else {
-            return self;
-        };
-        let compatibility = self.compatibility;
-        // add_rule takes ownership of `self.ruleset`.  On success we get
-        // the updated ruleset back; on error it is consumed irreversibly.
-        // The error requires a landlock_add_rule syscall failure (kernel
-        // bug), so we treat it as unreachable and fall through without
-        // the /dev/tty rule.
-        match self
-            .ruleset
-            .add_rule(PathBeneath::new(path_fd, allowed_access))
-        {
-            Ok(ruleset) => Self {
-                ruleset,
-                compatibility,
-            },
-            Err(err) => {
-                tracing::debug!(
-                    error = %err,
-                    "Landlock add_rule for /dev/tty failed (non-fatal)"
-                );
-                // Ruleset is consumed; build a fresh empty one so
-                // enforce() can still call restrict_self().  The original
-                // rules were already committed to the kernel fd, but that
-                // fd is now gone, so enforce will apply a maximally
-                // restrictive empty ruleset.  This is preferable to
-                // skipping Landlock entirely.
-                let fallback = Ruleset::default()
-                    .set_compatibility(compat_level(&compatibility))
-                    .handle_access(AccessFs::from_all(abi))
-                    .and_then(Ruleset::create);
-                fallback.map_or_else(
-                    |_| {
-                        // Cannot recover at all.  The process will
-                        // continue without Landlock enforcement.
-                        // Return a dummy that enforce() can handle.
-                        unreachable!(
-                            "failed to create fallback Landlock ruleset \
-                             after add_rule failure for /dev/tty"
-                        )
-                    },
-                    |ruleset| Self {
-                        ruleset,
-                        compatibility,
-                    },
-                )
-            }
-        }
-    }
-}
-
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 enum PathOpenMode {
     Privileged,

crates/openshell-supervisor-process/src/sandbox/linux/mod.rs

@@ -51,11 +51,6 @@ pub fn prepare_current_user(
 /// Neither operation requires root privileges.
 pub fn enforce(prepared: PreparedSandbox) -> Result<()> {
     if let Some(ruleset) = prepared.landlock {
-        // The child process now has a controlling terminal (setsid +
-        // TIOCSCTTY ran before this point), so /dev/tty is accessible.
-        // The supervisor couldn't add this rule during prepare() because
-        // it has no controlling terminal (/dev/tty returns ENXIO).
-        let ruleset = ruleset.add_dev_tty_if_available();
         landlock::enforce(ruleset)?;
     }
     seccomp::apply(&prepared.policy)?;

deploy/helm/openshell/README.md

@@ -115,8 +115,13 @@ The driver manages the deterministic name
 `server.sandboxJwt.gatewayId`, or the chart fullname when unset). Its `get` and
 `patch` permissions must be restricted to that exact name; `create` must remain
 a separate unrestricted ConfigMap permission because Kubernetes cannot apply
-`resourceNames` to create authorization. If you render the TOML setting outside
-this Helm value, grant that same split RBAC policy in every sandbox namespace.
+`resourceNames` to create authorization. Enabling this therefore gives the
+gateway/driver service account namespace-wide ConfigMap-create authority. In
+managed/operator modes, the chart's ClusterRoleBinding makes that permission
+cluster-wide for the bound service account; use a dedicated service account and
+scoped bindings when that boundary matters. If you render the TOML setting
+outside this Helm value, grant that same split RBAC policy in every sandbox
+namespace.
 
 Disabling the setting intentionally does not delete driver-managed ConfigMaps:
 the driver has no list/delete permissions, and a shared or operator namespace

deploy/helm/openshell/README.md.gotmpl

@@ -115,8 +115,13 @@ The driver manages the deterministic name
 `server.sandboxJwt.gatewayId`, or the chart fullname when unset). Its `get` and
 `patch` permissions must be restricted to that exact name; `create` must remain
 a separate unrestricted ConfigMap permission because Kubernetes cannot apply
-`resourceNames` to create authorization. If you render the TOML setting outside
-this Helm value, grant that same split RBAC policy in every sandbox namespace.
+`resourceNames` to create authorization. Enabling this therefore gives the
+gateway/driver service account namespace-wide ConfigMap-create authority. In
+managed/operator modes, the chart's ClusterRoleBinding makes that permission
+cluster-wide for the bound service account; use a dedicated service account and
+scoped bindings when that boundary matters. If you render the TOML setting
+outside this Helm value, grant that same split RBAC policy in every sandbox
+namespace.
 
 Disabling the setting intentionally does not delete driver-managed ConfigMaps:
 the driver has no list/delete permissions, and a shared or operator namespace

deploy/helm/openshell/templates/clusterrole.yaml

@@ -78,7 +78,10 @@ rules:
   # The Kubernetes driver reads and server-side-applies only its deterministic,
   # gateway-scoped destination CA ConfigMap in selected namespaces. CREATE
   # cannot use resourceNames because Kubernetes authorizes it before the name
-  # is available.
+  # is available. This is a namespace-wide ConfigMap-create capability when
+  # bound through a Role, and becomes cluster-wide when this ClusterRole is
+  # bound cluster-wide; use a dedicated service account and scoped bindings
+  # when that boundary matters.
   - apiGroups:
       - ""
     resources:

deploy/helm/openshell/templates/role.yaml

@@ -51,7 +51,9 @@ rules:
   {{- if $additionalCaEnabled }}
   # The Kubernetes driver reads and server-side-applies only its deterministic,
   # gateway-scoped destination CA ConfigMap. CREATE cannot use resourceNames:
-  # Kubernetes authorizes creates before the object name is available.
+  # Kubernetes authorizes creates before the object name is available. This is
+  # a namespace-wide ConfigMap-create capability; use a dedicated gateway
+  # service account when that boundary matters.
   - apiGroups:
       - ""
     resources:

skills/debug-openshell-cluster/SKILL.md

@@ -354,7 +354,11 @@ chart fullname when it is unset. The managed ConfigMap must have
 `openshell.ai/managed-by=openshell` and the matching
 `openshell.ai/gateway-id` label. The chart grants `get`/`patch` only on this
 exact name and separate unrestricted `create` (Kubernetes cannot restrict a
-create with `resourceNames`). Check both the object and authorization:
+create with `resourceNames`). Enabling this gives the gateway/driver service
+account namespace-wide ConfigMap-create authority. In managed/operator modes,
+the chart's ClusterRoleBinding makes that permission cluster-wide for the bound
+service account; prefer a dedicated service account and scoped bindings when
+that boundary matters. Check both the object and authorization:
 
 ```bash
 kubectl -n <sandbox-namespace> get configmap \