Microsoft LiteBoxを動かしてみる
Introduction
Microsoftは先日、RustベースのライブラリOSであるLiteBoxをリリースしました。
これは、完全なVMを使用せずにホストOSへのインターフェースを最小限にすることで
セキュリティを高めるサンドボックス型ライブラリOSです。
gVisor(k8sとかで使用されているランタイム)などと異なり、
OS機能をアプリに直接リンクする設計となっています。
※2026/2時点ではexperimental
このプロジェクトは、ライブラリOSという古くて新しいアプローチの最新実装です。
「OSをアプリに組み込む」という昔からある理想を、
安全な言語(Rust)と仮想化技術の組み合わせで実現しようとする試みとなっています。
ライブラリOS?
ライブラリOSとは、もともとカーネル内に存在するOS機能(ファイルシステムやネットワーク、メモリ管理など)を
「ユーザ空間のライブラリ」としてアプリに対してリンクするアーキテクチャです。
┌─────────────────────────────────────┐
│ 従来のOS │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ App A │ │ App B │ │
│ └─────┬─────┘ └─────┬─────┘ │
│ │ syscall │ syscall │
│ ══════╪══════════════╪═══════════ │
│ ┌─────┴──────────────┴─────┐ │
│ │ kernel │ │
│ │ VFS, Net, Sched, MM ... │ │
│ └──────────────────────────┘ │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ Libraly OS │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ App A │ │ App B │ │
│ │ ┌──────────┐ │ │ ┌──────────┐ │ │
│ │ │LibOS │ │ │ │LibOS │ │ │
│ │ │FS,Net,.. │ │ │ │FS,Net,.. │ │ │
│ │ └──────────┘ │ │ └──────────┘ │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ ═══════╪════════════════╪════════ │
│ ┌──────┴────────────────┴──────┐ │
│ │ micro kernel/VMM │ │
│ │ (H/W抽象化のみ) │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────┘
アプリごとに必要なOS機能だけをふくめることができ、
パフォーマンスもよくセキュアです。
ライブラリOSは歴史的に昔(1990年代)からあったようです。
中でもMicrosoft Researchが開発したDrawbridgeというライブラリOSが
「Windows APIをライブラリ化する」という目的で開発され、後のWSLなどに影響を与えました。
そして先日、サンドボックス型ライブラリOSとしてLiteBoxがリリースされました。
なので、ライブラリOSは決して新しいものではないのですが、
高速・軽量・セキュアな実行環境という要求から再度注目されているようです。
LiteBox?
詳細はこのへんで確認してもらうとして、ここでは簡単に。
LiteBoxの特徴は、ホストOSのカーネルを排除し、Rustで書かれた小さなOSでアプリを包むところです。
Linuxなどのカーネルには常に脆弱性リスクが存在します。
そこでLiteBoxはホストOSとアプリの境界に位置し、
必要最小限のOS機能だけを肩代わりすることでセキュリティを高めます。
この、OSをライブラリ化する特徴によって提供するシステムコールを極端に絞り込むことで、
攻撃面を削減し、セキュアなサンドボックス環境を実現しています。
North/South アーキテクチャ
LiteBoxは「North」と「South」の二層インターフェースで構成されています。
開発者はLiteBoxを仲介役として、↓のインターフェースを介して機能を実現します。
Northインターフェース(shims)
アプリケーション側に露出するAPIレイヤー。
各プログラムが利用するシステムコール群を受け止めるインターフェイスです。
アプリから見れば通常のLinux環境のように見える。
実際はLiteBox内で処理が変換され、安全な形で処理されます。
*未修正のLinuxバイナリをそのまま実行可能(再コンパイルの必要なし)
仮にアプリやLiteBox上のコンポーネントに脆弱性があっても、そもそも触れられる機能が限られている。
LiteBoxでは事前に用意された安全な窓口越しにしかホストリソースへアクセスできないため、
被害を最小限に抑えられる。
#現在、以下の2種類のShimが存在
- litebox_shim_linux — Linuxシステムコール変換
- litebox_shim_optee — OP-TEEトラステッドアプリケーション呼び出し変換
Southインターフェース(Platforms)
こちらはLiteBoxとホスト環境を接続するレイヤー。
ホストOSに応じたAPIやシステムコールを直接やり取りする部分です。
GitHubを見る限り、
現在はRustのPlatformトレイトとして実装され、以下のプラットフォームをサポートしているみたいです。
litebox_platform_linux_kernel- Linuxカーネルモードlitebox_platform_linux_userland- Linuxユーザーランドlitebox_platform_windows_userland- Windowsユーザーランドlitebox_platform_lvbs- LVBSlitebox_platform_multiplex- 複数プラットフォームの多重化
柔軟な組み合わせ
特徴として任意のNorthとSouthの組み合わせが可能となっており、
アプリ側のロジックを変えずにプラットフォーム側を差し替えることが可能。
※ LinuxのShimとWindowsのPlatformで、Windows上で未修正のLinuxプログラムを実行など
自由に組み合わせできるので、単一のライブラリOS実装でいろいろなユースケースに対応できます。
カーネルモードで直接ハイパーバイザとして動いたり、ユーザーモードでホストOS上のプロセスとして動いたりも可能。
コンフィデンシャルコンピューティング
LiteBoxはAMD SEV-SNPやARM TrustZone(OP-TEE)といったハードウェアセキュリティ機能にも対応する設計で、
アプリケーション実行時にメモリ内容の暗号化や遠隔検証(リモートアテステーション)を利用できる。
従来のOS上で同じことを実現するのは難しいですが、LiteBoxなら可能なため、
セキュリティ要求の厳しい用途にも適している。
- AMD SEV-SNP: クラウドのハイパーバイザーも信頼せず、VM のメモリを暗号化・改ざん防止するAMDサーバーCPUのハードウェア機能
- ARM TrustZone(OP-TEE): ARMプロセッサ上にハードウェアでセキュアな隔離領域を作り、機密処理を通常OSから守る仕組み(OP-TEEは隔離領域で動くオープンソースのOS)
このように、とにかくコンパクトで安全性が高いことが特徴になってます。
さらに、ほとんどがRustで実装されていることも安全性を高める要因になってます。
Runner
LiteBoxでは、NorthとSouthの具体的なペアを「Runner」として提供しています。
現在は以下のRunnerが公開されています。
| Runner | 説明 |
|---|---|
litebox_runner_linux_on_windows_userland |
完全なLinux VMを必要とせずにWindowsで未修正のLinuxプログラムを実行 |
litebox_runner_linux_userland |
Linux上でLinuxアプリケーションをサンドボックス化 |
litebox_runner_snp |
AMD SEV-SNP上でプログラムを実行 |
litebox_runner_optee_on_linux_userland |
ARM TrustZoneベースのOP-TEEプログラムをLinux上で実行 |
litebox_runner_lvbs |
LVBS上でセキュアカーネルとして動作する |
マルチテナントクラウド環境でのサンドボックス化やCI/CDでの信頼できないコードの実行など、
いろいろな用途が期待できます。
Try
実際にLiteBoxをEC2で動かしてみました。
最初macでorbstackのubuntuで動かそうとしてましたが、
以下のようなエラーで動かず。
error[E0425]: cannot find function `write_u8_fallible`
note: found an item that was configured out
--> litebox/src/mm/exception_table.rs:191:15
190 | #[cfg(target_arch = "x86")]
| ------------------- the item is gated behind the `x86` feature
t3.mediumインスタンスでAmazon Linux 2023 (x86_64)を使って確認しました。
環境構築
LiteBoxをビルド・実行するためのx86_64 Linux環境を構築します。
EC2(t3.medium)起動してSSHポートだけあけておきます。
sshログインしたら、以下のように必要なツールをインストール。
(Development Tools、git、clang、 clang-devel、bindgen、libclang、glibc-staticなど)
% sudo dnf groupinstall -y "Development Tools"
% sudo dnf install -y git clang clang-devel glibc-static
Rustツールチェーンも必須です。
% curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
% source ~/.cargo/env
# 確認
$ rustc --version
rustc 1.93.0 (254b59607 2026-01-19)
GitでLiteBoxのコードをcloneしてビルドしましょう。
% git clone https://github.com/microsoft/litebox.git
% cd litebox
% cargo build --release
・
・
・
Finished `release` profile [optimized] target(s) in xxxxxx
ビルド完了したら以下のようにRunnerが生成されています。
% ls target/release/litebox_runner*
target/release/litebox_runner_linux_on_windows_userland
target/release/litebox_runner_linux_userland
動作確認
LiteBoxのネットワーク機能をテストするためにTUNデバイスを設定しましょう。
TUN(Network TUNnel)デバイスとはLinuxカーネルが提供する仮想NWインターフェイスです。
物理的なネットワークカード(eth0等)とは違い、ソフトウェアで実装された仮想的なデバイスです。
LiteBoxではTUNデバイスでサンドボックス内のプロセスにネットワーク機能を提供します。
こうすることでサンドボックス内のプロセスはホストのネットワークに直接アクセスできず、
すべての通信がLiteBox経由で制御可能になります。
% sudo ./litebox_platform_linux_userland/scripts/tun-setup.sh
[i] Script parameters:
TUN device: tun99
TUN IPs: 10.0.0.1/24
[i] Creating TUN device
[i] Assigning IP addresses
[i] Bringing up TUN device
[+] Created TUN device
テスト実行
既存のテストでLiteBoxの各機能が正しく動作するか確認しましょう。
% cargo test --package litebox --lib
# 結果
test result: ok. 90 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
ファイルシステムやメモリ管理などのテストが実行されます。
なお、以下のようにすればRunnerのテストも実行可能です。
# テスト用に追加パッケージのインストール
% sudo dnf install -y nodejs iperf3
# テスト実行
% cargo test --package litebox_runner_linux_userland
# 結果
test result: FAILED. 6 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out
Amazon Linuxでは/lib/x86_64-linux-gnuが存在しないので失敗してるテストもありますが、
それ以外はOK.
LiteBoxのコア機能は動作してます。
LiteBoxの使い方
最初、↓みたいに実行するものかとおもってやってみたんですが、Segmentation faultエラーでした。
# エラー
% ./target/release/litebox_runner_linux_userland /bin/echo "Hello"
LiteBoxはホストファイルシステムを直接使用しない設計になっており、
サンドボックス内では独自の仮想ファイルシステムが使われます。
なので、以下(テストコード(tests/run.rs)で使われている方法)のようにします。
# 1. プログラムのsyscallを書き換え
% litebox_syscall_rewriter input_binary output_binary.hooked
# 2. 依存ライブラリを含むtarファイルを作成
% tar -cvf rootfs.tar lib64/ lib/ lib32/ out/
# 3. LiteBox経由で実行
% ./target/release/litebox_runner_linux_userland \
--unstable \
--interception-backend rewriter \
--env "LD_LIBRARY_PATH=/lib64:/lib32:/lib" \
--env "HOME=/" \
--initial-files ./rootfs.tar \
./program.hooked arg1 arg2
オプションは以下。
| オプション | 説明 |
|---|---|
--unstable |
実験的機能を有効化(現時点では必須) |
--interception-backend |
seccomp(デフォルト)またはrewriter |
--initial-files |
初期ファイルシステムを構築するtarファイル |
--env K=V |
環境変数を設定 |
--tun-device-name |
TUNデバイス名 |
--rewrite-syscalls |
実行時にsyscall書き換えを行う |
なお、以下のプログラムはテストで動作確認済みです。
ls -a(動的リンク、rewriterバックエンド)- カスタムhelloプログラム(静的/動的)
- Node.jsスクリプト
- iperf3(TUNデバイス経由でネットワーク通信)
- マルチスレッドプログラム(100スレッド並行)
- シグナルハンドリングプログラム
LiteBox内でNode.js Webサーバーを実行してブラウザからアクセス
では、LiteBoxサンドボックス内でNode.js HTTPサーバーを起動し、
外部からアクセスできるようにしてみます。
構成は以下。
[外部PC/ブラウザ]
↓ HTTP GET http://<EC2 Public IP>:3000/
[EC2 ens5: Public IP]
↓ iptables DNAT (3000 → 10.0.0.2:3000)
[TUN tun99: 10.0.0.1/24]
↓ TUN device (仮想ネットワーク)
[LiteBox Sandbox: 10.0.0.2:3000]
↓
[Node.js HTTP Server (sandboxed)]
↓ Response
[外部PC] ← "Hello from LiteBox!"
1. server.jsを作成
シンプルなnodeのHTTPサーバプログラムを作成します。
// /tmp/litebox_web/out/server.js
const http = require('http');
const server = http.createServer((req, res) => {
console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
res.writeHead(200, {'Content-Type': 'text/html'});
res.end('<h1>Hello from LiteBox!</h1><p>This Node.js server is running inside a sandboxed environment.</p>');
});
server.listen(3000, '10.0.0.2', () => {
console.log('Server running at http://10.0.0.2:3000/');
});
2. テストのキャッシュを活用してtarファイル作成
tar作成。
# テストで生成されたNode.js環境を再利用
% cd ~/litebox
% WORK_DIR=/tmp/litebox_webserver
% mkdir -p $WORK_DIR
% cd $WORK_DIR
# 既存のNode.js tarを展開
% tar -xf ~/litebox/target/debug/build/litebox_runner_linux_userland-*/out/rootfs_hello_node_rewriter.tar
# server.jsを追加
% cp /path/to/server.js out/
# 新しいtarを作成
% tar --format=ustar -cvf /tmp/webserver.tar lib64 lib lib32 out
3. iptables NAT設定(外部アクセス用)
NAT設定して外部からアクセス可能にします。
# IP転送を有効化
% sudo sysctl -w net.ipv4.ip_forward=1
# iptablesインストール(Amazon Linux 2023)
% sudo dnf install -y iptables-nft
# NAT設定
% sudo iptables -t nat -A PREROUTING -p tcp --dport 3000 -j DNAT --to-destination 10.0.0.2:3000
% sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
% sudo iptables -A FORWARD -i ens5 -o tun99 -p tcp --dport 3000 -j ACCEPT
% sudo iptables -A FORWARD -i tun99 -o ens5 -m state --state RELATED,ESTABLISHED -j ACCEPT
あとはAWSのセキュリティグループで↑のポート(3000)を開きます。
4. LiteBoxでWebサーバー起動
プログラム実行します。
% cd ~/litebox
% ./target/debug/litebox_runner_linux_userland \
--unstable \
--interception-backend rewriter \
--env "LD_LIBRARY_PATH=/lib64:/lib32:/lib" \
--env "HOME=/" \
--tun-device-name tun99 \
--initial-files /tmp/webserver.tar \
./target/debug/build/litebox_runner_linux_userland-*/out/node.hooked \
/out/server.js
5. 確認
curlでアクセスできることを確認しましょう。
# EC2内部から
% curl http://10.0.0.2:3000/
<h1>Hello from LiteBox!</h1><p>This Node.js server is running inside a sandboxed environment.</p>
# 外部から(ブラウザからも可能)
% curl http://<EC2 Public IP>:3000/
<h1>Hello from LiteBox!</h1><p>This Node.js server is running inside a sandboxed environment.</p>
LiteBoxサンドボックス内のNode.js Webサーバーに外部からアクセスできました。
Appendix : npm install
Litebox内でnpm installできればいろいろ検証できたりして便利では?とおもったけど、
駄目でした。(事前インストールしたパッケージは動作しますが)
| 操作 | 結果 | 原因 |
|---|---|---|
node --version |
✅ 動作 | - |
npm --version |
❌ エラー | Signal 11 (SIGSEGV) |
npm install |
❌ 動作せず | epoll_ctl mod未実装、DNS解決不可 |
| エラーメッセージ | 原因 |
|---|---|
WARNING: unsupported: epoll_ctl mod |
Node.jsのイベントループ(libuv)がepollの変更操作を使用するが、LiteBoxでは意図的に未実装 |
WARNING: unsupported: setsockopt(level=0, optname=11) |
一部のソケットオプションが未対応 |
WARNING: unsupported: shared futex |
スレッド間共有futexが未サポート |
getaddrinfo EAI_AGAIN |
DNS名前解決がサンドボックス内で機能しない |
-- Fatal signal Signal(6) |
上記の未サポート機能によりNode.jsランタイムがabort |
epoll_ctl modの実装コード(mod_interest()メソッド)は既に書かれているが、
#[expect(dead_code)]で意図的に無効化されている(epoll.rs:233-287)。
将来のリリースで有効化される可能性あり。
// epoll.rs:184 - 現在のコード
EpollOp::EpollCtlMod => {
log_unsupported!("epoll_ctl mod");
Err(Errno::EINVAL) // エラーを返す
}
// epoll.rs:233 - 実装は存在するが無効化中
#[expect(dead_code, reason = "currently unused, but might want to use soon")]
fn mod_interest(...) { ... }






