実行環境の隔離技術に関する調査

Transcript

1. 分離技術の安全性 • 実行環境の分離技術はいくつかある • JVM • コンテナ • VM • MicroVM • Unikernel • などなど… • どういう脅威モデルにおいてどれが最も安全？
2. 分離技術-JVM • Java バイトコードを JVM で解釈しながら実行 • 領域外アクセスは JVM がトラップしてくれる =スタック等の不正な領域操作による攻撃を阻止 • クラスごとにバイトコード署名可能 • クラスごとにアクセス権限を設定可能 • RMI, DMI などのリモートメソッドの実行機能 • 最近は Scala, Kotlin などの JVM 言語がある • 最近はJIT や SIMD 演算に対応して速くなったらしい
3. 分離技術-コンテナ • ホストのカーネルを利用した実行環境の分離 • 挙動としては chroot に似ている • jail(FreeBSD), LXC(Linux) などがある • Linux では以下の要素によって分離している • Namespaces: ホストとコンテナのプロセス空間を分離する • Control Groups: I/O や RAM などのリソースの制御をする • Capabilitis: ソケットなどに必要な権限を分割して特権を利用しないようにする • Secure Computation Mode: システムコールを制限する • ホストとカーネルを共有するため高速・軽量 • 標準のランタイムではセキュリティ的に不安なため、ユーザーランドでシ ステムコールを処理する gVisor もある
4. 分離技術-VM • ホスト OS と隔離された空間でゲスト OS を動かす • VMM, HyperVisor と呼ばれる基盤上でゲスト OS が動く • Xen, QEMU/KVM, BHyVe, Hyper-V, ESXi, VirtualBox などがある • 最近は仮想化支援技術(Intel-VTx, AMD-V など)により高速に動作する 物理マシン ホスト OS VMM ゲストOS アプリ ゲストOS アプリ 物理マシン HyperVisor ゲストOS アプリ ゲストOS アプリ
5. 分離技術-MicroVM • VM に関する既存技術には問題点がある • ゲスト OS をそのまま VM 上で動かすためサイズが大きい・非効率 • VMM 自体が大きい • 起動までに時間がかかる など • 仮想環境での実行に特化した VMM を作る • Amazon Firecracker, Intel Could HyperVisor など (Firecracker: Lightweight Virtualization for Serverless Applications, NSDI’20)
6. 分離技術-Unikernel • VMM, HyperVisor 上で動くことを目的として、アプリにきわめてシンプルな OS をくっつける • コード量の縮小 = バグなどによるセキュリティリスクの軽減 • MirageOS (Unikernels: Library Operating Systems for the Cloud, ACM SIGARCH 2013) OSv (OSv - Optimizing the Operating System for Virtual Machines, USENIX ATC ’14) などがある • 基本的に VMM によるメモリー空間の分離に頼る • OS と アプリ が空間を共有するバッサリと割り切った設計 • まだ黎明でセキュリティに関する議論には余地がある(いっぱい Unikernel が作られている段階)
7. まとめ 非言語依存 カーネルの分離 アプリの移植性 メモリ効率 権限管理 JVM × × 〇 〇 〇 コンテナ 〇 × 〇 〇 △ VM 〇 〇 〇 × △ MicroVM 〇 〇 〇 △ △ Unikernel △ 〇 × 〇 △
8. どれが一番安全？ • Container Security: Issues, Challenges, and the Road Ahead (IEEE, 2019) が参考になる
9. Application attacks container • 脆弱なアプリからコンテナを守れるのか？ • 基本的にアプリの脆弱性をつぶすことでしか対策できない • コンテナ側でアプリが利用する資源を制限することで軽減可能 • Linux Capabilities や コンテナ側のポリシーを利用する • コンテナランタイムの脆弱性なども(CVE-2017-5123) • JVM ではクラスごとにアクセス権限を設定可能 • でも JVM 自体にも脆弱性がある
10. Container attacks other containers • 脆弱なコンテナからほかのコンテナを守れるか？ • コンテナ間の分離に関する安全性 • 考えられる攻撃 • 信頼されていないコンテナイメージによる攻撃 • アプリの脆弱性による他コンテナへの DoS(SYN flood, ICMP flood) • コンテナ間のトラフィックの不十分な分離(ARP spoofing, DoS, port scan) • コンテナランタイムの脆弱性 • イメージの署名による信頼性の確認やネットワークの分離による対策が可能 • JVM は標準でバイトコード署名ができる • JVM はネットワーク周りの分離がしづらい(ホストのソケットを利用するため)
11. Container attacks the host • 脆弱なコンテナからホストを守れるか？ • 考えられる攻撃 • ホストの必要ないサービスへの攻撃 • ホストとカーネルを共有することによる脆弱性(container escape) • リソースの過剰使用 • ファイルシステムの脆弱性(ホストや他コンテナのファイルへアクセス) • コンテナがセキュリティ的に懸念が残る部分 • Seccomp によるシステムコールの制限やユーザーランドで システムコールをチェックする(gVisor) • VM ではゲストとホストでカーネルを分離するため安全 • デバドラなど準仮想化部分に存在する脆弱性からの VM escape • JVM はホストのプロセス分離に依拠する
12. Host attacks container • 脆弱なホストからコンテナを守れるか？ • 基本的に無理 • Intel SGX, ARM TrustZone などの TEE(Trusted Execution Environment) を利用した保護 • ハードウェアを信頼する仕組みだが、脆弱性が多数発見されている
13. 結論 • どの手法も脆弱性は存在する可能性がある • 汎用的にはカーネルをホストと分離しコンパクトな MicroVM が最も安全 • hardware-enforced isolation such as the use of SGX or EPT is fundamentally stronger than software-enforced isolation (containers/software LibOS) [A Binary-Compatible Unikernel(VEE ’19)] • 言語の仕様レベルで制限をかける JVM も割と安全? • IoT 分野ではほどほどの安全性で高速な コンテナ が使われることが多い • JVM with VM という選択肢もある • 攻撃された後の被害を最小化する → ネットワークのアクセス可能範囲の制限