> [!abstract] 概要 > Linux を中心に発展してきたコンテナは、軽量な仮想化と利便性の高まるエコシステムにより、クラウドにおいて重要な潮流となっている。しかし、コンテナ化の緩やかな隔離は、下位の Linux カーネルにおける攻撃面をもたらす。従来の VM やアプリケーションカーネルによる仲介など、他の仮想化技術をサンドボックス化と組み合わせると、コンテナの軽量かつスケーラブルな性質を損なう恐れがある。本研究では、攻撃者がコンテナを Linux に依存しているとほとんど仮定しているという事状に着目し、軽量サンドボックス化への別のアプローチを提案する。Linux コンテナを FreeBSD カーネルへ移植(transplant)することで、Linux に由来する主要な脆弱性攻撃を回避できる。さらに、FreeBSD 独自のサンドボックス機構である Capsicum を移植されたコンテナに透過的に適用することで、隔離を強化できる。本論文は、Linux コンテナが直面する脆弱性を分析し、Linux コンテナを FreeBSD へ移植する際の技術的課題を特定し、Linux アプリケーションに Capsicum サンドボックスを透過的に適用する仕組みを設計することで、アプローチの実現可能性を検討する。 ## 論文情報 - タイトル: Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing - 著者: [[Yuki Nakata]] ([[SAKURA internet Inc.]]), [[Shintaro Suzuki]] ([[Future University Hakodate]]), [[Katsuya Matsubara]] ([[Future University Hakodate]]) - 媒体: 14th ACM SIGOPS Asia-Pacific Workshop on Systems ([[APSys]] ’23) - 発表: 2023-08-24, Seoul, Republic of Korea - DOI: 10.1145/3609510.3609820 - ページ数: 7 ## 概要 本論文は、Linux コンテナを [[FreeBSD]] カーネル上で実行し、Linux カーネル固有の脆弱性攻撃を回避するとともに、FreeBSD の capability-based サンドボックス機構 [[Capsicum]] を透過的に適用する **Container Transplantation** を提案する。従来の VM ベース([[Kata Containers]])やユーザ空間カーネルベース([[gVisor]])のサンドボックスが性能・起動時間のオーバーヘッドを伴うのに対し、本手法は OS カーネル内でのシステムコール変換に限定したプリミティブなエミュレーションを用いるため、コンテナ本来の軽量性とスケーラビリティを維持することを目指す。(Source: §1, §3.2) ## 問題設定 ### Linux コンテナの攻撃面 Linux コンテナは [[Linux]] の namespace と cgroup によりプロセス・ファイルシステム・ネットワーク・ユーザ空間を分離するが、**ホスト OS カーネルは共有**している。したがって、Linux カーネル自体の脆弱性は、コンテナ脱出や権限昇格を通じて全コンテナとホストに影響する。(Source: §1) 論文は Linux カーネル脆弱性を以下の 3 カテゴリに分類する。(Source: §2) | カテゴリ | 攻撃内容 | 例 | |---|---|---| | CPU 処理 | CPU 枯渇による DoS、CPU 保護機構回避、情報窃取 | CVE-2020-27825, Meltdown | | メモリ処理 | 初期化・境界処理の不備による情報窃取、権限昇格、メモリ書き換え | CVE-2016-4486, CVE-2019-9213, CVE-2016-5195(Dirty COW), CVE-2017-1000405 | | ファイル処理 | ファイルディスクリプタの不備による DoS・権限昇格 | CVE-2017-10661 | ### 既存アプローチの限界 - **Kata Containers**: VM 内でコンテナを実行し、OS カーネルを隔離する。隔離は強いが、VM 起動時間と性能オーバーヘッドが大きい。 - **gVisor**: ユーザ空間カーネルがシステムコールをインターセプトし、ホストカーネルへの攻撃面を削減する。しかし、ユーザ空間とカーネル空間間のコンテキストスイッチが性能を低下させる。 いずれも「コンテナの軽量性」と「堅牢な隔離」のトレードオフを緩和しきれていない。(Source: §1) ## 提案手法 ### Container Transplantation のアイデア Container Transplantation は、**Linux コンテナを別 OS(FreeBSD)上で互換実行**させることで、Linux カーネル固有の脆弱性攻撃を無力化する。攻撃者が Linux カーネルの脆弱性を狙ってきた場合、FreeBSD カーネル上では該当の脆弱性が存在しないため、攻撃そのものまたは攻撃コードの実行が失敗する。これは一時的な異種 OS 移行による脆弱性窓口の緩和と同じ効果を期待する。(Source: §3.2) ### 機能要件 論文はコンテナサンドボックスに対して以下の 4 要件を定義する。(Source: §3.1) - **R1: OS カーネル脆弱性の攻撃防止・緩和**: 既知の脆弱性を防止するか、攻撃成功までの時間を従来コンテナに比べて十分に遅らせる。Linux カーネル実装に依存する脆弱性を対象とする。 - **R2: 計算資源制限と実行環境隔離**: CPU・メモリ上限、ファイルアクセス制限、プロセス・ユーザー情報の隠蔽、特権機能へのアクセス制限など、従来コンテナと同等の機能を提供する。 - **R3: 細粒度な資源アクセス制限**: 不要なシステムコールや無効な引数、特定内容のパケット・ファイルへのより細かいアクセス制限により、攻撃面を削減する。 - **R4: 性能と特性のオーバーヘッド最小化**: 上記の隔離を実現しつつ、性能と起動時間への影響を最小化する。 ### 実装設計 プロトタイプは FreeBSD 13.1-RELEASE 上で、Linux バイナリ互換実行機能 [[Linuxulator]] とプロセス隔離機能 [[Jail]] を組み合わせて Linux コンテナを実行する。(Source: §4, §5.2) #### システムコールエミュレーション [[Linuxulator]] は FreeBSD カーネル機能であり、Linux バイナリから発行されるシステムコールをカーネル内で FreeBSD のシステムコールに変換する。これにより、ユーザ空間でシステムコールをインターセプトする方式に比べ、性能オーバーヘッドを低減できる。(Source: §4.1) #### プロセス隔離の互換性 Linux の namespace と FreeBSD の Jail は以下の点で異なるが、いずれも対応可能である。(Source: §4.2) - **プロセス ID**: Linux namespace は PID1 から割り当てるのに対し、Jail はホストと隔離環境を通じて連続的に PID を割り当てる。コンテナでは PID1 が init ではなくアプリケーションプロセスとなるため、動作に影響しない。 - **ユーザ隔離**: Linux namespace は UID/GID を内外で異なる値にマッピングするのに対し、Jail は同一 OS 内で重複しうる。Sandbox 内で UID/GID を管理し重複を防ぐ必要がある。 #### Capsicum の透過的適用 FreeBSD の capability-based セキュリティ機構 [[Capsicum]] は、ファイルディスクリプタに改ざん不可能な権限トークンを与え、アプリケーションが許可された資源のみにアクセスできるようにする。しかし、通常はアプリケーション修正と事前の権限取得が必要であり、未修正の Linux バイナリには適用しにくい。(Source: §4.3) 本手法は以下の 2 つの仕組みで透過適用を実現する。 - **libpreopen**: アプリケーションが使用する OS 資源に関連するファイルディスクリプタを事前に開き、標準 C ライブラリに保存する。これにより、サンドボックス化後もアプリケーション修正なしに資源にアクセスできる。 - **Casper**: 動的な資源アクセスを、安全性を保ちつつプロキシ実行する。専用ライブラリ関数を呼び出す必要があるが、本手法は動的アクセス制御を必要とするシステムコールを、標準 C ライブラリ内のプロキシ実行関数にリダイレクトすることで、アプリケーションコードの修正を不要にする。 **Figure 1: 提案サンドボックス機構** ![[_attachments/3609510.3609820/fig01-sandboxing-mechanism.png]] (Figure 1. 提案するサンドボックス機構の全体像。Linux Rootfs 上のアプリケーションバイナリを Linuxulator でシステムコール変換しつつ、Jail と資源制限で隔離し、Capsicum により Sandboxed Container Process を構成する。動的資源アクセスは Casper プロセスが代理実行する。Source: §4.3) ## 新規性 - **異種 OS 間コンテナ移植による攻撃面削減**: VM による完全隔離やユーザ空間カーネルによるシステムコール再実装とは異なり、**異なる OS カーネル実装への移植**で Linux 固有の脆弱性を自然に無力化する。 - **FreeBSD 独自セキュリティ機構の Linux バイナリへの透過適用**: Capsicum を Linux アプリケーションにコード変更なしで適用する仕組みを設計した。 - **カーネル内エミュレーションによる軽量性**: ユーザ空間カーネル方式と異なり、カーネル内でのシステムコール変換に限定したプリミティブなエミュレーションにより、コンテナの起動時間と性能を維持する。 ## 実験設定 ### 貫通テスト Linux カーネル固有の脆弱性を悪用するプログラムを、FreeBSD の Linuxulator 上で実行し、攻撃が防止されるかを評価した。(Source: §5.1) **Table 1: 主要な Linux 脆弱性に対する貫通テスト結果** | CVE ID | 脆弱性の詳細 | 結果 | |---|---|---| | CVE-2016-9793 | カーネル関数の脆弱性を悪用した DoS 攻撃 | ✓ (防止) | | CVE-2016-5195 | Dirty COW | ✓ (防止) | | CVE-2017-1000405 | Huge Dirty COW | ✓ (防止) | | CVE-2017-10661 | ファイルディスクリプタの脆弱性を悪用した DoS・権限昇格 | ✓ (防止) | | CVE-2016-4486 | メモリ初期化の脆弱性を悪用した情報窃取 | △ (FreeBSD 未実装のため実行不可) | | CVE-2019-9213 | メモリ境界チェックの脆弱性を悪用した情報窃取 | △ (FreeBSD 未実装のため実行不可) | ![[_attachments/3609510.3609820/table01-penetration-testing.png]] (Table 1. Linux カーネル固有の脆弱性を悪用した攻撃プログラムを FreeBSD/Linuxulator 上で実行した結果。✓ は Linux の脆弱性を悪用した攻撃を防止、△ は FreeBSD に未実装の機能のため攻撃コードが実行できなかったことを示す。Source: §5.1, Table 1) ### 性能評価 UnixBench を用いて、システムコールと OS 関数呼び出しの性能オーバーヘッドを測定した。(Source: §5.2) - **OS 環境**: FreeBSD 13.1-RELEASE(Linuxulator がエミュレートするカーネルは Linux 3.17), Ubuntu 18.04 の Linux Rootfs - **ハードウェア**: Intel i5-4278U, 16 GB RAM - **比較対象**: runC 1.1.5, gVisor release-20230417.0, Kata Containers 1.13.0-alpha, Linuxulator with Jail - **測定項目**: execl スループット、pipe スループット、pipe context switching、process creation、system call overhead **Figure 2: システムコールベンチマークスコア** ![[_attachments/3609510.3609820/fig02-system-call-benchmark.png]] (Figure 2. UnixBench によるシステムコールベンチマーク比較。縦軸はスコア(高いほど良い)。Linuxulator with Jail は gVisor より小さい性能低下で、いくつかの項目では runC と同等以上のスコアを示した。Source: §5.2, Figure 2) ## 実験結果 ### 貫通テスト - CVE-2016-9793, CVE-2016-5195, CVE-2017-1000405, CVE-2017-10661 の 4 件について、Linuxulator 上で Linux カーネル固有の脆弱性を悪用した攻撃が**防止された**。 - CVE-2016-4486 と CVE-2019-9213 については、攻撃コードが FreeBSD 未実装の Linux カーネル機構に依存していたため、**実行自体が失敗した**。この結果も Container Transplantation の効果を示している。(Source: §5.1) ### 性能評価 Linuxulator with Jail は、gVisor より小さい性能低下を示した。(Source: §5.2) - **システムコールオーバーヘッド**: gVisor は runC に対して **96% 悪化**したのに対し、Linuxulator with Jail は **22% 悪化**に抑えられた。 - **execl スループット**: Linuxulator with Jail は runC よりも高いスコアを示した。これは OS 実装の差によるもので、純粋なオーバーヘッドはこれより小さい可能性がある。 - gVisor はユーザ空間でシステムコールをインターセプト・リダイレクトする際に大量のコンテキストスイッチが発生した。本手法は同様にシステムコールをインターセプトするが、カーネル空間内で変換するためコンテキストスイッチコストを避けられる。 ## 考察 ### 軽量性の根拠 Linuxulator はカーネル内で Linux システムコールを FreeBSD のシステムコールに変換する。これにより、gVisor のようなユーザ空間カーネル方式で生じるカーネル・ユーザ空間間のコンテキストスイッチが発生せず、軽量なサンドボックス化が可能となる。(Source: §5.2) ### 互換性の限界 Linuxulator は **ABI 互換**を持つが、**カーネル互換**は持たない。本プロトタイプは 65 の Linux システムコールをサポートしていない。未対応なシステムコールの多くは、madvise や io_uring などの高速化・最適化目的のもの、reboot や swapoff などのシステム管理目的のものである。したがって、高度に最適化・加速されたミドルウェアや汎用 VM としての用途には向かない。一方、Web アプリケーションの実行環境としては十分である可能性がある。(Source: §6) ### 新たな攻撃面 Container Transplantation では、攻撃者がコンテナが異種 OS 上でエミュレートされていることを認識し、**FreeBSD や Linuxulator 自体の脆弱性**を狙う可能性がある。これを緩和するため、実行環境の振る舞いからホスト OS を特定できないようにする必要がある。また、Capsicum などの厳格なアクセス制御機構を併用することで、攻撃者が権限を得た後の影響を抑えることができる。(Source: §6) ## 強み / 弱点・課題 **強み**: - Linux カーネル固有の脆弱性を回避しつつ、VM やユーザ空間カーネルより軽量なサンドボックス化を実現する。 - FreeBSD 独自の capability-based セキュリティ機構を活用し、コンテナの隔離強度を高める。 - カーネル内システムコール変換により、ユーザ空間カーネル方式のような大きなコンテキストスイッチオーバーヘッドを回避する。 **弱点・課題**: - プロトタイプであり、Linux コンテナランタイムとしての完成度は不十分。将来の課題として nginx など実用的アプリケーションでの評価が挙げられている。 - Linuxulator の未対応システムコールにより、高度に最適化されたアプリケーションや一部のミドルウェアが正常に動作しない可能性がある。 - ホスト OS(FreeBSD/Linuxulator)自体の脆弱性が新たな攻撃面となる。 - ABI 互換はあるがカーネル互換はないため、Linux カーネル固有の機能に依存する攻撃の防止効果はある一方、完全な Linux 互換性は担保されない。