LiteBox 0.1 Projet open source Microsoft
  • 9 octobre 2026
  • ComputaSYS
  • 0


Une bibliothèque à la place d’un système d’exploitation complet, pour n’exposer à l’application que le strict nécessaire. C’est le principe de LiteBox, le projet open source de Microsoft écrit en Rust, désormais disponible en version 0.1.

LiteBox fait partie de ces projets qui montrent l’engagement de Microsoft auprès de la communauté open source. Il avait été rendu public au début du mois de février 2026 et Microsoft l’avait annoncé par l’intermédiaire de James Morris, responsable de la sécurité des systèmes Linux et de l’engagement open source chez Microsoft. Il est d’ailleurs développé en collaboration avec LVBS (Linux Virtualization-Based Security).

Huit mois plus tard, Microsoft a publié sur GitHub la version 0.1.0 de LiteBox. Il s’agit de la première release officielle du projet, sans trop de détails, si ce n’est que Microsoft précise que les prochaines versions seront accompagnées d’un journal des modifications. En effet, ça peut être utile.

LiteBox est, ce qu’on appelle, un library OS. À l’inverse de Linux ou Windows, il ne fonctionne pas de manière autonome. Il implémente les fonctions d’un système d’exploitation sous la forme d’une bibliothèque, utilisée par l’application dans un environnement d’exécution contrôlé. L’application ne voit que les interfaces dont elle a besoin, et les échanges avec le système hôte sont réduits au minimum. Ni une VM, ni un conteneur.

“LiteBox est un library OS de sandboxing qui réduit drastiquement l’interface avec l’hôte, et donc la surface d’attaque”, peut-on lire sur le dépôt GitHub du projet. Moins d’interfaces, c’est moins de portes d’entrée pour un logiciel malveillant ou compromis.

Une architecture en deux faces : North et South

LiteBox repose sur une architecture modulaire articulée autour de deux interfaces. L’interface North fournit les fonctions du système d’exploitation aux applications, au travers d’une API Rust inspirée des bibliothèques nix et rustix (deux bibliothèques qui donnent accès aux appels système de type POSIX). L’interface South, de son côté, relie LiteBox à la plateforme d’exécution sous-jacente.

L’intérêt de cette séparation ? Pouvoir associer n’importe quelle couche applicative (North) à n’importe quelle plateforme (South), sans revoir l’ensemble du système. LiteBox est d’ailleurs conçu pour fonctionner aussi bien en mode noyau qu’en mode utilisateur.

Parmi les cas d’usage évoqués par Microsoft, on trouve :

Linux sur Windows : exécuter des programmes Linux non modifiés sur Windows (ce qui ne devrait pas remettre en cause WSL pour autant).

Linux sur Linux : isoler des applications Linux dans une sandbox, directement sur un hôte Linux.

AMD SEV-SNP : exécuter des programmes au-dessus de cette technologie de calcul, qui protège la mémoire des machines virtuelles au niveau matériel.

OP-TEE : exécuter sous Linux des programmes conçus pour cet environnement d’exécution de confiance open source.

LVBS : fonctionner sur Linux Virtualization-Based Security, où LiteBox joue le rôle d’un noyau sécurisé chargé de protéger le noyau d’une machine invitée, en s’appuyant sur les fonctions de virtualisation matérielle.

Donc quand je disais précédemment que LiteBox n’est pas une VM ni un conteneur, c’est pour les raisons suivantes : un conteneur partage le noyau de l’hôte, une machine virtuelle embarque un noyau complet. LiteBox, lui, cherche à limiter ce que l’application peut solliciter, quel que soit le socle en dessous.

Rust, encore et toujours

Pour développer LiteBox, Microsoft a fait le choix du langage Rust. Ce n’est pas étonnant, la firme de Redmond pousse Rust depuis plusieurs années… Notamment parce qu’il limite les vulnérabilités liées à la gestion de la mémoire. D’ailleurs, en début de semaine, je vous expliquais que Rust est officiellement devenu un langage de Tier-1 chez Microsoft, au même rang que C++.

LiteBox reste un projet en développement actif, mais l’approche est intéressante. Les mainteneurs préviennent que les API et les interfaces peuvent encore évoluer. “Si vous avez besoin d’une stabilité sur le long terme, il peut être préférable d’attendre une version stable, ou d’être prêt à vous adapter aux mises à jour”, précise Microsoft. Autrement dit, ce n’est pas encore un outil à déployer en production… mais plutôt un terrain d’expérimentation.

Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.



Source link

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *