SAccesor:デスクトップPCのための安全なファイルアクセス制御システム 数理・計算科学専攻　千葉研究室 滝澤　裕二 指導教員: 千葉 滋

OSカーネルに対する攻撃の脅威 OSカーネルがファイルアクセス制御を行っている パッチ未適用 ゼロデイアタック OSカーネルが攻撃を受けるとファイルアクセス制御が無効化されてしまう 一般ユーザがウィルスを実行 ウィルスがOSの脆弱性をついて特権と取得 認証をバイパス アクセス制御の無効化 任意のファイルへアクセスされる 現在のファイルアクセス制御というのは、基本的にはファイルの所有者とアクセス権のリストによってOSカーネルが行っています。 しかし、OSカーネルにもバグが多数報告されています。 パッチが公開されるのが普通ですが、ユーザのセキュリティ意識が低い、パッチを適用すると動かなくなるアプリがあるなどの理由で パッチが未適用の場合がある。また、パッチが公開される前に攻撃を受けてしまう場合もあります。あるいは、パッチを当てることで別ばバグがでてしまったりというようなことがあります。 アクセス制御を行っているOS自体がクラックされてしまうと、ファイルアクセス制御が無効化されてしまいます。 例えば 一般ユーザがウィルスを実行してしまった場合、通常ですと、ウィルスは実行したユーザの権限の範囲でしかファイルアクセスができませんが、 OSの脆弱性をついて特権を取得することで、任意のファイルへアクセスできるようになる危険性があります。

OS外のアクセス制限による保護 Kerberos＋ファイルサーバ 認証サーバ パスワード 認証チケット サービス 認証チケット クライアント OSカーネルが攻撃された場合にも認証やアクセス制御を実施するために、OSの外でアクセス制御を行うことが考えられますが、 単純に認証やファイルアクセス制御をOSの外に持ってくるだけでは実用的なシステムにはなりません。 例としてkerberos認証とファイルサーバを組み合わせて使うことが上げられます。 ケルベロス認証を使う場合には、クライアントは認証サーバで認証を行い、サービスを受けるためのチケットを取得します。 そのチケットを使って、ファイルサーバにアクセスをします。 この場合、認証を認証サーバに、ファイルアクセス制御をファイルサーバに分離することができて、クライアントのOSをクラックしても認証をバイパスすることはできません。 サービス 認証チケット クライアント ファイルサーバ

OS外のアクセス制限による保護 Kerberos＋ファイルサーバ 認証サーバ 認証 チケット パスワード キーロガー トロイの木馬 認証 ただし、攻撃者はクライアントマシンを攻撃して、 キーロガーやトロイの木馬を仕掛けることで、 パスワードあるいは秘密鍵を盗むことで 認証サーバに対して認証を成功させることができます。 キーロガー トロイの木馬 認証 チケット クライアント ファイルサーバ パスワード 秘密鍵の漏洩 サービス 攻撃者

OS外によるアクセス制御の保護 VMM,HDDでファイルアクセス制御 低い抽象度のインターフェイス ブロック番号 OSがクラックされた後のユーザ情報は信用できない 管理者です APP 別の方法として、VMMやHDDなどのデバイスでファイルアクセス制御を行うことも考えられます。 ただし、VMMやデバイスではファイルという構造は使えずに、 ブロック番号などの抽象度の低いインターフェイスしか提供おらず、またユーザの情報もないので、ファイルアクセス制御を行うことは難しい。 また、OSからユーザ情報を受け取って制御すればいいのかというと、OSがクラックされているかもしれないので、OSから受け取る情報というのは信用できず、 やはり適切にアクセス制御を行うことは難しいです。 このように、 OSがクラックされた状況においてもアクセス制御を強制するためには、OS外でアクセス制御を行う必要がありますが、 OSの外に認証やファイルアクセス制御を分離するというのは、そう簡単に上手くいくわけではありません。 ファイル名 OS ブロック番号 VMM アクセス制御

提案：SAccessor OSクラックされた状況においてもファイルアクセス制御を維持するシステム VMMとファイルサーバを組み合わせてアクセス制御を分離したときの問題を解決 システムファイルの不正書き換えはない OSを再起動することでクラックの影響を除去可能 ログインしていなければユーザファイルの不正アクセスはない 本研究では、OSがクラックされた状況でもファイルアクセス制御を維持するシステムSAccessorを提案します。 SAccessorではVMMとファイルサーバを上手く組み合わせることで、 ファイルアクセス制御をOSから分離したときの、 なりすましができてしまうとか、上手くアクセス制御できないといった 問題を解決して、実用的に使えるようにしました。 SAccessorを使うことでシステムファイルの不正書き換えを防ぐことができます。 これによってOSクラックされたとしても、再起動をかけてやることでクラックの影響を除去することができます。 また、ユーザログインをしていなければ、ユーザファイルへの不正アクセスも防ぐことができます。 これから、まずSAccessorのアーキテクチャについて説明して、 その次にシステムファイルをどうやって守るか、 最後にユーザファイルの防御について説明していきます。

