Provenanceって発音できる？Bates, et.al, Trustworthy Whole-System Provenance for the Linux Kernel [USENIX Security '15]
※この記事は情報セキュリティ系論文紹介 Advent Calendar 2015 - Adventarの17日目として執筆されました。ん、今日は26日だって？この記事は17日に書かれた、いいね？
はじめに
寒い日はコタツでRTSに限りますね、ゆずはらです。最近SteamでAoE2HDエディションがセールで500円ぐらいになってて、つい買ってしまったんです。寝る前に始めて、朝までやって・・・ゲフンゲフン。なんかholiday saleでまたSteam で 80% オフ:Age of Empires II HDすごい値段になってますね。高専のときに夏休み中AoCをやってたぐらいには好きなゲームなので、皆さんも是非。
さて、今回紹介するのは、USENIX Security'15で発表された、Trustworthy Whole-System Provenance for the Linux Kernel | USENIXについてです。といっても、slideを見てもらえばまぁ分かります。ただ、slideがすごくまとまりすぎてて、凄さが伝わらないスライドなので、そこを補う形で紹介していこうかなと思います。
まず、Data Provenanceって何？
はい、あまり聞き慣れない単語だと思います。provenanceは出自という意味で、originに近いところがあるかな？技術的にはInformation-flow controll/trackingと近いのですが、目的は「情報が誰によって作られ、誰によって操作（読み書き実行）されたものかmetadataを付加し、forensicやaccess controlに用いる」ためのものです。誰によって作られ、というところはどこから入手したか？と置き換えても良いですね。
この研究でやりたいこと
この研究の目標は、ファイルに属性を付けたり、作成ユーザの属性をLinuxカーネルレベルですべてトラッキングし、アクセス履歴をmetadataに突っ込んでいき、同時にアクセス制御をキメるというものです。このとき、問題になるのはトラッキングできるアクセス制御の粒度の細かさと、metadataの完全性（改ざんに対して耐性があるか）が保証できるか、というところです。前者においては、LPM（Linux Provenance Module）というLSMとは別のsystem call hooksを追加し、後者においてはLinux IMAという、通常はxattrとかプロセスのハッシュ値をTPMを用いて管理するセキュリティフレームワークを使って解決しています。また、これらの仕組みをrealな環境にdeployして動作させたよ！という、practicalな価値も強調しています。パフォーマンスも2.7%のオーバーヘッドしかないとか。マジかよすげえなって感じです。
この論文のすごいところ
ゴリゴリの実装と評価で、文句の付けようがない。OSカーネルレベルのInformation trackingはこれまでAsbestos [SOSP 2005], HiStar [SOSP 2006], Flume [SOSP 2007]などで提案されておりコンセプトは新しくないが、メタデータの完全性や正規表現ベースのポリシー記述など、practicalな有用性がある。・・・と解釈しました。まぁもう正直アクセス制御周りの話ってオワコン化してるところもあるので、これぐらいやらないとトップカンファレンスには通らないってことがハッキリわかんだね。
この論文でやり残しているところ
この手の話で問題になるのは、共有オブジェクトやデータバスをどう扱うか？ってところです。この論文のdiscussionにもあるけど、例えばX Window Systemはd-busで各プロセス間のメッセージ送受信を行うので、トラッキング時やそのトラッキング情報ベースでアクセス制御を書くときに非常に問題になります。実際は、トラッキングの粒度がプロセスではなくページング単位とか、mmapの境界ごとにアクセスをトラッキングするとかが必要になり、本論文でLinuxに元々あるセキュリティフックであるLSMとは別にフックを用意しているのは、この粒度の問題を解決するためですね。あ、Relay Bufferとして抽象化しているのかも。
まぁ2年前までやっていた研究（CiNii 論文 - 直感的ポリシー設定を可能にする動的な資源隔離機構）で、LSMベースでプロセス粒度のdata provenanceの研究やってて、このX Window Systemにハマって実装に詰まり、D課程のうちに博士が取れなかったんですけどね。しかたないね。
この研究はカーネルベースが2.6.32、つまりRHEL6で、systemdとかが適用されてないので、本当のd-busの恐怖を味わっていない可能性がありますね。ﾌﾌﾌ･･･
設計と実装について
USENIXの発表資料から図*1を拝借します。
Kernel側にあるのが、いわゆるリファレンスモニタ的なやつで、それをベースにしたファイルアクセス（実はファイルアクセスに限らず、ソケットとかメモリアクセスもだけど）のトラッキングとアクセス制御、及びmetadata（トラッキング情報）の保存をやっているようです。また、TPMを使ったLinux IMAで、トラッキング情報の完全性を保証しています。これは論文にも”やった”って書いてあるぐらいですが、基本的にはハッシュ値を使った完全性保護ですね。metadataはとにかくファイルアクセスごとに取れるので、結構扱いが難しいのですが、実装と評価ではftpっぽいファイル転送サービスへの適用例しかなく、あまり複雑な例はやってないっぽいので、性能評価もまぁ妥当なところでしょう。
まとめ
- 実装ゴリ押し論文である
- しかし、問題がクリアで、かつ実装でその解決を示しているところが評価されているのだと思う
- systemdとかになるとまた話は面倒なので、今から似た研究始める人は気をつけて、じゃないとしぬ
- TPM&IMAのあたりはもう「理論的にはこうできる」で片付けられず、ちゃんと実装しないと許されないのもしれない。でも実装結構大変だからゆるして。
以上です。最近は会社辞めた関係で、アンチアンチサンドボックスな研究がD審査に使えず、また、アクセス制御の研究を再開してなんとかDを取ろうって感じなので、こういう論文を読むと人生つらいですがｶﾞﾝﾊﾞﾘﾏｽ。
