サーバソフトウェアのための 動的なセーフティネットの研究 博士３年　光來健一 指導教官　清水謙多郎

ソフトウェアの安全性 ソフトウェアは複雑化、肥大化している ソフトウェアの安全面での問題が顕在化してきている 例：ウェブシステム バグの増大 初期は静的コンテンツのみ 現在はCGIやJAVAなどの動的コンテンツが増大 バグの増大 ソフトウェアの安全面での問題が顕在化してきている ソフトウェアの持つ権限を悪用する攻撃 ソフトウェアに残る不安定さ 近年、ソフトウェアは複雑化、肥大化する傾向にある。 例：ウェブシステムは最初静的コンテンツのHTMLページを見るだけ、現在では動的コンテンツのCGIやJavaなど その中に含まれるバグも増大している。 そのせいで、ソフトウェアの安全面での問題が顕在化してきている。

攻撃の脅威 インターネットに接続するソフトウェアは常に攻撃の危険にさらされている バッファオーバフロー攻撃によるサーバ乗っ取り 悪意あるモバイルコードの実行 攻撃を防ぐ様々な手法が提案されているが、未知の攻撃を防ぐことはできない StackGuard [Cowan et al.’98] スタックオーバフロー攻撃を検出する 提案された後に防げない攻撃が見つかった 攻撃という点から

不安定なソフトウェア ソフトウェアの中には不安定なものも存在する 言語やコンパイラによるサポートもあるが、必ずしも十分とはいえない β版のソフトウェア 正式版でさえ不安定なものもある フリーソフト 言語やコンパイラによるサポートもあるが、必ずしも十分とはいえない PCC [Necula et al.’96] プログラムの安全性を静的に検証する すべてのプログラムを検証できるわけではない 不安定さの点から

セーフティネットによる防御 セーフティネットとは？ セーフティネットの例 ソフトウェアが万一おかしな動作をした場合でも、被害を最小に抑える防衛ライン セーフティネットの適用範囲はできるだけ狭くすることが重要 セーフティネットの例 サンドボックス 攻撃や不安定さといったソフトウェアの安全面の問題を緩和するには、セーフティネットによる防御が必要となる セーフティネットとは... 被害を最小にするためにできるだけ狭く セーフティネットがないと重要なデータにも <click> セーフティネットがあればアクセスする必要がない重要なデータは守られる 例として... セーフティネット ソフトウェア 重要なデータ

従来のセーフティネットの問題 状況によって必要な資源が変わるソフトウェアには適さない 安全性や性能のためセーフティネットは固定 必要となり得る全ての資源をセーフティネットが含まなければならない セーフティネットの範囲が広くなる 万一の場合の危険が増す 資源 従来のセーフティネットには問題があった 後で詳しく話すが、安全性や性能の点から従来のセーフティネットは範囲が固定 ...には適さない ソフトウェアが２つの資源しか使わない時はこのようなセーフティネット 別の資源が必要になるとアクセスできない <click> 全てを含むようなセーフティネットが必要 セーフティネット ソフトウェア

本研究の目標 サーバソフトウェアに焦点 動的なセーフティネットの構築 様々なクライアントに同時に使われる 性能と安全性のバランスが重要 クライアントに応じたセーフティネット ユーザレベルサーバ 安定度に応じたセーフティネット OSモジュール ユーザレベル サーバ 状況によって必要な資源が変わるソフトウェアとして、特にサーバに焦点 様々なクライアントに同時に使われ、必要なセーフティネットが変わる 性能も重要なので、バランスの取り方でセーフティネットが変わる サーバのための動的なセーフティネットを目標 サーバの特徴に対応して、クライアントに応じたセーフティネットを構築 攻撃の対象になりやすいユーザレベルサーバを対象 安定度に応じたセーフティネットを構築 バグがシステム全体に影響を与えるOSモジュールを対象 OSモジュール カーネル