アーキテクチャ VMMを使い1台のマシン上に2つのOSを動作 作業OS:ユーザがログインして作業 認証OS：ファイルサーバ ローカルファイルシステムなし 認証OS：ファイルサーバ アクセス制御を実施 外部からのアクセスを制限 TCB SAccessorのアーキテクチャは図のようになっています。 仮想計算機モニタのXenを使って、１台のマシン上に2つのOSを動作させます。 ドメイン０上ゲストOSを認証OS,ドメインUのゲストOSを作業OSと呼んでいます。 ユーザは作業OSにログインして作業します。作業OSはローカルファイルシステムを持たず、 認証OSのファイルサーバを通してファイルアクセスを行います。 従って、作業OSが直接ディスクにアクセスするということはできず、ファイルアクセス制御を強制することができます。 認証OS上は作業OSからのリクエストを受け取って、ファイルアクセス制御を行います。 認証OSはクラックの危険を最小にするために、外部からのアクセスを制限します。 SAccessorでTrusted Computing Baseとしているところは図の赤線で囲まれた部分です。 具体的には、ハードウェアとVMM。 認証OSとその上で動くアプリケーションは安全だと仮定しています。 これは、VMMはOSよりも小さなソフトウェアである。 また認証OSはリモートからのアクセスを制限するため、 リモートからの攻撃を受けにくいと考えられます。 ファイル サーバ （NFSD) APP APP アクセス コントローラ 認証OS 作業OS VMM(Xen)

システムファイルのアクセス制御 基本的にREAD ONLY 認証OSがシステムファイル書き換えサービスを提供 xxx.pidやutmpなど一部例外は書き込み可 システム起動時に上書きされるので問題ない ログファイルは追記のみ許可 認証OSがシステムファイル書き換えサービスを提供 作業OSはそのサービスをRPCで起動 これ以外の方法では書き換えられない サービス起動時に認証を実施 基本操作ごとにサービスを用意 例:setuidコマンド(passwd,...) システムファイルのアクセス制御について説明します。 システムファイルは一部の例外を除いて、基本的にリードオンリーに設定します。 ただし、書き換える場合には特別な方法をとる。 システムファイルは一部の例外を除いて、リードオンリーに設定します。 一部の例外とはプロセスIDを記録するドットpidで終わるファイルやログインの記録をとるutmpファイル、ログファイルなどです。 ログファイルは追記のみ許可します。 .pidやutmpなどはシステム起動時に上書きされるようなファイルであるので、書き換えられても問題ではないですし、 ログファイルに追記されても、ログは消されないので問題はありません。 READ　ONLYにすることで、攻撃者による書き換えは防ぐことができますが、自分も書き換えられなくなってしまうので、 システムファイルを書き換える必要があるときはどうするかというと・・・ 認証OSがシステムファイルを書き換えるためのサービスを提供していて、作業OSはこのサービスをRPCで起動することでシステムファイルを書き換えます。 これ以外の方法では書き換えることはできません。 認証OSでは基本書き換え操作ごとにサービスを用意しておいて、サービスを起動するときに認証を行います。 システムファイルはpasswdのようなsetuidされたコマンドによって書き換えられることが多いので、 setuidコマンドが基本操作の一つの例になります。

サービス例：passwd 認証OS 作業OS passwdを実行 認証ダイアログ 認証 プロセス サービスの 呼び出し Glibc execve() 書き換え サービス 実行 passwd ディスク ウィンドウ /etc/passwd

SAccessorにおける認証 認証OSが作業OSの画面に重ねて認証ダイアログを表示 作業OSの画面はVNCウィンドウとして全画面表示 Xサーバは認証OS上で動作 認証OSがユーザと直接やり取り 作業OS上の攻撃者はダイアログにアクセスできない サービスを起動するときに認証を行うといいましたが、どう認証するかというと認証ダイアログというダイアログを通して行います。 認証ダイアログは作業OSの画面の上に重ねて表示します。 どうやって作業OSの画面の上に重ねて表示するかというと、 Xサーバが認証OS上で動作しており、作業OSの画面はVNC（VNCとはウィンドウズでいうリモートデスクトップのようなソフト） を使って、VNCウィンドウとして全画面表示を行う。 そうするとユーザには作業OSの画面だけが見えるようになります。 （図の説明） 認証OSはそのVNCウィンドウの上に重ねて認証ダイアログを表示します。 認証OSを意識させない シームレスな認証が可能 VNC 認証OS 作業OS

