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 Systemd-busで各プロセス間のメッセージ送受信を行うので、トラッキング時やそのトラッキング情報ベースでアクセス制御を書くときに非常に問題になります。実際は、トラッキングの粒度がプロセスではなくページング単位とか、mmapの境界ごとにアクセスをトラッキングするとかが必要になり、本論文でLinuxに元々あるセキュリティフックであるLSMとは別にフックを用意しているのは、この粒度の問題を解決するためですね。あ、Relay Bufferとして抽象化しているのかも。

まぁ2年前までやっていた研究(CiNii 論文 -  直感的ポリシー設定を可能にする動的な資源隔離機構)で、LSMベースでプロセス粒度のdata provenanceの研究やってて、このX Window Systemにハマって実装に詰まり、D課程のうちに博士が取れなかったんですけどね。しかたないね。

この研究はカーネルベースが2.6.32、つまりRHEL6で、systemdとかが適用されてないので、本当のd-busの恐怖を味わっていない可能性がありますね。フフフ・・・

設計と実装について

USENIXの発表資料から図*1を拝借します。f:id:yuzuhara:20151226193007p:plainKernel側にあるのが、いわゆるリファレンスモニタ的なやつで、それをベースにしたファイルアクセス(実はファイルアクセスに限らず、ソケットとかメモリアクセスもだけど)のトラッキングとアクセス制御、及びmetadata(トラッキング情報)の保存をやっているようです。また、TPMを使ったLinux IMAで、トラッキング情報の完全性を保証しています。これは論文にも”やった”って書いてあるぐらいですが、基本的にはハッシュ値を使った完全性保護ですね。metadataはとにかくファイルアクセスごとに取れるので、結構扱いが難しいのですが、実装と評価ではftpっぽいファイル転送サービスへの適用例しかなく、あまり複雑な例はやってないっぽいので、性能評価もまぁ妥当なところでしょう。

 

まとめ

  • 実装ゴリ押し論文である
  • しかし、問題がクリアで、かつ実装でその解決を示しているところが評価されているのだと思う
  • systemdとかになるとまた話は面倒なので、今から似た研究始める人は気をつけて、じゃないとしぬ
  • TPM&IMAのあたりはもう「理論的にはこうできる」で片付けられず、ちゃんと実装しないと許されないのもしれない。でも実装結構大変だからゆるして。

 

以上です。最近は会社辞めた関係で、アンチアンチサンドボックスな研究がD審査に使えず、また、アクセス制御の研究を再開してなんとかDを取ろうって感じなので、こういう論文を読むと人生つらいですがガンバリマス。

 

 

Anti-ROP祭りだぜ!USENIX Security2014 ROP: Return of the %edi

この記事はシステム系論文紹介 Advent Calendar 2014 21日目として書かれました。ん、今日は大晦日?えっなんだって?

はじめに

こんばんは。
Dを単位取得退学(自称)して就職し、今は東京の片隅で毎日パワポを作っています、id:yuzuharaです。
 
そんなことはさておき、今年のUSENIX SecurityではなんとROPに関する研究が4つもacceptされており、ROP: Return of the %ediというスターウォーズのタイトルをもじったセッションがありました。
  • ROP is Still Dangerous: Breaking Modern Defenses [N. Carlini et al.]
  • Size Does Matter: Why Using Gadget-Chain Length to Prevent Code-Reuse Attacks is Hard [E. Goktas et al.]
  • Oxymoron: Making Fine-Grained Memory Randomization Practical by Allowing Code Sharing [M. Backes et al.]
  • Stitching the Gadgets: On the Ineffectiveness of Coarse-Grained Control-Flow Integrity Protection [L. Davi et al.]
 
せっかくなのでこのセッション全体をざっくり紹介し、今Anti-ROP界隈がアツいぜ!というのを共有できればいいなと思います。
 

不正実行とそれに対する防御の歴史