クライアントに応じた セーフティネット アクセスしてくるクライアントに応じてサーバのアクセス権限を変える サーバが常に全てのユーザの個人情報にアクセスする権限を持つ必要はなくなる セーフティ ネット 公開情報 クライアントに応じたセーフティネットは...ことによって実現している それにより、... 外部ユーザに対しては公開情報にだけアクセスできるセーフティネット 外部ユーザ ユーザAの 個人情報 サーバ ユーザBの 個人情報

クライアントに応じた セーフティネット アクセスしてくるクライアントに応じてサーバのアクセス権限を変える サーバが常に全てのユーザの個人情報にアクセスする権限を持つ必要はなくなる セーフティ ネット 公開情報 ユーザAについてはユーザAの個人情報にも ユーザAの 個人情報 サーバ ユーザBの 個人情報 ユーザA

安定度に応じたセーフティネット OSモジュールの安定度に応じて保護の仕方を変える 安全だが遅い NFSサーバ UFS 安定度に応じたセーフティネットは...ことによって実現している それによって、... NFSサーバモジュールとUFSというローカルファイルシステムのモジュール NFSサーバモジュールが不安定な時は、それぞれを別々のセーフティネットにすれば、 NFSサーバがUFSにアクセスするのは遅くなってしまうが、 UFSが使うディスクを破壊したりせず安全 ディスク セーフティネット

安定度に応じたセーフティネット OSモジュールの安定度に応じて保護の仕方を変える 速い NFSサーバ UFS NFSサーバモジュールが安定している時、 一つのセーフティネットにすれば ディスクにもアクセスできてしまうので危険にはなるが、 NFSサーバからUFSへのアクセスは速い 危険 ディスク セーフティネット

本研究の主な成果 （Ⅰ）ユーザレベルサーバ用のアクセス制御機構 （Ⅱ） OSモジュール用の保護機構 クライアントに応じたセーフティネットを実現 プロセスクリーニング[Kourai et al.’01]によりアクセス制限の安全な変更を実現 （Ⅱ） OSモジュール用の保護機構 安定度に応じたセーフティネットを実現 マルチレベル・プロテクション[Kourai et al.’98]により性能と安全性のトレードオフを実現 ...機構を使って、...なセーフティネットを実現

（Ⅰ）ユーザレベルサーバ用の アクセス制御機構 ～プロセスクリーニング～ プロセスクリーニングを中心に説明

アクセス制限による セーフティネットの構築 ポリシールールに従ってシステムコールレベルでアクセスを制限する deny accept allow recv “A” allow send “A” allow read “*” A コネクション 確立 HTMLファイル クライ アント 通信 deny recv allow send “A” allow read “01.html” A 01.html リクエスト 受信 allow accept “*” allow read “*” 最初、ウェブサーバには全てのファイルにアクセスでき、全てのクライアントからのコネクションを受け付けるポリシーが適用 <click> クライアントAからのコネクションが確立すると、以降のacceptは禁止され、Aとのsend/receiveのみ さらに、01.htmlというファイルをリクエストされると、以降のreceiveは禁止され、01.htmlを読んで、Aに送ることだけができる サーバ HTMLファイル セーフティネット

アクセス制限の変更に伴うリスク 攻撃を受けたサーバにアクセス制限の変更を許すのは危険 しかし、攻撃を受けたかどうかを判断するのは難しい 乗っ取られたサーバのアクセス制限が解除されると、全権限を奪われる アクセス制限の変更後にトロイの木馬が実行されると、サーバの権限を乱用される しかし、攻撃を受けたかどうかを判断するのは難しい サーバ しかし、クライアントに応じたセーフティネットを構築するためにアクセス制限を変更できるようにするには、リスクが伴う 攻撃を受けたサーバに許すのは危険だから 例えば、サーバが乗っ取られている状態で解除されると... <click> サーバの全権限を奪われる セーフティネット

アクセス制限の変更に伴うリスク 攻撃を受けたサーバにアクセス制限の変更を許すのは危険 しかし、攻撃を受けたかどうかを判断するのは難しい 乗っ取られたサーバのアクセス制限が解除されると、全権限を奪われる アクセス制限の変更後にトロイの木馬が実行されると、サーバの権限を乱用される しかし、攻撃を受けたかどうかを判断するのは難しい サーバ まだ乗っ取られてはいなくても、バッファオーバフロー攻撃によってトロイの木馬となるコードがサーバに送り込まれていた場合... <click> アクセス制限を変更した後... トロイの木馬が実行されると、場合によってはより弱いアクセス制限の下で実行され、サーバの権限を乱用 攻撃を受けたサーバには許さなければよいが、判断するのは難しいです セーフティネット

従来のアクセス制御機構 Janus [Goldberg et al.’96] など SubDomain [Cowan et al.’00] 動的な変更は許さない SubDomain [Cowan et al.’00] 変更には秘密鍵が必要なので安全に見える 乗っ取られると秘密鍵も知られてしまう Capabilityシステム [Tanenbaum et al.’85など] capabilityを持っている間だけ権限を使える 乗っ取られると渡された権限を悪用される SubDomainではトロイの木馬となるコードが送り込まれたり、悪意のあるサーバモジュールが組み込まれたりしても、変更には秘密鍵が必要なので、安全に見える しかし、そのようなコードもサーバが読める秘密鍵を読むことができるのでダメ capabilityシステムでは、クライアントがサーバにcapabilityを渡している間だけ、サーバはクライアントの権限を利用できる しかし、一旦、悪意をもったクライアントに乗っ取られると、他のクライアントから渡されたcapabilityを悪用できる

プロセスクリーニング アクセス制限を変更する前にプロセスを攻撃される前の状態に戻す プロセスの制御を取り戻す メモリイメージを元に戻す 乗っ取られたままアクセス制限を変更させない メモリイメージを元に戻す トロイの木馬をメモリに残したまま アクセス制限を変更させない 攻撃を受けたプロセス 　　正常なプロセス　　 安全な状態 プロセスクリーニングという手法を提案している アクセス制限を変更する前に... <click> 攻撃されているかもしれないサーバプロセスの状態を攻撃される前の安全な状態に戻す これにより...

プロセスクリーニングの実装 save_stateシステムコール restore_stateシステムコール プロセスの状態を保存する レジスタ、メモリイメージなど カーネル内に保存 restore_stateシステムコール 保存しておいた状態を復元する save_stateのあとに適用されたアクセス制限を解除する save_state(); accept(); ＜アクセス制限＞ ＜リクエスト処理＞ restore_state(); ２つのシステムコール コードの例

メモリイメージの保存の遅延 copy-on-write技術により変更されたページだけ保存する save_stateで全てのページを書き込み禁止にする ページフォールトが起こったらシャドウページと置き換える 保存するページの内容をシャドウページにコピーする カーネル プロセスクリーニングの性能のボトルネックはメモリの保存と復元なので、様々な最適化を行った 書き込み禁止に（図の赤いページ） ページフォールトが起こったら... <click> そのページをカーネルに移動して保存し... シャドウページと呼ばれる新しいページに置き換える シャドウページには元のページの内容がコピーされる 保存 シャドウページ マップ ページフォールト アドレス空間

メモリイメージの復元方式 再マップ方式 コピー方式 保存しておいた元のページをマップ 次のページフォールトで再び保存される 元のページの内容を投機的にシャドウページにコピー 復元後に同じページが使われた時ページフォールトが起こらない 使われなければコピーが無駄になる 元のページ マップ シャドウページ 破棄 元のページ コピー 復元には２つの方式がある 再マップ方式は... <click> シャドウページを破棄し... 元のページをマップする これはデフォルトの方式で、次にページフォールトが起こったら再び保存される コピー方式は... 元のページの内容を投機的にコピー シャドウページ

静的データのレイアウトの最適化 変更されるメモリページ数が最小になるようにサーバプログラムの静的データを再配置 ライブラリを静的にリンクする データ・BSSセグメントを一か所にまとめる 実行時プロファイルに従って静的データを並び替える 変更されるデータをなるべく同じページに配置する アドレス空間 プロセスクリーニングの最適化ではないが、サーバプログラムのレイアウトをプロセスクリーニングに合わせて最適化することでも性能を改善できる ライブラリを静的にリンクしてデータ、BSSセグメントを一ヶ所にまとめることにより... <click> 静的データのページが減る 変更される静的データがなるべく同じページに配置されるように並び替えると... さらに減る

