Download as PDF, PPTX
iOS/macOSとAndroid/Linuxのサンドボックス機構について調べた
- 1.
- 2.
- 3. そもそもの疑問 ● 誰がfork(2)を無効化しているのか？ ● どんな仕組みなのか？ 3 「AppSandbox」が特定システムコールを無効化
- 4. 本日の内容 ● iOS/macOSの「App Sandbox」 ○アプリケーション用サンドボックス機構 ● Android/Linuxの「seccomp」 ○ システムコールを制限する仕組み ● どちらも情報が少ないので調査した ○ 注：chrootとかcgroupsとかの話はしません 4
- 5. 話題1：App Sandbox (a.k.a.Seatbelt) ● iOSアプリの機能を制限する仕組み ● macOS上にも存在 ○ Mac OS X Lion（10.8）から導入 ○ iOS版のサブセットらしい 5
- 6.
- 7.
- 8. App Sandbox 概要 ●iOS/macOS上のsandbox環境 ○ storeアプリは全てsandbox配下 ● システムコールをフック ○ DSLでフィルタを記述 ● 構成 ○ カーネル拡張 ○ デーモン ○ ライブラリ 8 （iOS Hacker’s Handbook より引用）
- 9. sandboxに対するAppleのスタンス ● macOSアプリ ○ store審査でsandbox化必須 ○GUIから設定する前提 ● iOSアプリ ○ 勝手にsandbox下で起動される ○ 開発者は対応作業なし ● 技術の詳細は非公開 ○ Cインターフェースが最近 deprecatedになった 9 （XcodeのmacOSアプリの設定）
- 10. sandbox_init(3) (deprecated) ● 権限を自ら捨てる ●権限の詳細は「プロファイル」で指定 ● プロファイルの種類 ○ カスタムプロファイル ○ ビルトインプロファイル ● 実験コード：https://github.com/hnw/apple-sandbox-test 10
- 11. カスタムプロファイル ● SBPL (SandboxProfile Language)で記述 ○ 許可・拒否のルールを記述するDSL ○ 内部的にはカスタムのScheme処理系で処理 ● 手元のmacOSにもある ○ /usr/share/sandbox/*.sb ○ /System/Library/Sandbox/Profiles/*.sb 11
- 12. カスタムプロファイルの文法 12 ● システムコールを複数束ね て許可・拒否を記述 ○ 例：「process-fork」 ●引数でフィルタ指定可能 ○ 例：「file-read-data」 ○ 正規表現マッチも可能
- 13. ビルトインプロファイル ● 定義はsandboxd内に存在 ○ バイナリ化されており読み出しは困難 ○古いバージョンの定義は解析されている ● iOSアプリはビルトインプロファイル 「container」下で動作 ○ プロセス起動の禁止を実現している 13
- 14. App Sandboxまとめ ● システムコールをフィルタする仕組み ○フィルタはDSLで定義、記述力は高い ● ファイルのアクセス制限も担当 ○ Linuxなら別の仕組み（SELinux）で実現するところ ● 開発環境やStore審査など仕組みで強制 ○ 開発者が自由に使うことは想定外? 14
- 15. 話題2：seccomp ● システムコールのフィルタリング機構 ○ Linux3.5から導入、多くの環境でデフォルト有効 ○ Android 7.0以降、全端末で有効 ○ バックエンドにBPFを利用 15
- 16. BPF (Barkley PacketFilter) ● パケットフィルタに特化したVM(?) ○ レジスタマシン（レジスタ数2） ○ フィルタとしてVM命令列を与える ○ JITコンパイルされるので高速、らしい →高速かつ記述力が高いのでseccompでも採用 16
- 17. BPFの例 17 ● フィルタ条件を記述 ● 大半の人類には難易度が高い （「LinuxのBPF: (1) パケットフィルタ - 睡分不足」より引用）
- 18. libseccomp ● seccompを扱いやすくするライブラリ ○ https://github.com/seccomp/libseccomp ○素のseccomp/BPFは使いたくないでござる ● 各言語のバインディングも存在 ○ Go / Perl / mruby ○ Python版はlibseccomp同梱 18
- 19. libseccompを試す(1) ● 実験コード ○ https://github.com/hnw/seccomp-test ●利用の流れ ○ seccomp_init() ：初期化 ○ seccomp_rule_add()：ルール追加 ○ seccomp_release()：ルールに従って権限を捨てる 19
- 20. libseccompを試す(2) ● 実際にコードを書いてみると結構面倒 ○ デフォルトdeny・必要分だけallowしていく ○Cライブラリ関数の内部でどのシステムコールが呼ばれ るか自明でない →何度も実行して試行錯誤するしかない ○ プリセットの定義があれば楽なのになぁ… 20
- 21. seccompの能力(1) ● 任意のシステムコールをフック ● マッチした場合に次の処理ができる ○問答無用でプロセスごとKILL ○ シグナルを投げる ■ シグナルハンドラで任意の処理を行う ○ 任意のerrnoを返す 21
- 22. seccompの能力(2) ● syscall引数（64bit int）の値による分岐 ○EQ / NE / LE / GE / MASKED_EQ など ■ 例：open()でO_WRONLYが指定されたらKILL ○ 文字列比較はできない 22
- 23. seccompの適用例 ● 権限を捨ててから危険な処理を行う ○ 例：Chrome20からFlash pluginがseccomp下で動作 ○ 脆弱性があった場合の被害を最小化する目的 ○ 3rd partyモジュールを実行するような場合に最適 23
- 24. Android 7.0とseccomp ● 現状、大多数のアプリとseccompは無関係 ○AOSPを見てもほとんど使われていない ○ App Sandboxのような利用は現時点では見られない ● 使いたい人が使えるようにしたという理解 ○ 今のところChromeくらい 24
- 25. まとめ(1) ● 「sandbox的な機構が両OSにあるぞ！」と思っ て調べてみたら運用方針が全く違った ○ iOS/macOS：3rdpartyアプリの不正を防ぐ、強制 ○ Android/Linux：安全性向上の仕組みを提供、任意 ● 優劣の話ではなく、役割が違う ○ Androidだとファイルアクセス制御はSELinuxが担当 25
- 26. まとめ(2) ● SELinuxは今後も現役、seccompと補完関係 ○ 調べる前はSELinuxを殺しに来たかと思った ○SELinux：管理者が頑張る・ファイルアクセス特化 ○ seccomp：開発者が頑張る・細かい制御は不向き 26
- 27.
- 28.
- 29.