Microsoft LiteBoxを動かしてみる

Microsoft LiteBoxを動かしてみる

2026.02.17

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 - LVBS
  • litebox_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(...) { ... }

参考リンク

この記事をシェアする

FacebookHatena blogX

関連記事