動的にallow/denyできる ファイルサンドボックスを作る

Kernel/vm東京No.19 の発表です @nullpo_head

seccomp-notifyとlandlockをつかってseccom-brokered sandboxを作ります

Transcript

1. 動的にallow/denyできる サンドボックスを作る kernel/VM 探検隊東京 No.19 @nullpo_head 1
2. 怪談を話します、夏ですからね 2
3. ベッドの下の男 夜更けすぎ、友人がしつこく コンビニへ行こうと誘う。 あまりにしつこく誘うのでし ぶしぶ部屋を出る。 すると、友人は血相を変えて 「ベッドの下に包丁を握った 男がうずくまっている」と言 ったのだ。 3
5. サプライ チェーン に潜む男 だ！ 5
6. サプライチェーンに潜む男 $ curl https://foo/install.sh | bash 気になるプロダクトをインス トールする 果たしてシステムに変な変更 をしていないだろう か・・・？ や も・・・？ $ npm install $ pip install 6
7. シリコン製の猿の手 はなんでもやってくれる 途中で "No space left on device" エラーがあったようだ ん、最新のコマンドは ... ？ Agent $ rm -rf proj1 proj2 .. 7
8. シリコン製の 体 猿の手 週 先 た, はなんでもやってくれる 験し に 途中で 本 当 エラーがあったようだ た っ あ . ん、最新のコマンドは . . 話 い 怖 ？ Agent "No space left on device" $ rm -rf proj1 proj2 .. ... 8
9. ファイルアクセスを監視できる サンドボックスがほしい！ 9
10. NOTICE! Linux 今日はかなり面白い での新しい テクニックの話をします 10
11. 「新しい技術」にいたるまでに 「聞いたことないが界隈では常識」 の話がたくさん必要 11
12. だからまずたくさんの 「聞いたことないが常識らしいこと」に この部屋で追いついてもらいます 12
13. 「新しい技術」になったときに「これ だけは知らなかった！」とちゃんと驚 いてください！ 13
14. 常識的な主流のサンドボックス技術の問題点 14
15. 常識的な 主流のサンドボックス技術三選 Per-process Sandbox によく使われる技術 Seccomp-BPF Namespace Landlock 触れないもの VM は根本的に原理が違うので今回は除外します 15
16. Seccomp-BPF プロセスにClassic BPFで書かれたルールを課す システムコール番号の許可リストor拒否リストを実装する root も user namespace もいらない 弱点 パスをもとにファイルのフィルタリングは不可能 動的に許可・拒否を決定することはできない 16
17. Namespace プロセスを隔離されたネームスペースで動かす マウントネームスペースでファイルシステムを分離 ネットワークも隔離可能 サンドボックス系の実装で主流 弱点 、もしくはuser namespaceが必要（ubuntuでは無効） 動的に許可・拒否を決定することはできない root 17
18. Landlock プロセスにLandLock APIで書かれたルールを課す パスベースでファイルの許可リストを指定できる ポートベースでネットワークの許可リストを指定できる root も user namespace もいらない 弱点 あとからルールを緩和することができない 動的に許可・拒否を決定することはできない 18
19. まとめ 動的に許可・拒否をする仕組みがない 19
20. 常識 20
21. ここからが面白い新しい技術の話 21
22. Cage Box: a seccomp-brokered sandbox https://github.com/nullpo-head/cage-box つくりました。Brokered Sandbox 方式（勝手に名付けた） プロセスがファイルアクセスをするたびに許可/拒否できる ルールファイルにより、プロセスがアクセスするファイルをあらか じめ宣言することもできる その仕組みとは・・・？ 22
23. Seccomp-notify 23
24. Seccomp-notify の許可/拒否をBPFではなくIPCで他のプロセスに委譲でき る ユーザースペースなのでパスも読める しかも、許可/拒否だけでなくFile Descriptorを結果として返すこと ができる Seccomp (ADD_FD) これはかなりアツい！！！！ 24
26. Seccomp-notify 弱点：セキュリティサンドボックスに利用できない？ がわざわざ「セキュリティ用途には使うな」と言っている. なぜ？ 不可能ではないが、かなり丁寧に実装しないとバイパス手段が多い notify ではない新しい seccomp をインストールされる CONTINUE で許可を実装してしまうと TOCTOU 攻撃でスレッド からパスを変えられる システムコールベースなのでトラップ漏れや増減に弱い man 26
27. 解決策: Landlockと組み合わせる ですべてを拒否する Landlock 外の broker が、代わりにファイルを開いて FD をターゲッ トプロセスにinjectすることになる Broker が明示的に開いたファイルしかアクセスされないことが保証 される これをSeccomp-Brokered Sandbox方式と勝手に呼んでいます Landlock 27
29. Seccomp-Brokered Sandbox (seccomp notify + landlock) 方式: もUser namespaceも必要ない 動的にファイルアクセスをパスベースで許可/拒否できる TCP のホストベースでのフィルタリングも可能（ Cage Box は未実 装） Root すごい！！ 29
30. デモ 30
31. デモ: ルールベース すでにアクセス範囲が決まっているものはLandlockでカバーできる この場合はopenのパフォーマンスオーバーヘッドもない allow rx /home/nullpo/.cargo allow rwx /home/nullpo/dev allow rx /etc allow rx %system_libs allow rx %system_bins 31
32. 実装上のチャレンジ たくさんあるんですが10分なんではしょります 32
33. TOCTOU パスは検査時とopenしたときで常に変わる e.g. symbolic link の置き換え Open -> get the realpath of the fd -> 許可 / 拒否 -> その fd を返す の 順でやる 33
34. パスの意味 あるパスが指すファイルはプロセスによって異なる場合がある -> アクセスしたプロセスの への特殊なシンボリ ックリンク 実態のあるデバイスファイルであるにも関わらずなんと 誰が開いたかで結果が変わる 異なる mount namespaceにいるプロセスのパス (未実装) /proc/self /proc/< PID> /dev/tty 34
35. execve(path, ...) が代行できない ptrace を組み合わせて へと置き換える （ はFDを取る） それでも全拒否Landlockとexecveの組み合わせが悪い 紆余曲折ありFSのFDに対して できない memfd に execve 対象ファイルをコピーして注入して現在は実装 (proxy プロセスを起動する方式のほうがいいかもね ) Broker execveat execveat execveat 35
36. まとめ seccomp-brokered sandboxと seccomp notifyがアツい！ 36
37. 理想的なビジョン 配布されているすべてのソフトウェアがルールファイルを同梱して くれるといい ルールをチェックするだけで安全性が分かる ルールがないものは、interactive modeで実行して逐一安全性を確 認する それでできたルールを共有する場所があるといいね 37
38. まとめ2 Seccomp-Brokered Sandbox (seccomp notify + landlock) 方式: もUser namespaceも必要ない 動的にファイルアクセスをパスベースで許可/拒否できる TCP のホストベースでのフィルタリングも可能（ Cage Box は未実 装） Root すごい！！ 38