Fork-Join法との比較 Fork-Join法でもプロセスクリーニングと同様の効果を得られる 子プロセスにアクセス制限をかけて処理させる セキュリティ 子プロセスを作る時には親プロセスの状態がコピーされるので同等 性能 オーバヘッドが大きい プロセスプールが使えない 子 fork exit 子 exit サーバ プロセスプール アクセス制御機構ではないが、Fork-Join法でも実現できる Fork-Join法はリクエスト毎に子プロセスをforkして... <click> アクセス制限をかけて処理させ、終わったら... 子プロセスを終了させる 他のリクエストがきたら... 別の子プロセスをforkする 親プロセスの状態がコピーされ、親プロセスの状態というのはプロセスクリーニングで言うところの保存された状態なので、通信しないなどして親プロセスが攻撃されないようにできれば同等 fork/exitのオーバヘッドが比較的大きい プロセスクリーニングの場合には使えるプロセスプールが使えない プロセスプールとは、あらかじめいくつかの子プロセスをforkしておき... リクエストを処理する時には一つを取り出して使い、終わったら... プールに戻して再利用する 再利用 プール

クライアントの行動の追跡 直接の通信相手のIPアドレスだけでは、攻撃者を判別することができない 踏み台攻撃を防げない クライアント情報を記録し、実行フローに従ってその情報を伝播させる 攻撃先のサーバにもセーフティネットを構築できる プロセスクリーニングの話は少し置いておいて、クライアントをより正しく判定する方法について説明する 現在のサーバでは直接の通信相手のIPアドレスだけを見ており、攻撃者がサーバ１を攻撃してからサーバ２にアクセスするような踏み台攻撃をされた場合にはうまくアクセスを制限できない サーバ2にはサーバ１からのアクセスに見える 各サーバでクライアント情報を記録し、実行フローに従って伝播 <click> 送られたクライアント情報を基にサーバ２にもセーフティネットを構築できる クライアント情報 踏み台攻撃 攻撃者 重要なデータ サーバ2 サーバ1 セーフティネット

クライアント情報の圧縮 クライアント情報は汚染レベルというパラ メータに圧縮する 実行フローに含まれるホストの最大の危険度 パケットのIPオプションを使ってホスト間で汚染レベルを伝播させる 汚染レベル 15 15 15 クライアント情報は大きくなる可能性があるので、性能を考慮して、汚染レベルに圧縮 攻撃者に汚染レベル15が割り当てられている時、サーバ１が攻撃されると１５になる <click> サーバ２に踏み台攻撃すると、パケットと共に汚染レベルが伝播され、サーバ２も１５になる 重要なデータに１５ではアクセスできないようにしておけばOK 踏み台攻撃 攻撃者 重要なデータ サーバ2 15 サーバ1 セーフティネット

ネットワークレベルのユーザ認証 サーバのアクセス制限に外部ホストの信頼できないIPアドレスは使えない しかし、外部からはアクセスできないのでは不便 外部からのアクセスはユーザ認証に基づき制限 カーネルが自動的にSSLの認証を行う 内部ネットワーク 外部ホストからのアクセス制限にはIPアドレスがよく使われているが、信頼できない かといって、外部からは公開情報のみでは不便 外部から個人情報にアクセスする時は、IPの代わりにユーザ認証を用いる ユーザレベルではバイパスされる恐れがあるので、カーネルレベルでSSLのユーザ認証を行う <click> 信頼できる ユーザA SSL セーフティ ネット ユーザAの 個人情報 サーバ

ネットワークレベルのユーザ認証 サーバのアクセス制限に外部ホストの信頼できないIPアドレスは使えない しかし、外部からはアクセスできないのでは不便 外部からのアクセスはユーザ認証に基づき制限 カーネルが自動的にSSLの認証を行う 内部ネットワーク 信頼できない ユーザ ユーザAの 個人情報 サーバ セーフティネット