ROPの話をする前に、いわゆるソフトウェアセキュリティ一般の話をざっと概略してみます。とりあえず、今までにどのような不正実行のテクニックがあり、それを防御する仕組みが採用されてきたか、というのを簡単に時系列にしてみました。代表的なものだけリストアップしています。
  • (攻)Stack overflow
  • (防)Stack smashing Protection
  • (攻)Heap overflow
  • (防)Data Execution Prevention(DEP) [Microsoft 2004]
  • (攻)Return to Libc
  • (防) Address space layout Randomization (SLR) [2005?-]
  • (攻)Return oriented programming [SHACHAM H, CCS’07]
  • (防)Control-flow integrity [M Abadi, CCS’05]
  • (攻)Jump Oriented programming
  • (防)Branch History Inspection(kBouncer)[V.Pappas et.al., SEC’13]
  • (攻)Sigreturn Oriented programming [E Bosmon, Oakland’14]
 
※攻撃(attack)の対義語は防御(defense)です。
なんというか、10年間で攻撃手法も保護も大きく変わりましたね・・・
 

ROP 防御の最新研究

kBouncer [V. Pappas et al., USENIX Security’13]
LBR(Last Branch Record)を使い、APIの呼び出し経路をチェックする方法が提案されています。この分岐ログを使った検知方法は、今回の4つの論文に大きな影響を与えています。
ROPecker [Y. Cheng et.al., NDSS'14]
kBouncerのようなLBRを使ったROP検出と合わせて、メモリを4,8KBのセグメントに区切り、そのブロックを越えるindirect jumpのチェインが一定数以上だとROPと見なす手法を提案しています。要するに、jumpの ”距離”に注目したROP検出です。
ただし、この”距離”のしきい値が経験的な値であり、ぬけ穴であるという検証が、次に出てくる論文で行われています。しかし、サイクル早すぎだろオマエら。
 

イカしたAnti-ROP論文紹介するぜ!

ROP is Still Dangerous: Breaking Modern Defenses 
この論文ではまず、既存のROP検出技術に対する3つの攻撃原理を定義しています。
  1. Call-Preceded ROP
    普通のプログラムなら、retの戻りアドレスの一つ前の命令はcallのはず、というチェックをしているROP guardは多い。kBouncerがそれにあたる。70KB以上のUbuntuシステムプログラムを解析したら、70KBより大きいプログラムは10個中10個そういうgadgetが見つかった。回避余裕でした。
  2. Evasion Attacks
    実行中のコードはROP Gadgetなのか、正常なコードの断片なのか?の判定基準は難しい。実行している命令のセグメントが短く飛び飛びに実行していればROPと判断する方法があるが、ROP Gadgetのサイズが大きいものがあると意味が無い。
  3. History Flushing分岐命令の履歴を使ってindirect jump元がROPガジェットぽかったら検知というロジックもあるが、no-opな命令実行で埋め尽くせば、検知しづらくできる。
結論
この論文では、kBouncerとROPeckerそれぞれに対し、上記のprimitivesに対応するROP攻撃を行っています。そしてkBouncer、ROPecker共に突破できたと報告があります。そして次に、kBouncer、ROPeckerを改良して、突破されないようにできた、とありました。しかしそれでも、長いROPガジェットがある場合は、提案手法でも検知できないそうです。
Size Does Matter: Why Using Gadget-Chain Length to Prevent Code-Reuse Attacks is Hard
過去に提案されているROP defenses(kBouncer, ROPecker)では、ROP gadgetのサイズと、chain数のしきい値に経験的な値を使っています。この研究では、IE8でASLR, DEP, kBouncerを回避するROPを作れるか検証しています。どうも長いROP gadgetが普通にあったのでそれを使ったらしいです。長いROP gadgetを使うと、こういう経験的なしきい値に基づくROP検知は余裕で突破できてしまうようです。
 
この論文のコントリビューションは、新しい仕組みではなく、既存の手法と、リアルな環境とアプリケーションでの検証にある、というところっぽいです。しかし、USENIX Securityではなかなか珍しいタイプの論文ではないでしょうか?(IEEE S&Pとかだと絶対通らなさそう)
Oxymoron: Making Fine-Grained Memory Randomization Practical by Allowing Code Sharing 
共有ライブラリのメモリランダマイズには限界があります。しかも、サイズが大きく、ROP gadgetを作るときによく使われてしまいます。この研究では、ASLRをより効果的に行うため、共有ライブラリを分割するバイナリ変換ツールを作成しています。
いくつかの関数ごとに分割し、読み込まれるアドレスを連続では無くすることで、関数のアドレスの予測可能性を下げています。関数呼び出し時は、間接呼び出しテーブルを使って、共有ライブラリ中の関数のアドレスを解決するようです。
 
Stitching the Gadgets: On the Ineffectiveness of Coarse-Grained Control-Flow Integrity Protection | USENIX
“Practical” control flow integrity(CFI)がホットトピックであると言っています(本当か?)kBouncerや、ROP Guard(MS EMET)などは、Practical CFIだそうです(本当かよ?)
 
この論文の貢献は、ROP検知の手法を整理し、その上でEMETのような粗いCFIを簡単に突破できてしまうことを実証したことにあるようです。その実証ということで、既存のPractical CFIで実行できる1MB以下のプログラム(共有ライブラリ)でTuring-completenessなROPを構築し、回避することができたとあります。
 

まとめ

  • 今、Anti-ROPがアツい
  • リアルアプリケーションでの検証が必須
  • ホットトピックはサイクルが短い
    (kBouncerがUSENIX SEC’13、ROPeckerに至ってはNDSS’14!)

あとがき

ということで、ざっとAnti-ROPセッションを紹介しました。セキュリティの研究者はここ10年で伸びており、USENIX Securityもコミュニティの広がりを考慮し、採択する論文を多くするという方針を採っているそうです。博士が取れないとかクサってる場合じゃねぇ!論文書いてトップカンファレンス通さなきゃ!
 
ということで、来年も研究頑張るぞい!

D進しようと思っている春にM2になる優秀な人達へ

こんなところを見ていないで、学振の申請書を書きましょう。

 

参考情報:

Road to JSPS -- NAIST version

小町先生の学振(DC)関係の大変参考になるドキュメント。

日本学術振興会特別研究員(DC1)申請書・学振 - 吉田光男 (YOSHIDA Mitsuo) - 自然言語処理グループ - 筑波大学

吉田さんの、大変参考になるドキュメント。

 

mode 2 seccompの話

この記事はカーネル/VM Advent Calendar 2013の記事です.

カーネル/VM Advent Calendar 2013 - Qiita [キータ]

前書き

にゃん↑ぱすー(挨拶).

さて,今年はmode 2 seccompの話です.
今年のセキュリティキャンプ2013,セキュアなシステムを作ろう組システムソフトウェアゼミでも取り扱いました.この辺りの話は,ゼミの卒業生第一号であるきゃにーさんのブログを見ると雰囲気が伝わるかなと思います.

seccamp2013卒業しました - 名前はまだ無い


彼女はC言語あんまり触ったことなく,準備期間でC言語の修行をおこない,1ヶ月と少しでプロセス分割とサンドボックス化まで出来るようになりました.頑張った!

 

さてseccomp の話題に戻します.巷ではseccomp 2, seccomp mode 2などとも書かれて,どうも表記に幅があります.

元々,システムコール番号をフィルターする seccompという仕組みがカーネルにあり,Linux Kernel 3.5からこれに追加する形でmode 2 seccompが導入されています.
この3.5から導入された仕組みのことを指す場合,mode 2 seccompあるいはseccomp filter, seccomp_bpfといった呼び方になるようです.

ざっくりとした説明などはこちらのスライドでどうぞ.


Linux Mode 2 Seccomp Tutorial // Speaker Deck

Mode 2 seccomp Internals

はてなブログソースコードの張り方とかがよく分からず面倒くさくなったので,ソースコードの解説などは今度まとめてqiitaとかで書こうと思います.めんど.

 

seccompのコードはlinuxソースコードを落としてきて,kernel/seccomp.cに実体がああります.メインとなるデータ構造はseccomp_filter構造体ですが本体はsock_filterという構造体のラッパー&リストになっています.は?(威圧)

 

sock_filterというのは,Berkeley Packet Filter(bpf)で使う,BPF instruction setをぶち込むためのデータ構造です.(半ギレ)

 

そう,Mode 2 seccompはBerkeley Packet Filterをバックエンドに使うのです.なんだろう,このリンゴ切るのにチェンソー使う感じ.どうしてこんなことになったのか?経緯はググると出てくるのですが,ざっと挙げるとこんな感じです.

 

1. レンダリングプロセスをサンドボックス化したいのん

Google Chromiumは設計段階からセキュリティを大きく重視しています.具体的には,javascriptやhtmlをレンダリングする処理をプロセス分割し,named pipeを使ってコードを送り,レンダリングプロセスでそれを実行,結果をshared memoryに描画するという感じになってます.これは第一にレンダリングに関わるjavascript実行エンジンとブラウザを切り離し,レンダリングプロセスが暴走したり,サーバからきたコードやレンダリングエンジンがバグっていてもブラウザ自体は動き続けるようにするためです.ただ,このレンダリングエンジンの脆弱性や悪意のあるjavascriptなどがブラウザを乗っ取るようなことを出来なくするため,レンダリングプロセスが出来る操作を大幅に制限しよう!という感じで設計していったと考えられます.

 

2. セキュリティアーキテクチャはOS(ディストリ)ごとに大きく変わるのでメンテナンスがめんどいのん

Google Chromiumサンドボックス化,PIDベースだと足りないけどSELinuxとか使うのは面倒過ぎて死ぬ 参照:Capsicum[USENIX Security '10]*1の論文

 

SELinuxを使う場合,ポリシーを書いてOSに強制してもらうわけですが,ディストリごとにタイプの割り当てが違っていたり,そもそもSELinuxがまともに動いてなかったり,ユーザーがOFFにしてしまうようなことになると意味ないわけです.

また,Chromeがリリースされた当初はWindows版がなかなかでなかったわけですが,この原因もこのサンドボックス化対応じゃないかなーと思っています.結局リリースされたWindows版も,FAT32ベースのシステムだとサンドボックスが上手く動かない,とか,その筋の人にしか分からない微妙な制限があったのが思い出されます.ま,Windowsで真面目にサンドボックス化しようと思っても当時のXPとかセキュリティはガバガバだからね,仕方ないね.

 

3.  ケーパビリティでは粒度が荒いのん

アクセス制御や権限の”粒度”というのは業界用語かもしれないのですが・・・ま,アクセス制御をおこなう単位のことです.*nixなシステムでは,プロセスごとにOSが特権を持たせ,プロセス生成時に親プロセスの特権を引き継ぐとか,特権の一部を剥奪することができます.ケーパビリティの例としては,CAP_SETUIDとか.CAP_SETUIDという特権を持っているプロセスは自身のUIDを変更できたりします.

権限の操作はprctlというシステムコールでおこなえます.プロセスがfork()するときに,子プロセスに対して,権限を指定する,要はプロセスが自発的に権限を放棄するわけですね.ここ重要です.

このようなケーパビリティベースの権限管理でも手の届かないところはあります.例えば,fork()を禁止したりとか.なので,じゃあシステムコール単位で権限を設定できるようにしようぜ!というところでしょうか.

 

4. mode 1 seccompは雑すぎなのん

とまぁここまで来て,Linux カーネルに元々あったsecure computing mode(seccompのオリジナル)が出てきます.secure computing modeは ケーパビリティの手の届いていないread/writeなど代表的なシステムコールを発行する権利を自ら放棄する仕組みです.ですが,mode 1 seccompは・・・大雑把過ぎたのです.read、write、sigreturn、exit をそれぞれ許可することしかできない.つらい.

 

とまぁこんないきさつがあって,システムコール単位の権限管理ができるものが欲しかったchromiumチームがmode 2 seccompを提案するわけです.しかし,どういうわけか彼らはBerkeley Packet Filterをバックエンドに持ってくるという発想に至ったようです.システムコールを制限するだけなら,プロセスごとにハッシュテーブルでシステムコール番号(たかだか数百)とその権限をもたせればいいんじゃないのかなーと思うのですが・・・

 

一応もっともらしい理由もあるようです.LWNの記事*2によると,

セキュリティサブシステムは性能もあんま考えないし,メンテもおろそかになりがちだし,カーネル内に似た機能があれば性能もよく考えられていて,メンテもよくされているわけだし,積極的に使えば良いじゃん.だから俺らはBerkeley Packet Filter使うわ.

みたいなことが書いてあります.うーん.2004年頃だったか,SELinuxが性能遅いというので海外産がロック周りの性能改善をやっていたという話も聞いたような.確かに一理あるという感じです.

 

まーでも,このbpfをバックエンドに使うことで別の問題が生じたりしています.Linux kernelの3.5だったか,bpf_jitというオプションが利用できるようになり,フィルタ性能を向上させるためにbpf処理をJITする機能がマージされました.カーネルでJITさせるというのは保守的なLinuxでよく入れたなぁと思うのですが,それだけ性能に対する要求が大きいというところでしょうか.ところが,このJITを使った攻撃手法もすぐに出現しました.

main is usually a function: Attacking hardened Linux systems with kernel JIT spraying

セキュリティサブシステムのバックエンドがセキュアじゃなかった,というなんだか悲しい出来事ですが,セキュリティサブシステムが独自の実装をしていればセキュアという訳でもないですからねぇ.

 

とまぁ,こんな感じでMode 2 seccompについてだらだらと書いてみました.

 

*1:いちいちフルペーパーなんか読めるかよって人は僕の論文輪講資料を参照

*2:Yet another new approach to seccomp [LWN.net]

つくば的新生活のススメ[交通編]

つくばに住んで早6年になったyuzuharaです.入学,編入,入院でつくばに住むことになった大学生(僕は情報系なので,そっちに偏るかも)が知っておいて損がない,そんなトピックをちょっとずつ紹介していこうかなーと思います.

とりあえず交通編.

交通編

つくばの足は自転車だ!盗まれないように気をつけよう!!

つくばはとにかくスケールが大きいです.
参考:http://d.hatena.ne.jp/natsu_san/20100531/1275319900

筑波大学からつくばセンターまで歩くと1時間は軽くかかります.となると,必然的に移動は自転車になる(車がないと生活できないというレベルでもない)のですが,よく自転車は盗難に遭います.つくばは(比較的)治安が悪いと言われる所以ですね.自衛策としては,防犯番号を登録しておく,鍵は2重ロックが基本というところです.

あとは自転車のメンテナンスについても.つくばは街灯が少ないスポットが結構あり,無灯火で走ってると死にかけます.車からしても,無灯火チャリは大変に脅威になります.自転車のライトは常に気にかけましょう.ダイナモ式がイヤなら,秋葉原のヨドバシで自転車用ライトが2000円ぐらいで買えますので,こっちにしましょう.

あと経験上,大学院生の1/3ぐらいはシティクロスやクロスバイクに乗っています.パンク修理が簡単で,そこそこスピードも出せるので結構オススメです.

筑波大学キャンパス交通システム(要は学内循環バスの定期)は早めに買っておくこと

つくばのメインの交通手段は自転車です.ただ,雨が降ったりすると辛いし,大学からつくばセンター(TXつくば駅)まで行く用事とかがあるときはバスの方が便利です.学生は年間4200円で,月に1往復するだけでも元が取れます.

#関鉄バスは大変UX(User eXperience) が低いため,学生証を見せるだけでOKというのもポイント高いです.

なお,3/31で切れるので,毎年4月の始めに更新を忘れないようにしましょう.

PASMOも買っておく

記名付のPASMOを買っておくことをオススメします.なんだかんだで東京に出る機会が多いし,利用ケースが限定された切符(デイズタウンの自動販売機で買える!)もありますが・・・面倒です.つくばエクスプレスは一本逃すと致命的なておくれ(=遅刻)を招くので,ギリギリを攻める機会が多い人はさっさと買っておくといいと思います.

記名式にしておくと,利用明細とかが印刷できるので,バイトなどで東京に行ったりするときにもそれで対応出来ます.

遠出するときのために,自宅とつくば駅の距離を把握しておく

乗換案内サイトは,当然ながらつくば駅を基準に時間を算出してくれます.しかし,大学周辺からつくば駅はそれなりに距離があります.前述のバスも感覚的には20分に1本(しかしsparseであるため,信用してはいけない)です.遠出する際にはこのバス一本で予定ギリギリになってしまうことがあるので,気をつけましょう.

僕の経験上大学からつくばセンターまでは,バスでの移動でも前後を入れて25~35分を見込んでおくといいと思います.

 

 とりあえず交通編はこんなところかな・・・聞きたいことがあればコメントください.

次回はたぶん,食糧事情編で.

 

 

 

Titanium Mobile(android)でtabgroupのTabbarを消す方法とその補足

消す方法:この記事を読んでください。

http://gihyo.jp/dev/serial/01/titanium/0014

 

消した後,戻るボタンで謎画面が出る問題:

Androidのみに存在するTitanium.UI.windowのプロパティexitOnCloseをtrueにするだけデス.

 

なんというquickhack...

Apple Sandbox(Seatbelt)を・・・強いられているんだ!

 この記事はカーネル/VM Advent Calendar 2011の記事です.

 

前書き

どうも,サンドボックス萌えなid:yuzuharaです.

 今年はみんな大好きMacに標準搭載されているApple Sandboxの話をしてみようと思います

サンドボックスっていうと,コンテキストによっていろいろ意味が変わります.

 この記事でいうサンドボックスは,”OSレベルの実行時アプリケーションの隔離を行う機構”のことをいいます.隔離というのは,プログラムを実行するとOSが管理するリソースのすべてが利用不可能な状態で起動するという感じです.この状態から,セキュリティポリシーにより最低限のリソースの利用を許可していくのがサンドボックスの基本的な利用方法となります.

f:id:yuzuhara:20111227234609j:plain 

こんな感じ.

 サンドボックスは,サンドボックス上で実行したアプリケーションを,あらかじめセキュリティポリシーに書かれたリソースにしかアクセス出来なくします.アプリケーションに脆弱性があり,その権限が乗っ取られたときでも,あらかじめ記述したセキュリティポリシーの範囲にしか変更する事が出来ません.

 ・・・まぁ,このセキュリティポリシーを書くのが難しいんですけどね.

 OSレベルのアプリケーションの隔離といえば, Daniel Walshさんが作ったSELinux SandboxがFedora14から利用可能になっています.その中身は,sandbox用のtype と,labelの管理(状況によってlabelを変更)を行うツールです.ベースになっている強制アクセス制御は,皆さんがいつもいつも真っ先にDisabledにしてしまうSELinuxです.

 まぁどうせ皆さん,SELinux Sandboxもオフっちゃうんでしょうけど・・・

Apple Sandboxとは

 Mac OSX 10.6(Snow Leopard)から搭載されている,アプリケーション用サンドボックスです."Seatbelt”という名前で開発が進められており,こちらの名前を知っている人も多いかと思います.

 そのベースになっているのは,Trusted BSD Projectで開発されたMAC Frameworkです.Trusted BSDはアメリカ国防総省のセキュリティに関するコンピューター導入基準(Common Criteria)にBSDを適応するためのセキュリティ機能群ですね.

 

Apple Sandboxの簡単な使い方

 とりあえず使ってみましょう.

 皆さんのMac(Lion)には,既にこのApple Sandboxは組み込まれています.ついでにいうとiOSデバイスにも.サンドボックスを使ってアプリケーションをlaunchするには,/usr/bin/sandbox-execというコマンドを利用します,

 sandbox-execでは,セキュリティポリシーのことをprofileと読んでいます.デフォルトで用意されているprofileを指定するときは,"-n"で指定します.自分自身でprofileを用意する場合は,ファイルに記述し,.sbという拡張子で保存しておくとよさそうです.ファイルを指定するときは-f hoge.sb.

 

%sandbox-exec -n no-internet curl http://www.gentoo.org/

curl: (7) Failed to connect to 89.16.167.134: Operation not permitted

 

とまぁ,インターネットに繋げずにエラーとなります.

オプションについては,man sandbox-execやman sandbox_initで確認できます.

さらっと紹介.

 

  • no-internet

  TCP/IPが利用不可

  • no-networking

  ソケットベースの全ての通信が利用不可

  • no-write

 アプリケーションはいかなるファイルにも書き込みができない

  • no-write-except-temporary

 アプリケーションは一部(/var/tmpや_CS_DAR-WIN_USER_TEMP_DIRに設定されたディレクトリ)のディレクトリ以外に書き込みができない

  • pure-computation

 アプリケーションは一切OSのリソース・サービスを利用することができない

 

ためしに,書き込み禁止プロファイルを使って,gentooのトップページをダウンロードしてみました.

% sandbox-exec -n no-write curl -o /var/tmp/gentoo http://www.gentoo.org/

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0Warning: Failed to create the file /var/tmp/gentoo: Operation not permitted

  5 47502    5  2598    0     0   2062      0  0:00:23  0:00:01  0:00:22  5575

curl: (23) Failed writing body (0 != 2598)

アアアッ,書き込めないって怒られました.

今度は,/var/tmpに書き込みを許可したポリシーを用いて,/var/tmp/gentooというファイルに書き込みを試みます.

 

% sandbox-exec -n no-write-except-temporary curl -o /var/tmp/gentoo http://www.gentoo.org/

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100 47502  100 47502    0     0  32532      0  0:00:01  0:00:01 --:--:-- 46938

[bachi@lucchini] % head /var/tmp/gentoo

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html lang="en">

<head>

お,保存できましたね.

 

簡単な使い方はこうです.

 

プロファイルの書き方

プロファイルはこんな方に書いていきます.どこかS式っぽい・・・

 

(version 1)

(allow default)

(deny file-write* (regex #"/var/tmp/*$") )

 

ポリシー記述の基本は,いわゆるパス名ベースとなってます.

これ,カーネルモジュールの中に正規表現エンジンが入っていて,カーネルの中でそのまま評価されるみたいです.

セ,セキュリティ的に大丈夫なんだろうか・・・

(TOMOYOも正規表現にバグがあったときがありましたよね・・)

 

このプロファイルは,/var/tmp/以下にファイルを作成できなくするようにポリシーを書いてみました.

ホントは,デフォルトで禁止と書きたいのですが・・・このためには,プログラムの正常な動作をすべて記述しなければなりません.

この作業はとても大変・・・・

 

と,この大変な作業を簡単にする方法があるようです.

sandbox-simplify というコマンドは,traceコマンドで取ったプロセスのトレースログを使って,プロファイルの下地を作ってくれます.

※traceについては時間が無かったので今度再度まとめます・・・

 

既存のプロファイルを見てみよう

Lion では,/System/Library/Sandbox/Profiles  や/usr/share/sandboxの中にプロファイルがたくさんあります.興味がある人はのぞいてみると良いと思います.

プロセスの基本的な振る舞い(ライブラリやログ周り)については,/System/Library/Sandbox/Profiles/bsd.sbというファイルがあります.

自分でカスタムプロファイルを作るときは,まずこのbsd.sbをimportするとよいと思われます.

 

 

どんなプログラムがサンドボックス化されているの?

activity monitorで確認することが出来ます(デフォルトでは表示されていないので,項目を右クリック→表示).

有名なのはGoogle Chromeですね.

あとはAppleのデフォルトインストールアプリは割とサンドボックス化されているようです.f:id:yuzuhara:20111227234558p:plain

まとめ

ざっとですが,Apple Sandboxについて紹介しました!

余裕があれば,今度はkernel内部を読んでみようと思います.

それでは,皆さん良いお年を!

 参考文献

  1. Dionysus Blazakis, The Apple Sandbox Blackhat-DC 2011
  2. Apple's Sandbox Guide v1.0