Présentation

Microsoft Execution Container (MXC) est un système de sandboxing destiné à exécuter du code non fiable – par exemple la sortie d’un modèle d’IA, des plugins ou des outils – sur Windows, Linux et macOS. Le projet, publié sous licence MIT, expose une API unifiée qui permet aux développeurs d’isoler leurs charges de travail sans gérer directement les mécanismes d’isolation propres à chaque système d’exploitation.

Architecture et backends

MXC s’appuie sur une couche d’abstraction qui sélectionne, selon le système hôte, le backend d’isolation le plus adapté. Sur Windows 11 (x64/ARM64), le backend par défaut est ProcessContainer, avec la possibilité d’utiliser Windows Sandbox, WSLC, MicroVM, Hyperlight ou IsolationSession. Sur Linux (x64/ARM64), le backend de référence est Bubblewrap, complété par LXC, MicroVM et Hyperlight. macOS (ARM64/x64) ne propose actuellement que le backend Seatbelt. Les backends marqués d’un astérisque sont encore expérimentaux, ce qui implique une surveillance accrue des mises à jour.

Chaque backend implémente le même modèle de cycle de vie : provisionnement, démarrage, exécution, arrêt et déprovisionnement. Cette uniformité permet à l’application appelante de rester indépendante du type de conteneur sous‑jacent.

Modèle de politique et SDK

Les conteneurs MXC sont configurés via un fichier JSON versionné. Le schéma décrit les politiques de système de fichiers (listes de chemins en lecture‑seule, lecture‑écriture ou refusés), les politiques réseau (proxy, contrôle de sortie, filtrage d’hôtes) et les politiques UI (accès au presse‑papier, affichage, interface graphique). Cette approche « policy‑driven » garantit que les règles de confinement sont explicites et auditables.

Le projet fournit des SDK natifs pour Rust, .NET et Node.js. Le SDK Rust compile le moteur MXC et les backends sélectionnés directement dans l’application, tandis que les packages .NET et Node incluent les exécutables natifs requis. Les développeurs peuvent ainsi invoquer MXC sans cloner le dépôt : il suffit d’ajouter la dépendance via crates.io, nuget.org ou npmjs.com.

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};
const child = await spawn(request);

Le fragment montre la création d’une requête JSON minimale : exécution d’une commande Node, interdiction de toute sortie réseau et délai d’attente de 30 s.

Analyse des limites et perspectives

Le principal point de friction réside dans la configuration des politiques. Un conteneur mal paramétré bloque l’accès aux ressources nécessaires, ce qui se traduit par des erreurs d’accès refusé. MXC propose un mode de débogage qui expose les raisons de ces blocages, mais la résolution dépend du développeur.

Les backends expérimentaux (MicroVM, Hyperlight, IsolationSession) offrent des niveaux d’isolation supérieurs, mais leur stabilité varie selon les versions du système d’exploitation. De plus, la prise en charge de macOS se limite à Seatbelt, ce qui réduit les options d’isolation avancée sur cette plateforme.

En résumé, MXC fournit une interface cohérente pour le sandboxing multiplateforme, repose sur des backends natifs éprouvés et expose des politiques détaillées via JSON. Son adoption nécessite toutefois une phase d’ajustement des règles de confinement et une vigilance accrue lors de l’utilisation des backends expérimentaux.