実験 Apacheウェブサーバの性能を測定 実験環境 0バイトの同じファイルをリクエストした時の性能 様々なファイルをランダムにリクエストした時の性能 実験環境 サーバ： PentiumIII 933MHz, Compacto OS クライアント： Celeron 300MHz, FreeBSD 3.4 16台 100Mbpsイーサネット WebStoneベンチマーク 次に

実験結果 プロセスクリーニングのオーバヘッド（最大） Fork-Join法に比べた性能向上率 0バイトファイル：36% 様々なファイル：18% Fork-Join法に比べた性能向上率 0バイトファイル：60% 様々なファイル：30% グラフは様々なファイルをランダムにリクエストした場合 横軸はクライアント台数、縦軸は一秒あたりに処理できたリクエスト数 0バイトファイルの場合もほぼ同じ形のグラフ

最適化の効果 コピー方式は再マップ方式より5%速い 静的データの再配置により40%近く性能が改善する コピー方式は再マップ方式より速かった これはApacheではリクエストによってメモリのワーキングセットがあまり変わらず、コピー方式による投機的なコピーが有効に活用できたためである しかし、膨大なデータにランダムにアクセスするようなワーキングセットの大きいサーバは、コピー方式では次々にシャドウページが増えていくのでスワップが頻発して遅くなるかもしれない 静的データの再配置は静的データに関して変更されるメモリページ数が10から1まで減った その結果

第Ⅰ部のまとめ ユーザレベルサーバ用のアクセス制御機構を開発した プロセスクリーニングの性能を測定した プロセスクリーニングを提案した 安全にアクセス制限を変更できる クライアントに応じたセーフティネットを実現した クライアントを正しく認識する技術の開発 プロセスクリーニングの性能を測定した オーバヘッドは最大で36% 従来のFork-Join法より30～60%高速

（Ⅱ）OSモジュール用の 保護機構 ～マルチレベル・プロテクション～ サーバプログラム用のアクセス制御機構はここまで ここからはもう一つのセーフティネット

OSモジュール用の 従来のセーフティネット LKM（ロード可能カーネルモジュール）は範囲が広すぎる 性能はよいが危険 Mach [Accetta et al.’86]は範囲が狭すぎる 安全だが性能が悪い ユーザ プロセス カーネル モジュール モジュール セーフティネット カーネル

性能と安全性のトレードオフ OSモジュールの安定度は様々であるのに、セーフティネットは固定であるのが問題 解決すべき問題 ユーザが性能と安全性のトレードオフを変更できるようにすればよい 解決すべき問題 変更はできるだけ簡単にできるようにすべき 性能を最優先にした時にオーバヘッドができるだけ小さくなるようにすべき 柔軟なトレードオフがとれるようにすべき 従来のは安定度は様々なのにセーフティネットが固定だったために問題が生じた そこでトレードオフを変更できるようにすれば、応じた動的なセーフティネットが構築できる 解決すべき問題がある 性能を再優先にした時、トレードオフを取る機構自体のオーバヘッドができるだけ小さくなるようにすることが重要 性能か安全性かの二者択一ではなく、柔軟なトレードオフ

マルチレベル・プロテクション OSモジュールを様々な保護レベルでOSに組み込むことができる 安定度に応じて性能と安全性のトレードオフを取ることができる 良 悪 性能 OSモジュール セーフティネット これらの問題を解決し、トレードオフを実現するために、マルチレベル・プロテクションを提案している 様々な保護レベルで組み込める モジュールが不安定ならば、マイクロカーネルのようにセーフティネットを狭くして、性能を犠牲にして安全性を高めることができる 逆に、安定しているなら、LKMのようにセーフティネットを広くして性能をよくすることができる カーネル カーネル カーネル 高 低 安全性