SAccessorにおける認証 認証OSが作業OSの画面に重ねて認証ダイアログを表示 作業OSの画面はVNCウィンドウとして全画面表示 Xサーバは認証OS上で動作 認証OSがユーザと直接やり取り 作業OS上の攻撃者は認証ダイアログにアクセスできない （図をさして）ユーザが作業OS上で、認証OSのサービスを呼び出すようなコマンドを実行すると、 （次スライド）このように、認証ダイアログが一番手前に表示されます。 このダイアログにパスワードを入力して認証を行います。 この画面を横から見た図が右になります。 作業OSの画面の一部としてダイアログがあるのではなくて、別のウィンドウとして認証OSが表示させる。 そのため、作業OS上の攻撃者からはこの認証ダイアログにアクセスできず、安全にユーザ認証を行うことができます。 作業OSの画面は全画面表示されているので、この認証ダイアログはユーザからは作業OSから出たように見え、 裏で認証OSが動いているということを意識しないシームレスに認証ができます。 認証OSを意識させない シームレスな認証が可能 VNC 認証OS 作業OS

認証ダイアログの安全性 タイトルにシークレット文字列を表示 認証OSにあらかじめ登録しておく 作業OSからはみることができない ユーザはこの文字列を見て偽のダイアログと区別 認証ダイアログへのキー入力を盗まれることはない シークレット文字列 TCB 認証ダイアログを作業OSの画面に重ねて表示することでシームレスな認証ができますが、それを逆手にとって、 作業OSから偽のダイアログを表示してユーザのパスワードを盗む攻撃が考えられます。 作業OSから偽のダイアログを出されてユーザがパスワードを入力してしまうとパスワードが盗まれてしまうという危険性があります。 作業OSから出される偽の認証ダイアログと区別するために 認証ダイアログのタイトルには、シークレット文字列を表示させています。 シークレット文字列は認証OSにあらかじめ登録しておく、ユーザのみが知っている文字列です。 この文字列は認証OS上にあるので作業OSから真似することはできません。 その他には、中央に起動しようとしているサービス名が表示されていて、 ユーザの意図しないサービスの場合にはDENYボタンを押して認証を失敗させることができます。 認証ダイアログへのキー入力はハードウェアからVMM,認証OSとTCBの中を通ってダイアログに渡されるため、作業OSから盗まれることはない。 VNC サーバ X11 認証OS 作業OS VMM ハードウェア キー入力

ユーザファイルのアクセス制御 ファイルアクセス時に認証ダイアログで認証 段階的なアクセス制御 認証に成功するまではアクセス不可能 ファイルやディレクトリをまとめたグループごとに認証 一度の認証で関連するファイルもまとめて許可 認証に有効期間を設定 認証の有効期間内は認証を省略 ユーザファイルへのアクセスに対しては、システムファイルの書き換えサービスと同様に認証ダイアログでユーザ認証を行います。 この認証が成功するまでは作業OSからユーザファイルへのアクセスはできません。 認証に成功すると作業OSからファイルにアクセスできるようになりますが、 一度の認証で全てのファイルにアクセスできるようになるわけではなくて、 これからアクセスしようとしているファイルと、それに関連するファイルを一緒に許可する。 認証には有効期間が設定できて、認証に成功したら認証の有効期間の間は認証なしでファイルにアクセスできるようになります。 ファイルシステム 一度の認証でファイルシステムの一部分を期限付きで公開

