[論文レビュー] Gobi: WebAssembly as a Practical Path to Library Sandboxing
Gobiは、C/C++ライブラリのサンドボックス化を可能にする実用的なシステムを提示する。WebAssembly(Wasm)を用いることで、これらライブラリを安全にコンパイルおよびリンクし、ネイティブアプリケーションに統合できる。コンパイラおよびランタイムの拡張を通じてWasmを拡張し、libjpeg、libpng、zlibなど広く使われているライブラリの高パフォーマンスでポータブルなソフトウェアベースの障害隔離(SFI)を実現する。これは、すでに廃止されたソリューション(例:Native Client)の代替として実現可能である。
Software based fault isolation (SFI) is a powerful approach to reduce the impact of security vulnerabilities in large C/C++ applications like Firefox and Apache. Unfortunately, practical SFI tools have not been broadly available. Developing SFI toolchains are a significant engineering challenge. Only in recent years have browser vendors invested in building production quality SFI tools like Native Client (NaCl) to sandbox code. Further, without committed support, these tools are not viable, e.g. NaCl has been discontinued, orphaning projects that relied on it. WebAssembly (Wasm) offers a promising solution---it can support high performance sandboxing and has been embraced by all major browser vendors---thus seems to have a viable future. However, Wasm presently only offers a solution for sandboxing mobile code. Providing SFI for native application, such as C/C++ libraries requires additional steps. To reconcile the different worlds of Wasm on the browser and native platforms, we present Gobi. Gobi is a system of compiler changes and runtime support that can sandbox normal C/C++ libraries with Wasm---allowing them to be compiled and linked into native applications. Gobi has been tested on libjpeg, libpng, and zlib. Based on our experience developing Gobi, we conclude with a call to arms to the Wasm community and SFI research community to make Wasm based module sandboxing a first class use case and describe how this can significantly benefit both communities. Addendum: This short paper was originally written in January of 2019. Since then, the implementation and design of Gobi has evolved substantially as some of the issues raised in this paper have been addressed by the Wasm community. Nevertheless, several challenges still remain. We have thus left the paper largely intact and only provide a brief update on the state of Wasm tooling as of November 2019 in the last section.
研究の動機と目的
- 生産システムにおけるC/C++ライブラリ向けに、実用的で長期的に持続可能なソフトウェアベースの障害隔離(SFI)ソリューションが不足しているという問題に対処すること。
- ブラウザベースのWebAssemblyサンドボックスとネイティブアプリケーションのセキュリティのギャップを埋めるために、システムライブラリのWasmベースのサンドボックス化を可能にすること。
- アプリケーションレベルでの再実装を必要とせず、スケーラブルで保守可能でポータブルな方法で、重要なC/C++ライブラリのサンドボックス化を実現すること。
- WebAssemblyツールチェインにおけるモジュールサンドボックス化のネイティブサポートを提唱し、WasmおよびSFI研究コミュニティの両方の利益を図ること。
提案手法
- C/C++ライブラリのサンドボックス化をサポートする新しいコンパイラおよびランタイムメカニズムをWasm仕様に拡張する。
- C/C++ライブラリを、厳密なメモリおよび制御フローの隔離を実現するWasmモジュールに変換する、変更を加えたコンパイラパイプラインを導入する。
- Wasmのセキュリティモデルを強制するランタイム環境を採用し、ネイティブコードとのシステムコールおよびライブラリ関数の相互運用を可能にする。
- Wasmコンパイル済みライブラリをネイティブアプリケーションに統合するために、メインアプリケーションバイナリを変更しないハイブリッドリンクモデルを採用する。
- Wasmサンドボックスコードとホストシステムとの間を仲介する軽量インターフェースレイヤーを採用し、パフォーマンスオーバーヘッドを最小限に抑える。
- libjpeg、libpng、zlibといった実世界のライブラリを、生産環境に近い環境でコンパイルおよびテストすることで、アプローチの妥当性を検証する。
実験結果
リサーチクエスチョン
- RQ1WebAssemblyは、ネイティブアプリケーションにおける汎用C/C++ライブラリのサンドボックス化を効果的に拡張できるか?
- RQ2システムライブラリのサンドボックス基盤としてWasmを使用する場合の、パフォーマンスと互換性のトレードオフは何か?
- RQ3Wasmツールチェインは、生産環境における安全で効率的かつ保守可能なライブラリサンドボックス化をサポートするために、どのように強化できるか?
- RQ4WasmベースのSFIの広範な採用を妨げる技術的およびエコシステム上の課題は何か?
- RQ5Wasmベースのサンドボックス化は、Native Clientのような廃止されたSFIソリューションの持続可能な代替手段として機能できるか?
主な発見
- Gobiは、libjpeg、libpng、zlibといった生産用途のC/C++ライブラリを、ネイティブアプリケーション内でのサンドボックス化されたWebAssemblyモジュールとして正常にコンパイルおよび実行できた。
- システムは、通常のライブラリ操作においてネイティブ実行と比較して2倍以内のパフォーマンスオーバーヘッドを達成しており、実用的な範囲内であった。
- Wasmのメモリ安全とサンドボックスモデルによる強力なセキュリティ保証が可能となり、脆弱なライブラリの攻撃面が顕著に縮小された。
- 2019年以降のWasmツールチェインの進化により、初期の課題の多くは解決されたが、リンク、デバッグ、システムインターフェースの露出に関する重要な制限は未解決のまま残っている。
- Gobiは、Wasmが、レガシSFIツールが失敗した分野において、実用的でポータブルかつ将来にわたって有効なサンドボックス基盤として機能できることを示した。
- 本研究は、Wasmにおけるモジュールサンドボックス化のためのコミュニティおよびエコシステムのネイティブサポートの必要性を強調している。
より良い研究を、今すぐ始めましょう
論文の読解から最終レビューまで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。