保護マネージャ OSモジュールとカーネルの間のゲートウェイ OSモジュールから他の部分を保護する カーネルからの呼び出しを中継する セーフティネット OSモジュールとカーネルの間のゲートウェイ カーネルからの呼び出しを中継する OSモジュールにカーネルデータを安全に操作させる OSモジュールから他の部分を保護する OSモジュール コールバック カーネルデータ の操作 保護マネージャ モジュール 呼び出し アクセス モジュール呼び出しを中継 <click><click> カーネルデータを操作 カーネル

保護レベルの変更 保護マネージャの交換によってOSモジュールの保護レベルを変更する 保護マネージャは複数用意されている それぞれが異なる保護レベルを実現している OSモジュールのソースコードを変更したり、再コンパイルしたりする必要はない 保護マネージャの実体はライブラリ 再リンクのみでよい 保護レベルを変更するには、この保護マネージャを交換する 複数用意されている 保護マネージャの実体はライブラリで再リンクだけでよく、 ...の必要はない 今まで動いていたのを止めて、新しい保護マネージャがリンクされたモジュールを動かせば完了

共通APIの提供 全ての保護マネージャが共通の APIを提供し、交換を容易にする APIの種類 それぞれの保護マネージャの 実装方法の違いを吸収する APIの種類 コールバック用のAPI VFSのインタフェース トランスポート層のインタフェース カーネルデータ操作用のAPI 抽象度の高いデータ構造を見せる システムコール 共通 API VFS VFS UFS NFS ファイルシステム モジュール ソケット層 このように再リンクだけで済ませられるようにするために、共通のAPIを提供している コールバック用のAPIとして ファイルシステムの場合はVFSのインタフェースを提供 VFSはNetBSDで使われている仮想的なレイヤで全てのファイルシステムを統一的に扱える ネットワークの場合はトランスポート層のインタフェースを提供 共通 API TCP UDP ネットワーク モジュール

様々な保護レベルの実現 保護マネージャは以下の保護技術を組み合わせて様々な保護レベルを提供する 不正メモリアクセスの検出 デッドロックの検出 OSモジュールをユーザ空間に配置する カーネルデータを保護する カーネルデータを複製して内容を検査する デッドロックの検出 wait-for-graphを作成して定期的に検査する 保護マネージャは...提供する <click> 不正メモリアクセスを検出するためにカーネル空間ではなく、ユーザ空間に配置できる この時、性能のためにこのOSモジュールが使うカーネルデータはカーネルとOSモジュールの間の共有メモリに置かれる カーネルデータの置かれているメモリを保護でき、保護マネージャを介してアクセスさせるようにできる 複製したカーネルデータにアクセスさせ、書き戻す時に内容を検査できる また、wait-for-graphを作成して、デッドロックを検出できる

アドレス空間の保護 OSモジュールをユーザ空間に配置する OSモジュールがカーネルに影響を与えないようにする アップコールで呼び出す システムコールでカーネルの機能を利用 OSモジュールがカーネルに影響を与えないようにする OSモジュール システムコール アップコール 関数呼び出し カーネル

カーネルデータの保護 カーネルデータの置かれる共有メモリを保護する OSモジュールがカーネルデータを破壊してしまうのを防ぐ OSモジュールに制御がある間はmprotectで保護 保護マネージャに制御がある間はアクセスを許可 OSモジュールがカーネルデータを破壊してしまうのを防ぐ OSモジュール メモリ保護 保護マネージャ カーネルデータ カーネル

カーネルデータの複製 カーネルデータを複製してそれにアクセスさせる OSモジュールがカーネルデータの扱いを誤るのを防ぐ 保護マネージャが内容を検査してから書き戻す OSモジュールがカーネルデータの扱いを誤るのを防ぐ OSモジュール 複製 保護マネージャ 検査＆書き戻し カーネルデータ カーネル

エラーからの回復 OSモジュールのエラーを検出したらカーネルからその影響を取り除く 不正メモリアクセスを検出した場合 以後そのモジュールを参照しないようにする ログを元に安定な状態に戻す デッドロックを検出した場合 wait-for-graphのループを破壊する OSモジュール ロック テーブル 資源 カーネル

