LiteBox 0.1: Microsoft’s Rust-Based Library OS Aims to Isolate Apps
A library instead of a full operating system, exposing only the bare minimum to the application. That is the principle behind LiteBox, Microsoft’s open source Rust project, now available in version 0.1.
LiteBox is one of those projects that highlights Microsoft’s commitment to the open source community. It was made public at the beginning of February 2026, and Microsoft announced it through James Morris, the company’s Linux systems security and open source engagement lead at Microsoft. It is also being developed in collaboration with LVBS (Linux Virtualization-Based Security).
Eight months later, Microsoft published LiteBox version 0.1.0 on GitHub. This is the project’s first official release, with very few details so far, except that Microsoft says future versions will come with a changelog. And honestly, that can be useful.
LiteBox is what is known as a library OS. Unlike Linux or Windows, it does not run on its own. It implements operating system functions in the form of a library, used by the application within a controlled runtime environment. The application only sees the interfaces it needs, and exchanges with the host system are reduced to a minimum. Neither a VM nor a container.
"LiteBox is a sandboxing library OS that drastically reduces the interface with the host, and therefore the attack surface", we can read on the project’s GitHub repository. Fewer interfaces mean fewer entry points for malicious or compromised software.
A two-sided architecture: North and South
LiteBox is based on a modular architecture built around two interfaces. The North interface provides operating system functions to applications through a Rust API inspired by the nix and rustix libraries (two libraries that provide access to POSIX-style system calls). The South interface, on the other hand, connects LiteBox to the underlying execution platform.
What is the point of this separation? It makes it possible to pair any application layer (North) with any platform (South) without redesigning the whole system. LiteBox is also designed to run in both kernel mode and user mode.

Among the use cases mentioned by Microsoft, we find:
- Linux on Windows: run unmodified Linux programs on Windows (which should not call WSL into question, however).
- Linux on Linux: isolate Linux applications in a sandbox directly on a Linux host.
- AMD SEV-SNP: run programs on top of this confidential computing technology, which protects virtual machine memory at the hardware level.
- OP-TEE: run programs under Linux that were designed for this open source trusted execution environment.
- LVBS: operate on Linux Virtualization-Based Security, where LiteBox acts as a secure kernel responsible for protecting a guest machine’s kernel by relying on hardware virtualization features.
So when I said earlier that LiteBox is neither a VM nor a container, here’s why: a container shares the host’s kernel, while a virtual machine ships with a full kernel. LiteBox, for its part, tries to limit what the application can access, whatever the underlying platform may be.
Rust, once again
To develop LiteBox, Microsoft chose the Rust language. That is not surprising, since the Redmond company has been pushing Rust for several years now, notably because it helps reduce memory management vulnerabilities. By the way, earlier this week, I explained that Rust has officially become a Tier-1 language at Microsoft, on par with C++.
LiteBox is still an actively developed project, but the approach is interesting. The maintainers warn that APIs and interfaces may still evolve. "If you need long-term stability, it may be better to wait for a stable release, or be prepared to adapt to updates", Microsoft notes. In other words, this is not yet a tool to deploy in production... but rather a testbed for experimentation.


