Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

feat(policy): add portable UI controls for MXC sandboxes

Ouverte
  • Quelque chose ne va pas ?
#3,022 2 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@shailendra-nv y travaille déjà.

Depuis le 1/9/2026.

  • #3221 par @shailendra-nv — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

Description

state:accepted

User Story

As an OpenShell operator, I want a platform-neutral UI policy so I can
explicitly control graphical UI access, clipboard direction, and synthetic
input without embedding backend-specific or operating-system-specific concepts
in an OpenShell policy.

Problem Statement

OpenShell cannot currently express portable UI controls. The MXC mapper has an
intermediate restrictive top-level ui representation, but the active typed
driver path does not carry that representation into wxc-exec, so there is no
end-to-end UI policy enforcement today.

MXC process containers can enforce the proposed controls. MXC isolation
sessions and the current Docker, Podman, Kubernetes, and VM drivers cannot
enforce the complete contract. Without an explicit driver capability boundary,
OpenShell could accept a UI policy on a backend that cannot truthfully report it
as enforced.

Impact / Why This Matters

Windows process-container users cannot opt into a graphical application,
selectively allow clipboard reads or writes, or permit input injection through
an OpenShell policy. Bypassing or modifying the mapper loses the portable
OpenShell policy boundary and is unsuitable for managed sandboxes.

More broadly, silently accepting UI policy on an unsupported backend would
weaken policy integrity. Operators need sandbox creation to fail before
provisioning when the selected backend cannot enforce an explicitly requested
UI contract.

Proposed Design

Add an optional, typed, static ui section to the version 1 OpenShell policy:

ui:
  allow_graphical_ui: false
  clipboard: none
  allow_input_injection: false

The field names describe portable capabilities rather than Windows APIs.
clipboard accepts none, read, write, or all. Within an explicitly
present UI section on a supporting backend, omitted fields default to deny.
Absence of the entire section means no UI-policy request and preserves existing
runtime behavior.

Compute drivers advertise whether their configured backend can enforce the
complete UI policy contract. Before any lifecycle side effect, OpenShell rejects
an explicitly present UI section, including ui: {} or a deny-only section, if
the selected driver does not advertise support.

Driver or backend Explicit ui section Absent ui section
MXC process_container Enforce all three capabilities exactly Preserve the existing restrictive MXC output
MXC isolation_session Reject before invoking MXC Preserve existing backend behavior; claim no UI restriction
Docker, Podman, Kubernetes, VM Reject before provisioning Preserve existing behavior
Future drivers Accept only after advertising complete UI-policy enforcement Preserve existing behavior

On MXC process containers, map the three capabilities to MXC's top-level
ui.disable, ui.clipboard, and ui.injection. Do not expose MXC's
Windows-specific desktop, system-settings, IME, or isolation controls.

The section is immutable after sandbox creation and participates in static
policy comparison and hashing. Driver capability checks apply at sandbox
creation; live policy mutation cannot add, remove, or change UI policy.

Current MXC Contract

Microsoft MXC models top-level ui as a one-shot configuration field. Its
state-aware isolation-session provision contract does not include ui, and MXC
maintains explicit rejection fixtures for isolation-session configurations that
supply the field:

OpenShell therefore rejects explicit UI policy for MXC isolation_session
itself, producing stable fail-closed behavior across MXC versions without
relying on whether a particular MXC build rejects or ignores the unsupported
field.

Alternatives Considered

  • Scope UI controls as MXC-specific configuration. Rejected because the policy
    fields describe portable security capabilities and future drivers may
    implement the same complete contract.
  • Expose MXC's JSON shape directly. Rejected because it would leak
    backend-specific and Windows-specific concepts into an OS-agnostic policy.
  • Add generic host-device or desktop-system-control fields now. Rejected
    because the semantics are not portable across operating systems.
  • Silently accept UI policy and apply a more restrictive backend default.
    Rejected because OpenShell could not truthfully report the requested policy
    as enforced.
  • Treat an absent UI section as a universal deny guarantee. Rejected because
    backends without UI enforcement cannot make that claim; absence must preserve
    existing behavior.
  • Silently discard explicit UI policy on MXC isolation_session. Rejected
    because requested security policy must not be reported as enforced when it is
    not representable.

Acceptance Criteria

  • The version 1 protobuf and YAML policy surface includes the typed,
    optional, platform-neutral UI section and preserves absent versus
    explicitly empty presence.
  • Within an explicit UI section, omitted fields default to deny.
  • Compute drivers advertise complete UI-policy enforcement support.
  • Sandbox creation fails before provisioning when an explicit UI section is
    supplied to a driver or configured backend that does not advertise UI
    policy support.
  • UI policy is static, hash-significant, deterministic, and round-trips
    through protobuf/YAML conversions.
  • MXC process containers map every UI capability exactly and preserve the
    legacy restrictive output when the OpenShell section is absent.
  • MXC isolation sessions preserve existing behavior when UI is absent and
    reject any explicit UI section before invoking MXC.
  • Docker, Podman, Kubernetes, and VM preserve existing behavior when UI is
    absent and reject any explicit UI section before provisioning.
  • Mapper, schema, conversion, hashing, capability, create-validation, and
    platform-boundary tests cover the new behavior.
  • Real-MXC contract tests cover process-container mapping and
    isolation-session rejection against supported baseline and current MXC
    revisions.
  • Relevant architecture, user, crate, and agent-skill documentation is
    updated with the capability matrix and absence semantics.
  • Cross-platform CI and supported Windows architecture validation pass.
Langage dominant
Rust
Étoiles
15.4k
Forks
1.7k
Merge moyen
1 j 19 h
PR mergées (30 j)
347

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.