実験 NFSサーバモジュールとTCPモジュールの性能を測定 表の５つの保護レベルとカーネルに直接作り込んだものについて実験した 実験環境 ＰＣ（PentiumII 400MHz, CAPELA OS) ２台 10Mbpsイーサネット △：読み出し専用 にして保護

NFSサーバモジュールにおける 実験結果 最高の保護レベルでのオーバヘッド 最低の保護レベルでのオーバヘッド コピー：70% コンパイル：20% 最低の保護レベルでのオーバヘッド コピー：1.4% コンパイル：1.1% NFS上の６４KBのファイルを同じNFS上にコピーする時間 NFS上に展開されたｐｓプログラムのソースをコンパイルする時間 1-5と保護レベルが低くなるにつれて、ほぼ性能もよくなっている handというのは手で作りこんだもの

TCPモジュールにおける 実験結果 最高の保護レベルでのオーバヘッド 最低の保護レベルでのオーバヘッド レイテンシ：220% FTP：16% レイテンシ：2.8% FTP：1.3% ラウンドトリップレイテンシ FTPの転送レート

関連研究 Chorus [Rozier et al.’88] VINO [Seltzer et al.’94] ユーザ空間とカーネル空間のどちらかに透過的にモジュールを配置できる カーネル空間に配置した時のオーバヘッドが大きい VINO [Seltzer et al.’94] SFI[Wahbe et al.’93]によりカーネル内モジュールの不正メモリアクセスを検出する SPIN [Bershad et al.’95] Modula-3で記述することにより不正メモリアクセスを回避する Chorusは二者択一でもある Chorusはマイクロカーネルを速くする目的なので、カーネルに入れた時のオーバヘッドが比較的大きい マイクロカーネルを速くするためにIPCを高速化する研究もあるが、アプリケーションにもよるが、十分にオーバヘッドが小さくないことが多い

第Ⅱ部のまとめ OSモジュール用の保護機構を開発した 実験によりマルチレベル・プロテクションの有用性を確かめた マルチレベル・プロテクションを提案した 性能と安全性のトレードオフをとる 実験によりマルチレベル・プロテクションの有用性を確かめた 保護レベルを低くすると性能が良くなった 保護レベルを最低にした時、作り込みのモジュールの性能に十分近くなった

本発表のまとめ 性能を十分に考慮してソフトウェアの安全性を高めることを目標とした研究を行った サーバソフトウェアに対して動的なセーフティネットを構築した プロセスクリーニングによりサーバのアクセス制限を安全に変更できる マルチレベル・プロテクションによりOSモジュールの性能と安全性のトレードオフをとれる

今後の展望 マルチスレッドサーバへのプロセスクリーニングの適用 マルチレベル・プロテクションにおいて保護レベルを変更するガイドラインの作成 安全性を保つには保護つきのスレッドが必要 メモリの保存・復元に関してはプロセスの場合と大差ない可能性が高い マルチレベル・プロテクションにおいて保護レベルを変更するガイドラインの作成 統計を指標として利用したい OSモジュールの使用年数、使用頻度、開発者のスキルなどに対するバグの減り方を調べる必要がある より高性能なサーバやミドルウェアで使われているマルチスレッドサーバへの適用 これらではリクエストにつき一つのスレッドを割り当てる スレッドには保護がないので、乗っ取りなどの攻撃に対応するには、スレッドに保護を導入する必要がある そうすると、結局、メモリの保存、復元のコストは高そう ガイドライン 現象としてOSのバグの遷移に関する研究はあるが、このようなファクタがまったく考慮されていないので、指標として利用するには不十分

既発表論文 プロセスクリーニング マルチレベル・プロテクション “サーバのアクセス制限を安全に変更するための機構”， 情報処理学会論文誌，42巻6号 “A Secure Access Control Mechanism against Internet Crackers”, IEEE ICDCS’01 (short) マルチレベル・プロテクション “多段階保護機構：拡張可能OSの新しいFail-safe機構”， 情報処理学会論文誌，39巻11号 “Operating System Support for Easy Development of Distributed File Systems”, IASTED PDCS’98 (short)