プロフィール

大山恵弘

  • Author:大山恵弘
  • 公式なサイトはこちら

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブロとも申請フォーム

ブログ内検索

RSSフィード

リンク

FC2カウンター

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

【データベース】 Application-Level Isolation to Cope With Malicious Database Users 【セキュリティ】

In ACSAC 1998.
http://www.acsac.org/1998/abstracts/wed-a-330-jajodia.html

IDSによって、ある人間を怪しいと判断しても、すぐ何か過激な対応をするのははばかられる。判断ミスをしているかもしれない。なので、そのユーザを「隔離」して、さらに調査を続けるのが有効。本論文はデータベースの文脈でその方式を提案。

DBだと、隔離された側と元の側でデータのinconsistencyが生じるので、それを考えて隔離する必要がある。元の側は隔離に関係なくトランザクションを行いたい。

詳しくは読んでないが、隔離機構が存在する状況下での読み出しや更新のプロトコルを提案しているようだ。
スポンサーサイト

【セキュリティ】 Preventing Secret Leakage from fork(): Securing Privilege-Separated Applications 【特権分割】

In ICC 2006.
http://www.cs.berkeley.edu/~daw/papers/

プログラムを複数のプロセスに細切れに分割してセキュリティを高める研究が(昔から類似研究はあるとは思うが)最近いくつか出てきている。Sensitiveなデータにさわる必要があるプログラム部分を高い特権のプロセスで実行、それ以外の部分を低い特権のプロセスで実行、みたいなの。低い特権のプロセスが乗っ取られてもsensitiveなデータは漏れない。

そういうことするのもいいけど、forkによって、trustedな親プロセスからuntrustedな子プロセスに、sensitiveな情報が漏れることがあるから、注意しましょうって話。注意喚起だけではなく、対策手法も提案している。

コードメモリ、データメモリ、スタックメモリ、シグナルハンドラ、環境変数など、様々なデータオブジェクトが、forkで子にコピーされるかどうかを考え、脅威を分析。forkするとき、スタックの未使用領域や、メモリアラインメントの都合で使わなかった領域にsensitiveなデータがあるかもしれないので危ないとか。

制御フロー解析(プログラムスライス)とデータフロー解析(型推論)を組み合わせて、fork時に生きているsensitiveデータを静的に検出。OpenSSHのソースに本方式を適用して解析したところ、OpenSSHでは、親プロセスから子プロセスに情報が漏れない(sensitiveなデータを適切に消去している)ことがわかった。

(少なくとも前半は)地を這うような論文。ワグナー節炸裂!

forkによるデータ漏れがどれくらいの脅威なのか、まだよくわからない。大きな脅威なのかもしれないし、そうでもないのかもしれない。OpenSSHにデータ漏れが見つかってたら、もっとインパクトあっただろうけれども、見つからなかったので、うーむどうでしょうという段階でもある。

Privilege separationの論文が出て3年後に、こういう論文をすかさずきちっと出してくるあたり、見習いたいのう。あぶないぞって警告するだけでなく、プログラムスライシングと絡めた対策手法とセットにしてくるところとか、実世界アプリに適用したところとかも、いい味出してる。

SoftwarePotは、たしか、子プロセスを作ってすぐexecveしてるので、環境変数とファイルデスクリプタとファイルシステムくらいからしか、情報は漏れない。Solaris版では環境変数から変な情報がのぞけたりしますけどね。

【VMM】 Multi-Level Security Requirements for Hypervisors 【セキュリティ】

In ACSAC 2005.
http://www.acsac.org/2005/abstracts/154.html

Multi-level Securityを実現するhypervisorの設計について議論。実装も実験も提案システムもない異色の論文。

Pure isolation hyperviror: VM間を完全に隔離して資源共有ができないようにするhypervisor。実装が楽。「完全隔離」という唯一のセキュリティポリシーを強制すればいいだけなので。
IBM PR/SMとかhp NetTopとか。

Sharing hypervisor: VM間の資源共有を許すhypervisor。
IBM z/VMとか。

Sharing hypervisorの最も重要な特徴はsecure shared file storeである。secure shared file storeはhypervisor組み込みで実装する方法と、信頼できるVMパーティションが提供する方法と二種類ある。

Pure isolation hypervisorでは簡単に実装できないアプリケーションが多く存在する。ゆえにsharing hypervisor (ていうかsecure shared file store)が必要である、と展開。

【セキュリティ】 Trusted Virtual Domains: Toward Secure Distributed Services 【分散システム】

In HotDep '05
http://www.ece.cmu.edu/~leendert/

安全な分散計算のための枠組みTrusted Virtual Domains (TVD)の提案。

アプリケーションは複数のコンポーネントに分けられる。
各コンポーネントは、ある役割を演じる遠隔実体によって実行される。

遠隔実体の役割は、その実体が行うことができる操作に対する制限を含む。

各実体が役割に沿って動くことはインフラ層が保証。

サービスの提供者は、自分は何をどう保護するかを表明。
サービスの利用者は、どんな保護が必要かを表明。

サービス利用者の要求にしたがって、
複数のハードウェアをまたがった仮想ドメインが作られるようだ。
VPNをもっと激しくしたようなもの?
一つのセキュリティポリシーを、参加全ノードに強制することができる。

実装はTPMベースハードウェアと仮想マシンモニタによる。

なんかTerraっぽいかんじ。

仮想マシン技術を用いて複数の計算機を自律的に連合させ、複数の計算機上に一つの仮想実行空間を生成する研究としては、他にも、こことかこことかがあります。

【セキュリティ】 Sub-Operating Systems: A New Approach to Application Security 【アクセス制御】

In SIGOPS European Workshop 2002.
http://www.cis.upenn.edu/~sotiris/thevillage/6private/cv.html

メールやftpなどで流通する、危険かもしれないコンテンツを安全に実行する方法。

コンテンツを実行するユーザの権限を与えてプロセスを実行するのが問題と主張。

コンテンツにsub user-idをつけて配布。そのコンテンツを実行するプロセスには、そのコンテンツのsub user-idが付加される。そのプロセスはsub user-idの権限でアクセスできる資源にしかアクセスできない。要するにコンテンツ作成者の権限で、コンテンツ処理プログラムを実行する。

sub user-idを暗号的に検証することにより詐称を防ぐ。

OpenBSDを拡張して実装。open, exec, forkなどのシステムコールを拡張して実装。sub user-idはファイルのinodeの部分およびプロセス構造体の中に格納される。

グローバルなsetuidというか、Javaのpermissionというか、テイントというか。

メール添付ファイルを安全に実行する枠組みの提案としては、他にも、これとか、これとかがあります。

| ホーム |


 BLOG TOP 


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。