ユーザの秘密鍵を守るポリシ例 メーラに関するファイルだけにアクセス許可をだす ウィルスメールを受信した場合 被害はメーラグループのみ ユーザの秘密鍵を盗まれることはない この段階的なアクセス制御をどのように使うかというと、例えば、ユーザの秘密鍵を守るポリシが書けます。 ポリシの説明 グループの定義 パーミッション 有効期間 メーラを起動すると一回認証を求められて、その認証に成功すると、 thunderbird以下のファイルへのアクセスが１０分間アクセスできるようになる。 ここで、ウィルスメールを開いてしまった場合でも、 作業OSからアクセスできるファイルは認証済みのメーラグループに限定されるので、 ウィルスがユーザの秘密鍵にアクセスしようとすると、sshグループに対する認証ダイアログがでるので ユーザはその認証を失敗させてやることで、ウィルスが秘密鍵を盗むのを防ぐことができます。 <メーラ>[600]　 /home/takizawa/.thunderbird/* (rw) </メーラ> <ssh>[10] /home/takizawa/.ssh/id_rsa (r) </ssh> パーミッション 有効期間(秒)

作業OSのキャッシュクリア 認証の有効期間の切れたファイルキャッシュはクリアさせる 作業OSにあるファイルキャッシュは認証なしでアクセス可能 VMM（Xen)の機能を利用 作業OSのメモリ空間を認証OSのメモリ空間にマップ 作業OSの変更不要

キャッシュクリアの実装 作業OSのCPUレジスタの値から実行中のプロセスの情報を取得 ファイル名とプロセスのルートディレクトリから対象ファイルのinode構造体を探す nfs_inodeのcache_validityの値を変更 キャッシュを使わずサーバに問い合わせるようになる radix_treeからページキャッシュを探しゼロクリアする

実験 SAccessorの性能測定 認証OS上で実行するsetuidプログラムの数 キャッシュクリアにかかる時間 Bonnie++ ext3(native) VM+NFS SAccessor 認証OS上で実行するsetuidプログラムの数 実験環境 CPU:PentiumD 3.0GHz メモリ：１GB Xen:3.0.4 認証OSに512MB 作業OSに384MBのメモリ割り当て 両OS:Linux 2.6.16.33

キャッシュクリアの性能 クリアにかかる時間はファイルサイズに比例 メモリマップ1回にかかる時間は約0.4ミリ秒 1ページ(4KB)のキャッシュをクリアするのに３回メモリマップが必要 VMM内で実装することで削減可能

ファイル読み込み性能 nativeと比較して約33%のオーバーヘッド VM+NFSと比較すると約7%のオーバーヘッド 7%がSAccessorでアクセス制御のために追加した分のオーバーヘッドと考えられる

書き込み性能 ブロック単位/文字単位 文字単位 ブロック単位 nativeと比べ約42%のオーバーヘッド VM+NFSは同等 書き込み性能　ブロック単位/文字単位 文字単位 nativeと比べ約42%のオーバーヘッド VM+NFSは同等 ブロック単位 SAccessorのほうが良い NFSを使っているため、実際にディスクに書き込むのを待たずに測定終了しているため

ダイアログの出現頻度 Linuxのsetuidプログラムの数33個(FC5の場合） 認証ダイアログの出現頻度は少ない 認証OS上で実行すべきもの11個 passwd,crontab,chfn,chsh　etc 任意のプログラムを実行できるため認証OS上で実行すべきでないもの７個(sudo etc) ネットワークを使うので認証OS上で実行すべきでないもの5個(rsh etc) 作業OSで実行するべきもの10個(mount etc) 認証ダイアログの出現頻度は少ない passwd,chshなどは1日に一回も使わない

関連研究 Plan9 [Bell Labs ‘95] SVFS [Xin Zhao et al SISW’05] 管理者のファイルへのアクセスはファイルサーバのコンソールからのみに限定 SVFS　[Xin Zhao et al SISW’05] VM毎に異なるアクセス権 別VMにログインしなおして作業する必要 Proxos [Richard et al OSDI’06] プロセスをVMに隔離して実行 プログラマがシステムコールレベルのポリシを記述

まとめ・今後の課題 OSがクラックされてもファイルアクセス制御を強制するSAccessorの提案 今後の課題 以下が守れる 実行ファイル、設定ファイル、ライブラリの書き換え 再起動することでクラックの影響を取り除ける ユーザファイルへのアクセス 被害を限定 今後の課題 キャッシュフラッシュの実装をVMM内で行う オーバーヘッドの削減

以上です

脅威モデル デスクトップPCを対象 攻撃者がOSレベルの特権を取得 攻撃者はリモートにいる ファイルの改ざん ユーザの機密ファイルへアクセス 実行ファイル、設定ファイル、ライブラリ ユーザの機密ファイルへアクセス 攻撃者はリモートにいる マシンへの物理的なアクセスはない

実装 認証OS 作業OS 書き換えサービス 実行 setuidコマンド ユーザ空間 ユーザ空間 カーネル空間 カーネル空間 Xen ディスク 認証ダイアログ 書き換えサービス 実行 setuidコマンド 認証 プロセス Glibc execve() ユーザ空間 ユーザ空間 カーネル空間 カーネル空間 アクセス コントローラ NFSD NFS Xen ディスク