JP2004501467A - Filtering permission sets using permission requests related to code assembly - Google Patents

Abstract

A security policy manager generates a permission grant set for a code assembly received from a resource location. The policy manager can execute in a computer system (e.g., a Web client) in combination with the verification module and class loader of the run-time environment. The permission grant set generated for a code assembly is applied in the run-time call stack to help the system determine whether a given system operation by the code assembly is authorized. A permission request set may also be received in association with the code assembly. The permission request set may include a minimum request set, specifying permissions required by the code assembly to run properly. The permission request set may also include an optional request set, specifying permissions requested by the code assembly to provide an alternative level of functionality. In addition, the permission request set may include a refuse request set, specifying permissions that are not to be granted to the code assembly. The permission requests are used to filter a permission set to generate a permission grant set.

Description

【０００８】
この例では、ソースロケーション”ｗｗｗ．ＢｏｂｓＷｉｄｇｅｔｓ．ｃｏｍ”からのアプレットが、ＢｏｂｓＣｅｒｔｉｆｉｃａｔｅの中に含まれる他の鍵に対応する鍵で署名されている場合、このアプレットに、あるファイルアクセス許可を交付する。アプレットは、従来、オペレーティングシステム内から直接にではなく、ブラウザ内から実行されるように設計されたプログラムである。このアプレットには、ホストシステム上の「／ｔｍｐ」ディレクトリからファイルを読み取り、また「／ｔｍｐ／ｂｗｄｉｒ」ディレクトリの中にファイルを作成し、書き込む許可が交付される。別の一般的な許可修飾子が、「実行する」許可である。その他のセキュリティポリシー指定により、例えば、アプリケーションのソースに関わらず、またはアプリケーションに署名されているか、署名されていないかに関わらず、任意のシステムロケーションにおけるファイルにアクセスする広い許可が交付されることが可能である。
【０００９】
そのような手法では、セキュリティポリシーは、特に静的であり、長期間にわたり固定されたままである。インターネットを介するオンデマンドアプリケーション処理がより一般的になるにつれ、実質的に、静的セキュリティポリシーでは、あまりにも制約がある。さらに、実際に行われる（通常、システム管理者によって行われる）頻度の低いセキュリティポリシー変更は、セキュリティの弱点またはセキュリティギャップを導入する、または前にアクセスの許可を受けたアプリケーションにアクセスを行うことを拒否することにより、許可されたアプリケーションが実行されるのが妨げられる可能性がある。このため、既存のセキュリティアーキテクチャは、ユーザのシステムに対するある量のアクセスをアプリケーション（またはアプリケーションの所与のコードアセンブリ）に任せることができるかどうかを動的に、また柔軟に判定することができない。
【００１０】
さらに、既存のセキュリティフレームワークでは、許可の割振りが、ユーザのシステムにおいて定義されたセキュリティポリシーによって決定され、場合によっては、アプリケーションの実行中またはロード中のユーザに対するクエリによって決定される。このため、オンデマンドアプリケーションの構成要素は、一般に、どの許可がセキュリティポリシーに従って割り振られるかに影響を与えない。例えば、許可されたロケーションからの構成要素に、コンピュータシステムの保護されたエリアに対する広汎なアクセスが交付される可能性があり、その構成要素が、そのようなアクセスを必要としない、または所望さえしない可能性があっても交付される可能性がある。責任上の理由から、構成要素は、より限られたアクセスを所望する可能性がある。さらに、構成要素は、最低限の許可のセットなしには、実行することができない可能性がある。既存のセキュリティフレームワークでは、コードアセンブリの実行中、許可が欠如されているために要求された動作が失敗したときにだけ、不十分な許可交付セットが検出され、その時点では、実行時間が無駄になっており、誤り回復がより複雑である可能性がある。
【００１１】
（発明の概要）
本発明によれば、以上の問題およびその他の問題が、リソースロケーションから受け取られたコードアセンブリに対して許可交付セットを生成する証拠ベースのポリシーマネージャによって解決される。許可交付セットは、コードアセンブリに関連して受け取られた許可要求によって影響される（例えば、フィルタされる）ことが可能である。許可要求は、コードアセンブリの許可ニーズの特性を定義することができる。例えば、許可要求は、少なくとも基本的機能を伴って適切に動作するのにコードアセンブリによって必要とされる許可を指定する最低限の許可セットを含むことが可能である。また、許可要求は、代替レベルの機能を提供するのにコードアセンブリによって必要とされる許可を指定するオプションの要求セットを含んでもよい。さらに、許可要求は、コードアセンブリに交付されるべきでない許可を指定する拒否要求セットを含むことも可能である。
【００１２】
本発明の実施形態では、リソースロケーションから受け取られたコードアセンブリに関連する許可セットを処理するための方法が提供されて、コードアセンブリの実行が制御される。許可セットは、コードアセンブリに関連する少なくとも１つの許可を含む。許可要求セットは、コードアセンブリに関連して受け取られる。許可セットが、許可要求セットに基づいてフィルタされてコードアセンブリの実行が制御される。
【００１３】
本発明の別の実施形態では、方法は、１つ以上のコードグループにおけるコードアセンブリのメンバーシップに基づいて許可セットを生成することをさらに含む。コードグループ集合が、セキュリティポリシー指定に基づいて定義される。コードグループ集合は、１つ以上のコードグループを含む。証拠が、コードアセンブリに関連して受け取られる。１つ以上のコードグループにおけるコードアセンブリのメンバーシップが、その証拠に基づいて評価される。
【００１４】
本発明のさらに別の実施形態では、リソースロケーションから受け取られたコードアセンブリに関連する許可セットを処理してそのコードアセンブリの実行を制御するためのポリシーマネージャモジュールが提供され、このモジュールは、コードアセンブリに関連する許可セットおよび許可要求セットを受け取るフィルタを含む。また、フィルタは、許可要求セットに基づいて許可セットをフィルタして、コードアセンブリの実行を制御する。
【００１５】
本発明のその他の実施形態では、製造品が、コンピュータプログラム（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ ｐｒｏｄｕｃｔｓ）として提供される。コンピュータプログラムの一実施形態は、コンピュータシステムによって読取り可能であり、リソースロケーションから受け取られたコードアセンブリに関連する許可セットを処理してそのコードアセンブリの実行を制御するためのコンピュータプロセスを実行するためのコンピュータプログラムを符号化するコンピュータプログラム記憶媒体を提供する。コンピュータプログラムの別の実施形態は、コンピュータシステムによるキャリアで実現され、リソースロケーションから受け取られたコードアセンブリに関連する許可セットを処理してそのコードアセンブリの実行を制御するためのコンピュータプログラムを符号化するコンピュータデータ信号で提供することができる。
【００１６】
一実施形態では、コンピュータプログラムは、セキュリティポリシー指定に基づいてコードグループ集合を定義するコンピュータプロセスをコンピュータシステム上で実行するためのコンピュータプログラムを符号化する。コードグループ集合は、１つ以上のコードグループを含む。証拠が、コードアセンブリに関連して受け取られる。１つ以上のコードグループにおけるコードアセンブリのメンバーシップが、その証拠に基づいて評価される。許可セットは、その１つ以上のコードグループにおけるコードアセンブリのメンバーシップに基づいて生成される。許可セットは、コードアセンブリに関連する少なくとも１つの許可を含む。許可セットおよび許可要求セットに対して論理集合演算が行われて、許可交付セットが生成される。
【００１７】
本発明の実施形態の大きな効用は、許可要求に従ってポリシーマネージャによってコードアセンブリに交付される許可がフィルタされることである。これにより、コードアセンブリが、適用可能なセキュリティポリシーが許すものと協調して、自らが受け取る許可に影響を与える。許可は、コンピュータシステム内部でコードアセンブリの実行を制御するのに使用される。コードアセンブリによって実際に要求された許可だけを交付するのが有利である。例えば、セキュリティポリシーが、信頼されるコードアセンブリに広い許可を交付することが可能である。ただし、そのコードアセンブリが所与の許可を要求しない場合、そのコードアセンブリにおける誤りによって生じさせられるようなコンピュータシステムの保護されたエリアへの不慮のアクセスを回避することができる。さらに、コードアセンブリは、所与の許可のセットを拒否して、コンピュータシステムの保護されたエリアにアクセスする（また、場合によっては破壊する）ことで責任を負う可能性にさらされるのを回避することができる。
【００１８】
本発明を特徴付ける以上の特徴およびその他の様々な特徴、並びにその他の利点は、以下の詳細な説明を読み、関連する図面を詳しく見ることで明白となる。
【００１９】
（発明の詳細な説明）
本発明の実施形態は、リソースロケーションから受け取られたコードアセンブリに関する許可交付セットを生成する証拠ベースのポリシーマネージャを提供する。一般に、コードアセンブリは、．ＥＸＥファイル、または．ＤＬＬファイルなどのパッケージ化されたコードの単位である。ポリシーマネージャは、ランタイム環境の確認モジュールおよびクラスローダと組み合わせで、コンピュータシステム（例えば、Ｗｅｂクライアントまたはネットワーク化されたワークステーション）において実行することができる。ただし、ポリシーマネージャはランタイム環境の外部でも実行することができる。コードアセンブリに対して生成された許可交付セットが、ランタイム呼出しスタックの中で適用されて、システムがコードアセンブリによる所与のシステム動作が許可されるかどうかを判定するのを助ける。ポリシーマネージャは、コードアセンブリに関連して受け取られた許可要求を処理することができる。さらに、コードアセンブリと証拠をともに、ローカルソース（例えば、ローカルのマシン内部から）、ローカルネットワークまたは周辺機器、またはネットワーク（例えば、インターネット）を介する遠隔リソースロケーションから受け取ることができる。
【００２０】
本発明の実施形態では、許可要求を使用して、コードアセンブリに関連して受け取られたセキュリティポリシー指定および証拠に基づいてポリシーマネージャによって最初に提供された許可がフィルタされる。これにより、コードアセンブリが、そのコードアセンブリに関連付けられる結果の許可交付セットに影響を与えて、過度の、または不必要な許可を受け取るのを回避するようにすることができる。
【００２１】
図１は、本発明の実施形態における証拠ベースのセキュリティポリシーマネージャ１０４を描いている。サーバなどのリソースロケーション１００がネットワーク（図示せず）を介してコンピュータシステム１０２（例えば、ＷｅｂクライアントまたはＷｅｂサーバ）によってアクセス可能である。リソースロケーションは、一般にＵＲＩ（ユニフォームリソース識別子）で示され、ＵＲＩはＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ上のオブジェクトを参照するすべてのタイプの名前およびアドレスの総称である。ＵＲＬ（ユニフォームリソースロケータ）は一種のＵＲＩである。例としてのリソースには、限定するものとしてではなく、ネットワークを介してアクセス可能なドキュメント、イメージ、オーディオデータ、アプリケーション、ルーチン、並びにその他のデータおよびコードデータストアが含まれることが可能である。リソースロケーションは、コンピュータシステム１０２にローカルであることもコンピュータシステム１０２に遠隔である（例えば、インターネットで結合される）ことも可能であることを理解されたい。
【００２２】
本発明の実施形態に関係のある１つのタイプのリソースが、コードアセンブリである。コードアセンブリは、例えばアプレットコード、アプリケーションコード、クラスコード、ルーチンコード、およびデータから成ることが可能である。コードアセンブリに含まれるコードおよびデータは、バイトコード、中間コード、マシンコード、およびデータ構成要素（クラス、イメージ、オーディオクリップおよびビデオクリップ等）の形であることが可能である。さらに、リソースロケーションからダウンロードされる１つ以上のクラスを含むアーカイブファイルにコードアセンブリをパッケージ化することもできる。本発明の一実施形態では、アプリケーションのクラスを組み合わせてモジュール（リンクプロセスの出力）にし、また１つ以上のモジュールを組み合わせてコードアセンブリにすることができる。
【００２３】
図１は、コンピュータシステム１０２上で実行されるダウンロードされたアプリケーションに関して描かれている。別の実施形態は、ダウンロードされたアプレット、ＡＣＴＩＶＥＸコントロール、並びにその他のルーチンおよびオブジェクトを含んでいてもよい。一例としてのダウンロードされたアプリケーションは、１つ以上のローカルまたは遠隔のコードアセンブリにおいて定義されたオブジェクトから成る。ローカルコードアセンブリは、コンピュータシステム１０２内部に記憶され、必要なときにメモリの中にロードされる。遠隔コードアセンブリは、リソースロケーション１００のようなリソースロケーションからダウンロードされる。
【００２４】
コンピュータシステム１０２が、ランタイム環境を開始してダウンロードされたアプリケーションを実行し、システム１０２のセキュリティを管理する。コンピュータシステム１０２のランタイム環境は、ランタイム環境の外部にあるオペレーティングシステムシェル、ブラウザ、ＳＱＬサーバ、またはその他のコードなどの「信頼されるホスト」によって初期化されることが可能である。ホストも、アプリケーションを構成する様々なコードアセンブリ１０６をシステム１０２にダウンロードし、実行のために仮想マシン１１０にそのコードアセンブリ１０６を渡すことによってアプリケーションの実行を開始する。
【００２５】
仮想マシンは、別個のコンピュータの機能の多くを実行する自己完結型の動作環境を提供する。例えば、ホストオペレーティングシステムに直接にアクセスすることなく、仮想マシンにおいてアプリケーションを実行することができる。この設計は、少なくとも２つの利点を有する。
・システム独立性：アプリケーションは、システムの基礎となるハードウェアおよびソフトウェアに関わらず、そのアプリケーションが書かれているプログラミング言語をサポートする任意の仮想マシンにおいて同様に実行される。例えば、同一のアプリケーション（すなわち、同一のプログラミングコード）が、異なるタイプのマイクロプロセッサおよび異なるタイプのオペレーティングシステムを有する、異なるコンピュータシステム上の仮想マシンにおいて実行されることが可能である。
・セキュリティ：仮想マシンにおいて実行されているアプリケーションが、一般に、保護されたシステムリソース（すなわち、オペレーティングシステム、ファイルシステム、メモリの保護された領域、接続されたネットワークまたは接続された周辺機器）にアクセスするのが防止される。ただし、本発明の実施形態は、証拠およびセキュリティポリシーを評価して、アプリケーションが保護されたシステムリソースにアクセスするのを許すかどうかを判定できることを理解されたい。所与の動作（ｏｐｅｒａｔｉｏｎ）に対する許可が交付された場合、アプリケーションは、その動作に関して「信頼される」ものとみなされる。コードアセンブリに関連して受け取られた許可要求を使用して、そのコードアセンブリがどの動作を行うことができるかを判定するのに使用される結果の許可交付セットをフィルタすることができる。
【００２６】
アプリケーション構成要素（例えば、ダウンロードされたコードアセンブリ１０６）がシステム１０２によって受け取られ、確認モジュール１１２がコードアセンブリ１０６の中のダウンロードされたコードが適切にフォーマットされており、コード言語または仮想マシン１１０の安全制約に違反しないことを確かめる。また、ポインタアドレス指定が存在しないこと、内部スタックにオーバーフローまたはアンダーフローが生じるのが不可能なこと、コード命令が正しく分類されたパラメータを有することを確認するなどのその他の確認も行うことができる。次に、コードアセンブリはクラスローダ１１３に渡され、クラスローダ１１３は、そのアプリケーションが、ランタイム環境内でシステムレベル構成要素に置き換わらないことを確実にする（すなわち、クラスローダは、ホストによって提供されたコードアセンブリが、要求されたときに実行されることを強制し、これにより、ダウンロードされたコードアセンブリとの名前のコンフリクトを排除する）。その後、クラスローダ１１３は、仮想マシン１１０からの要求に応答してランタイム呼出しスタック１１４上にコードアセンブリ１０６をロードする。
【００２７】
例えば、仮想マシンが、第２のコードアセンブリ（例えば、図２のパーサコードアセンブリ）によって提供されるルーチンを呼び出す第１のコードアセンブリ（例えば、図２のメインコードアセンブリ２０２）を実行する。クラスローダ１１３が第２のコードアセンブリに関する仮想マシンの要求を受け取り、第２のコードアセンブリをランタイム呼出しスタック１１４にロードして、第１のコードアセンブリが、必要とされるルーチンを呼び出すことができるようにする。
【００２８】
保護された領域に対する許可のないアクセスが防止されるのを確実にするため、ダウンロードされたコードアセンブリ１０６のそれぞれに関連する証拠１０８がポリシーマネージャ１０４に入力される。ポリシーマネージャ１０４は、各コードアセンブリに関連する許可交付セットを判定する（図４の許可交付セット４１４参照）。また、セキュリティポリシー指定１１６もポリシーマネージャ１０４に入力されて、適切な交付の計算を助ける。さらに、許可要求１２０がダウンロードされたコードアセンブリ１０６に関連して受け取られて、それぞれダウンロードされたコードアセンブリ１０６の許可ニーズの特性が指定される。一実施形態では、許可要求は、コードアセンブリ自体の中に２進シリアル化フォーマットで記録され、したがって、単一回のネットワーク通信でコードアセンブリとともにダウンロードされる。あるいは、許可要求は別のネットワーク通信でポリシーマネージャ１０４によってアクセス可能なリソースロケーションにおける別のどこかに記録されていてもよい。さらに、許可要求を記録することに関して２進シリアル化フォーマットが例としてのフォーマットとして指定されているが、本発明の範囲内で別のデータフォーマット（例えば、ＸＭＬ）も企図される。
【００２９】
さらに、ＸＭＬなどの１つのデータフォーマットが、許可要求を初期に指定するのに開発者によって使用されることが可能である。したがって、コードアセンブリに組み込むため、ＸＭＬ仕様の許可要求を２進シリアル化フォーマットなどの別のデータフォーマットに符号化することができる。さらに、一部のコンパイラは、開発者がコードアセンブリのソースコードの中で宣言セキュリティ注釈を使用して許可要求を指定できるようにしている。次に、コンパイラは、その注釈を符号化してコードアセンブリに組み込まれた許可要求にすることができる。
【００３０】
本発明の実施形態では、許可要求１２０は「分類（ｔｙｐｅｄ）」されており、したがって、各タイプの許可要求を適用して許可を異なる仕方でフィルタすることができる。以上の入力に基づき、ポリシーマネージャ１０４は各コードアセンブリに関する適切な交付を計算し、結果の許可交付セットをランタイム呼出しスタック１１４に渡す。
【００３１】
このため、ランタイム呼出しスタック１１４の中の各コードアセンブリは、対応する許可交付セット（例えば、図２の許可交付セット２０８、２１０、および２１２）に関連付けられている。交付セットがポリシーマネージャから受け取られ、対応するコードアセンブリに関して計算された様々な許可を定義する。各コードアセンブリに関連する許可は、すべて「証拠」１０８と呼ばれる、コードアセンブリの相対的出所（例えば、ローカルまたは遠隔）、コードアセンブリの特定の出所（例えば、特定のＵＲＬ）、またはコードアセンブリのその他の信頼特性に基づいて大幅に異なる可能性がある。本発明の実施形態では、信頼特性を使用して所与のコードアセンブリに関する許可交付セットが判定される。さらに、セキュリティポリシー指定１１６により、所与のコードアセンブリの信頼特性が評価される所与の企業、マシン、ユーザ、アプリケーション等に関するセキュリティフレームワーク内で、複数のポリシーレベルを定義することが可能である。
【００３２】
図２は、呼び出された順序で積み重ねられた個々のコードアセンブリを含むランタイム呼出しスタック２００を表している。個々のコードアセンブリは、遠隔リソースロケーションからダウンロードすること、または図１のコンピュータシステム１０２からローカルで取り出すことが可能である。個々のコードアセンブリは、図１の仮想マシン１１０によるアクセスおよび実行のためにクラスローダ１１３によってランタイム呼出しスタック１１４にロードされる。
【００３３】
例えば、コードアセンブリ２０２中のメインアプリケーションクラスのオブジェクトが、まずクラスローダにより、図示するランタイム呼出しスタック２００にロードされる。仮想マシンがそのメインクラスを実行すると、メインクラスはコードアセンブリ２０４からパーサオブジェクトを作成し、そのパーサオブジェクト中のメソッドを呼び出してコンピュータシステムの保護された領域中のデータファイルを構文解析する。したがって、クラスローダがコードアセンブリ２０４のパーサコードをランタイム呼出しスタック２００にロードする。その後、パーサオブジェクトがコードアセンブリ２０６からファイルアクセスオブジェクトを作成し、そのファイルアクセスオブジェクトの中のメソッドを呼び出して保護されたファイルに対する読取り動作を行う。したがって、クラスローダがコードアセンブリ２０６のファイルアクセスコードをランタイム呼出しスタック２００にロードする。
【００３４】
各許可交付セットが、ランタイム呼出しスタックの中のコードアセンブリに対応する。このため、保護されたリソースにアクセスしようとするコードアセンブリの試みが、関連する許可交付セット、並びにランタイム呼出しスタック２００中のその他のコードアセンブリの許可交付セットに照らして評価される。図２で示したアプリケーションによる保護されたファイルに対する読取り動作の例では、メインコードアセンブリ２０２が、許可交付セット２０８に関連している。メインコードアセンブリ２０２が許可交付セット２１０に関連しているパーサコードアセンブリ２０４の中のメソッドを呼び出す（矢印２１４で表される）。保護されたファイルにアクセスするため、パーサコードアセンブリ２０４は許可交付セット２１２に関連するファイルアクセスコードアセンブリ２０６中のメソッドを呼び出す（矢印２１６で表される）。ファイルアクセスコードアセンブリ２０６が保護されたファイルにアクセスすることができるかどうかを判定するため、許可交付セット２０８、２１０、２１２の「積集合（ｉｎｔｅｒｓｅｃｔｉｏｎ）」が計算され、ファイルアクセス動作が許可されるかどうかを判定するのに使用される。例えば、許可交付セット２１２が保護されたファイルから読取りを行う許可を含むが、許可交付セット２０８または２１０の一方は、それを含まない場合には、保護されたファイルに対するアクセスが拒否される。
【００３５】
一般に、「積集合」演算（記号「∩」で表される）は、オペランドセットの共通要素をもたらす集合演算である。例えば、Ｓｅｔ１が要素Ａ、Ｂ、およびＣを含み、Ｓｅｔ２が要素Ｂ、Ｃ、およびＤを含む場合には、Ｓｅｔ１とＳｅｔ２の積集合（すなわち、Ｓｅｔ１∩Ｓｅｔ２）は、ＢおよびＣに等しい。これとは対照的に、「和集合」演算（記号「∪」で表される）は、オペランドセット中のすべての要素（すなわち、セット中のすべての要素の重複しない集合）をもたらす集合演算である。例えば、Ｓｅｔ１が要素Ａ、Ｂ、およびＣを含み、Ｓｅｔ２が要素Ｂ、Ｃ、およびＤを含む場合には、Ｓｅｔ１とＳｅｔ２の和集合（すなわち、Ｓｅｔ１∪Ｓｅｔ２）は、Ａ、Ｂ、Ｃ、およびＤに等しい。
【００３６】
図３は、本発明の実施形態における証拠ベースのセキュリティを管理するためのコンピュータシステムを描いている。サーバ３００（例えば、Ｗｅｂサーバ）が、通信網（図示せず）を介してクライアント３０２（例えば、Ｗｅｂクライアント）に結合される。クライアント３０２は、ランタイム環境（例えば、マイクロソフト（登録商標）コーポレーションからのＣＯＭ＋２．０ランタイム環境）を実行してクライアント３０２上のアプリケーションの実行を管理する。本発明の実施形態では、ランタイム環境は、確認モジュール３０４、ローダモジュール３０６、およびポリシーマネージャ３０８を含む。
【００３７】
前述した通り、仮想マシン３１２による実行のためにコードアセンブリがランタイム呼出しスタック３１８にロードされる。コードアセンブリの第１のカテゴリはローカルコードアセンブリ３１４によって代表され、ローカルコードアセンブリ３１４はクライアント３０２上を出所（ｏｒｉｇｉｎ）としているため、一般に、信頼されるコードアセンブリとみなされる。これとは対照的に、コードアセンブリの第２のカテゴリは、ダウンロードされたコードアセンブリ３１６によって代表され、ダウンロードされたコードアセンブリ３１６は、サーバ３００などの遠隔のリソースロケーションまたは信頼されないリソースロケーションを出所とする可能性がある。本発明の実施形態では、ローカルコードアセンブリ３１４およびダウンロードされたコードアセンブリ３１６が、確認のために確認モジュール３０４に入力される。その後、コードアセンブリは、ローダモジュール３０６に入力されてランタイム呼出しスタック３１８にロードされる。
【００３８】
コードアセンブリ３１４および３１６は、一般に、各コードアセンブリに関する許可交付セットを計算するのに使用される証拠（または証明）に関連している。一例としての証拠構成要素は、ＡＵＴＨＥＮＴＩＣＯＤＥ署名であることが可能である。別の例としての証拠構成要素は、ＰＩＣＳ（インターネットコンテンツ選択のためのプラットフォーム）ラベルであり、ＰＩＣＳラベルは、インターネットリソースのプロパティ（例えば、実行可能コードがウイルス検査済みである）を述べる。ＰＩＣＳラベルに関するさらなる詳細は、Ｐ．ＲｅｓｎｉｃｋおよびＪ．Ｍｉｌｌｅｒによる「ＰＩＣＳ：Ｉｎｔｅｒｎｅｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｓ ｗｉｔｈｏｕｔ Ｃｅｎｓｏｒｓｈｉｐ（検閲なしのインターネットアクセス管理）」、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ＡＣＭ， ３９（１９９６年）、８７〜９３ページで述べられており、この論文は、ｗｗｗ．ｗ３．ｏｒｇ／ｐｕｂ／ＷＷＷ／ＰＩＣＳ／ｉａｃｗｃｖ２．ｈｔｍにおいても閲覧可能である。証拠のその他の例には、限定するものとしてではなく、購入の証明またはライセンス、作成者識別子、ベンダ識別子、バージョニング情報、およびプログラム式の証明が含まれることが可能である。プログラム式の証明は、例えば、他の証明によって行われたステートメントを検査し、ネットワークから補足の情報をフェッチしてから、どの証拠ステートメントをポリシーマネージャ３０８に提供するかを決定するプログラムコードの形態であることが可能である。
【００３９】
コードアセンブリ自体に関する証拠は、ホストによって提供されること、またはコードアセンブリ自体から抽出することが可能である。ローカルの、またはホストによって提供される証拠３２２は黙示的に信頼され、真であると信じられる。ただし、ダウンロードされた、またはアセンブリによって提供された証拠３２０は黙示的に信頼されることはなく、自己確認が行われるか（例えば、デジタル署名されている）、または独立に確認されるものでなければならない。ダウンロードされた証拠３２０は、１つ以上のリソースロケーションからダウンロードされていることが可能であり、コードアセンブリの出所であるリソースロケーションからダウンロードされた証拠に限定されない。
【００４０】
ローカルの証拠３２２およびダウンロードされた証拠３２０はポリシーマネージャ３０８に入力され、ポリシーマネージャ３０８はセキュリティポリシーに基づいてその証拠を評価する。ポリシーマネージャ３０８内部で、証拠がセキュリティポリシー指定３２６（およびオプションとして、コードアセンブリによって要求された許可セットを定義する許可要求３２４）との組み合わせで評価されて、所与のコードアセンブリに対応する最終の許可交付セットが生成される。
【００４１】
本発明の実施形態では、許可要求３２４は１つ以上のコードアセンブリ３１４および３１６に関連し、３つのタイプの許可要求セット、すなわち、（１）最低限の要求セット（ＭｉｎＲＳ）、（２）オプションの要求セット（ＯｐｔＲＳ）、および（３）拒否要求セット（ＲｅｆｕｓｅＲＳ）の少なくとも１つを含むことが可能である。本発明の範囲内で別のタイプの許可要求セットも企図されることを理解されたい。
【００４２】
本発明の一実施形態（図６のフィルタリングの流れ図を参照）では、ＭｉｎＲＳおよびＲｅｆｕｓｅＲＳに関するデフォルト値が、空集合に等しく、またＯｐｔＲＳに関するデフォルト値が、全集合に等しい。この結果、許可要求が全く提供されない場合には、図４の中間許可セット４２２が、結果の許可交付セット４１４として交付される。
【００４３】
最低限の要求セットは最低限の許可条件を定義しており、関連するコードアセンブリが実行されるのに必要とする最低限の許可のセットを含むことが可能である。ポリシーマネージャ３０８によって生成された許可交付セットが最低限の許可条件を満たさない場合（例えば、最低限の要求セットが図５の許可セット生成器５１８によって出力される中間許可セットのサブセットではない場合）は、ポリシーマネージャ３０８は、関連するコードアセンブリ３１４または３１６がロードされるべきでないとローダ３０６に知らせるポリシー例外を発生させる。この実施形態では、コードアセンブリのロードおよび実行に先立って、最低限の要求セットが関わるセキュリティ判定が評価される。あるいは、ポリシーマネージャ３０８が、コードアセンブリが不十分な許可交付セットを伴ってロードされるのを許すことが可能であり、ただし、この不十分な許可交付セットのため、コードアセンブリは実行することができない。
【００４４】
限定するものとしてではなく、順序付けされた要求セットの少なくとも１つが中間許可セットのサブセットである場合、最低限の許可条件が満たされる複数の順序付けされた要求セットを提供することを含め、本発明の範囲内で別の最低限の許可条件を使用することもできる。このため、満たされる第１の順序付けされた要求セットを使用して中間許可セットをフィルタすることができる。
【００４５】
さらに、限定するものとしてではなく、最低限の許可条件が満たされていないことを示す関連するコードアセンブリ３１４または３１６に関連する属性を設定することを含め、コードアセンブリが実行されるのを防止するための別の技法を使用することもできる。例えば、ローダ３０６が各コードアセンブリに関する属性を検査してから、コードアセンブリをロードすることに取りかかることが可能である。また、ローダ３０６が結果を仮想マシン３１２に戻して、コードアセンブリのロードが失敗し、実行できないことを示すことも可能である。
【００４６】
本発明の別の実施形態では、クライアント３０２内部のランタイム環境が、最低限の要求セットを満たす許可をコードアセンブリが獲得するのに失敗したのに応答して、修正処置を提供しようと試みることが可能である。例えば、最低限の要求セットが所与の保護されたディレクトリに書き込むための必須の許可を含む場合、ランタイム環境がユーザにクエリを行ってこの許可を交付することが可能である。さらに、ユーザが、そのような必須の許可を対話式に交付するのに必要とされる権限は、ユーザの身元に基づいて制限することができる（例えば、管理者ステータスを有するユーザだけが、対話式にそのような許可を交付することができる）。
【００４７】
オプションの要求セットは、交付されることをコードアセンブリが選好するが、コードアセンブリが実行されるのに絶対的に必要ではない許可を含む。そのようなオプションの許可により、コードアセンブリが、より高い機能を提供することが可能になる。ただし、オプションの許可が交付されない場合には、最低限の要求セットによって定義されるより基本的な機能がそれでも利用可能である。
【００４８】
本発明の一実施形態は、コードアセンブリにオプションの機能を組み込むことによってオプションの要求セットのオプションとしての性質を扱う。つまり、オプションの要求セット中の許可のいくつか、またはすべてが交付されなかった場合、コードアセンブリは、実行中、要求の動作が拒否されたとき（または、要求のオプションの許可が拒否されたとき）、このことを知ることができる。そのような拒否に応答して、コードアセンブリは、最低限の許可セットの中で示される許可などの、異なる許可を利用する別の、または追加のコードを実行することができる。この実施形態では、オプションの要求セットが関わるセキュリティ判定がコードアセンブリの実行中に評価される。
【００４９】
別の実施形態では、複数のオプションの要求セットが、ポリシーマネージャ３０８によって取得されてもよい。複数のオプションの要求セットを処理して、複数のレベルの機能に対応して要求された許可を指定するようにしてもよい。許可セットによって満たされることが可能な、または可能でないオプションの要求セットに基づき、ポリシーマネージャ３０８は、１つ以上のクラスをロードするのを除外するようローダ３０６に合図することができる。例えば、所与のクラスによって必要とされる許可が入手可能でないことをローダ３０６が事前に知っている場合、そのクラスをロードすることが必要ない可能性がある。そのようなオプションの要求セットに順序付けを行って、最高レベルの許可交付により、適切なコードアセンブリのロードが行われて、最高レベルの機能が提供されるようにすることができる。
【００５０】
あるいは、オプションの要求セットを使用してオプションの許可のグループを指定することができる。例えば、第１のレベルの機能を提供するのに、コードアセンブリが許可Ａ、Ｂ、Ｃ、およびＤ（第１のオプションの要求セットによって指定される）を必要とし、一方、第２のレベルの機能を提供するのに、そのコードアセンブリが許可ＡおよびＢ（第２のオプションの要求セットによって指定される）だけしか必要としないことが可能である。このため、許可セットが許可Ａ、Ｂ、およびＣだけしか提供できない場合、第１のオプションの要求セットは満たされないが、第２のオプションの要求セットは満たされる。したがって、第２のオプションの要求セットが許可セットをフィルタして許可ＡおよびＢだけを提供し、許可Ｃの不必要な交付を回避する。
【００５１】
さらに、確認モジュール３０４における確認プロセス、およびポリシーマネージャ３０８におけるセキュリティ管理プロセスが、同時に実行されることが可能であり、この２つのプロセスは、互いに影響を及ぼすように通信することができる。例えば、ポリシーマネージャ３０８は、証拠を評価して、所与のコードアセンブリのタイプの安全性が保証されるのを示すことができる。したがって、このタイプの安全性の保証が確認モジュール３０４に伝えられることが可能であり、確認モジュール３０４は、その情報に基づいてタイプを検査する動作をスキップすることができる。あるいは、確認モジュール３０４が、所与のコードアセンブリがタイプの安全性の検査に合格しないと判定することができる。これに応答して、確認モジュール３０４はポリシーマネージャ３０８と通信して、タイプの安全性の検査に合格しなかったにも関わらず、そのコードアセンブリに実行の許可が交付されるかどうかの照会を行うことができる。
【００５２】
図４は、本発明の実施形態における証拠ベースのセキュリティを管理するためのポリシーマネージャのモジュールを描いている。図４に関連して説明した実行可能なモジュールがコンピュータシステム上で実行可能なソフトウェアモジュールとして実装されていることが可能である。あるいは、ハードウェアで、またはハードウェアとソフトウェアの組み合わせで実装される実行可能なモジュールも本発明の範囲の中で企図される。さらに、本発明の範囲を逸脱することなく、本明細書で開示するモジュールをマージしてより少ない数のモジュールにするか、または分割して追加のモジュールにすることができる。
【００５３】
ポリシーマネージャ４００が、セキュリティポリシー指定４０２および証拠セット４０４を受け取るように結合される。セキュリティポリシー指定４０２は、１つ以上のコードグループの定義を指定する。一実施形態では、コードグループは１つ以上のコードグループ集合に構成される。あるいは、コードグループを１つ以上のコードグループ階層に構成してもよい。また、セキュリティポリシー指定は、１つ以上のポリシーレベルも定義することができる。証拠セット４０４は、コンピュータシステムによって受け取られたコードアセンブリに関連する信頼特性を定義する。
【００５４】
本発明の一実施形態では、パーサモジュール４０６がセキュリティポリシー指定４０２を受け取り、１つ以上の名前付きコードグループの定義を抽出する。各コードグループは、メンバーシップ基準、子定義（コードグループの０または１つ以上の子コードグループを指定する）、およびコードグループ許可セットに関連している。メンバーシップ基準は、所与のコードグループに関するメンバーシップの条件を指定し、証拠セットは、対応するコードアセンブリがそのコードグループのメンバーであるとみなされるためには、その条件を満たさなければならない。子コードグループ定義は、所与のコードグループの子を指定する。コードアセンブリが第１のコードグループ（すなわち、親コードグループ）におけるメンバーシップを証明した場合、そのコードアセンブリは、その親コードグループの子コードグループにおけるメンバーに入れるように考慮される。コードグループ許可セットは、コードグループに割り当てることができる許可の集合を表す。コードアセンブリがコードグループのメンバーであると判定された場合、関連する許可セットの許可がコードアセンブリに交付されることが可能であり、コードアセンブリは、ポリシーマネージャ内部でその他の動作を受ける。
【００５５】
その他のコードグループ実施形態には、別のデータ構成が含まれることが可能である。例えば、一実施形態では、コードグループ集合はそれぞれがメンバーシップ基準および許可セットを含み、前述の子コードグループ定義を省略するコードグループの１次元リストで表される。この実施形態では、１次元リストは、順序付けられていても、順序付けられていなくてもよい。さらに、本発明の範囲内でその他のデータ構成も企図される。
【００５６】
本発明の例としての実施形態では、許可セットに命名を行い、セキュリティポリシー指定４０２の中で識別を可能にすることができる。同じ名前の付けられた許可セットに複数のコードグループを割り当てることができる。このため、名前付き許可セットに変更（例えば、個々の許可の挿入または削除）が行われた場合、その変更は、その名前付き許可セットに関連するコードグループのすべてに影響を及ぼす。例えば、異なるコードグループのメンバーであるいくつかのエクストラネットビジネスパートナーのＷｅｂサイトに同じ許可を交付するため、単一の名前の付けられた許可セットを定義し、そのいくつかのコードグループに割り当てることができる。
【００５７】
本発明の実施形態では、３つのタイプの名前付き許可セットがサポートされる。すなわち、（１）標準の許可セット−このセットは、事前定義され、変更することができない、（２）事前定義された許可セット−このセットは、管理者が変更することができる、および（３）カスタムの許可セット−このセットは、許可セットの名前が標準の許可セットの名前または事前定義された許可セットの名前とコンフリクトしない限り、ユーザが定義することができる。一実施形態では、標準の許可セットは、すべてのポリシーレベルで利用可能であり、個別のどのポリシーレベルでも再定義することができない（汎用範囲）。この実施形態では、事前定義された許可セットおよびカスタムの許可セットは任意の所与のポリシーレベル中で定義されて参照され、その他のポリシーレベルからは参照することができない（ポリシーレベル範囲）。ただし、本発明の別の実施形態では、どの許可セットの範囲も所与のポリシーレベルを超えて広がることが可能であることを理解されたい。
【００５８】
次の表１は、本発明の実施形態で利用可能な標準の許可セットを説明している。インターネットセットおよびローカルイントラネットセットなどのいくつかの標準の許可セットは、事前定義されているが、ユーザまたは管理者によって変更されることが可能である。確認スキップなどのその他の許可セットは、本発明の実施形態では変更することができない。また、本発明の範囲内で別の名前付き許可セットも企図され、表１の中で説明する名前付き許可セットは、本発明を逸脱することなく変更することができる。
【００５９】
【表２】

【００６０】
本発明の実施形態における例としての許可として、本明細書で多数の許可について述べたが、本発明の範囲内で企図される可能な許可のリストは、これらの例としての許可に限定されない。例えば、確認が失敗したのにも関わらず、コードアセンブリが実行されるのを許す許可を交付することもできる。あるコードアセンブリの中のクラスが、別のコードアセンブリ中のクラスから継承を行うことを可能にする別の許可（例えば、サブクラスに対する権利）を交付することもできる。
【００６１】
所与のコードグループに関連するコードグループ許可セットが、コードグループに関連する許可を指定することができる。あるいは、所与のコードグループに関連するコードグループ許可セットが、コードグループおよびすべての親元コードグループに関連する許可を指定することができる。この柔軟性により、セキュリティポリシー指定の中で様々なセキュリティ構成（例えば、ポリシーレベル、許可セット、メンバーシップ基準等）を定義することが可能になる。以下で述べる通り、ポリシーマネージャは、そのような様々なセキュリティ構成に対応するように開発することができる。
【００６２】
一実施形態では、セキュリティポリシー指定４０２は、それぞれが１つ以上のコードグループを有する複数のポリシーレベルも指定することができる。コードグループは、１つ以上のコードグループ集合に構成することができる。ポリシーレベルにより、管理者が、例えば、異なるマシン、異なるユーザ、異なるアプリケーション、異なる期間、異なるユーザグループ等に関して異なるセキュリティポリシーを定義することが可能になる。メンバーシップエバリュエータ４１０は、所与のポリシーレベルに関するポリシーレベル許可セットを生成する際、そのポリシーレベルに関連するコードグループ全部を横断（ｔｒａｖｅｒｓｅ）する。したがって、ポリシーマネージャ４００は個々のポリシーレベルに関連する許可セットを生成することができる。その後、複数のポリシーレベルからの許可セットを処理して（例えば、マージまたは選択して）、結果の許可交付セット４１４を生成することができる。
【００６３】
図示する実施形態では、コードグループ集合生成器モジュール４０８がパーサモジュール４０６から構文解析された定義を受け取り、コンピュータシステムのメモリの中で１つ以上のコードグループ集合を生成する。メンバーシップエバリュエータモジュール４１０は証拠セット４０４を受け取り、対応するコードアセンブリに関係する信頼特性（ｔｒｕｓｔ ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ）を抽出する。メンバーシップエバリュエータモジュール４１０はコードグループ全体を横断して、コードアセンブリが１つ以上のコードグループのメンバーであるかどうかを判定する。許可セット生成器モジュール４１２が、メンバーシップエバリュエータモジュール４１０からメンバーシップ判定を受け取り、コードアセンブリがメンバーであると判定されたコードグループに関連するコードグループ許可セットの論理上の組み合わせに基づき、中間許可セット４２２を生成する。許可／要求フィルタモジュール４２４が中間許可セット４２２をフィルタして、結果の許可交付セット４１４を生成する。
【００６４】
図５は、本発明の実施形態においてポリシーマネージャが動作する例としてのポリシーレベルを描いている。セキュリティポリシー指定５００がポリシーマネージャ５０２上で処理されて、１つ以上のセキュリティポリシーレベル５０６、５０８、および５１０が生成される（この処理は、ポリシーレベルのそれぞれをポイントする破線で表される）。本発明の実施形態では、セキュリティポリシー指定５００はＸＭＬ（エクステンシブルマークアップ言語）ファイル内に書かれる。ただし、別の実施形態では、ＳＧＭＬ（標準一般化マークアップ言語）、ＨＴＭＬ（ハイパーテキストマークアップ言語）、ＲＤＦ（リソース記述フレームワーク）、ビジュアルベーシック、およびその他の標準およびカスタマイズされたデータフォーマットおよびコードフォーマットを限定するものとしてではなく含む、その他のデータフォーマットも使用することができる。
【００６５】
本発明の実施形態では、セキュリティポリシー指定５００は、各ポリシーレベルがコードグループから構成されたセキュリティポリシーの永続的な表現（例えば、ポリシーレベルの順序付けされた集合および／またはコードグループ集合）である。より下位のポリシーレベルは、一般に、より高位のポリシーレベルより制限的なポリシー制限を指定する。セキュリティポリシー指定５００は、通常、適切な許可を有するシステム管理者、ユーザ、またはアプリケーションセットアッププログラムによって生成される。例としてのポリシーレベルには、限定するものとしてではなく、企業ポリシーレベル、マシンポリシーレベル、ユーザポリシーレベル、およびアプリケーションポリシーレベルが含まれることが可能である。
【００６６】
本発明の一実施形態では、最高レベルのポリシーレベルは、任意の所与の企業内部のすべてのシステムに適用されるセキュリティポリシーを定義することが可能な企業ポリシーレベルである。より低いポリシーレベルは、所与のシステム上のすべてのユーザに適用されるセキュリティポリシーを定義することが可能なマシンポリシーレベルである。ユーザポリシーレベルは、ユーザがどの個別のシステムにログインしているかに関わらず、所与のユーザに適用されるセキュリティポリシーを定義することができる。アプリケーションポリシーレベルは、アプリケーションを実行するユーザまたはシステムに関わらず、所与のアプリケーションに適用されるセキュリティポリシーを定義することができる。本発明の範囲内で、さらなるポリシーレベルおよびポリシーレベル順序も企図される。
【００６７】
また、セキュリティポリシー指定５００は、コードグループ集合（例えば、コードグループレベルの集合）を使用してセキュリティを管理することもでき、コードグループ集合はメンバーシップ条件によって定義され、許可セットおよび特別の属性を含む。セキュリティポリシー指定５００は、関連する許可のセットを有するコードグループの宣言から成る。所与のコードグループのメンバーであるコードアセンブリには、そのコードグループに関連する許可セットからの許可が交付されることが可能である。コードグループメンバーシップは、デジタル署名、コードアセンブリの出所（ｏｒｉｇｉｎ）などのコードアセンブリに関連する証拠セット５０４を使用してポリシーマネージャ５０２によって判定される。管理者は、新しいコードグループに属するコードアセンブリに追加の許可を交付するため、コードグループ集合にコードグループを追加することができる。
【００６８】
本発明の実施形態では、コードグループに「排他」プロパティフラグを属性として与えることができ、このフラグは、その特定のコードグループに関連する許可だけが、メンバーのコードアセンブリに適用されるべきことを指定する。その他のメンバーコードグループからの許可セットは無視される（すなわち、マージされない）。
【００６９】
本発明の実施形態では、コードグループは、「オール」コードアセンブリに対応するルートノードを有するコードグループ階層中で定義される。このルートノードは、子ノードを有する親コードグループを表し、子ノードのそれぞれも子ノードを有することが可能であり、以下同様、コードグループ階層が形成される。限定するものとしてではなく、コードグループの順序付けされた、または順序付けされていないリストを含め、別のコードグループ集合も本発明の範囲内で企図される。ポリシーマネージャ５０２が、あるコードアセンブリが親コードグループのメンバーであると判定した場合には、そのコードアセンブリは親コードグループの子に照らして試験されて、子としてのメンバーシップが判定される。例としてのコードグループタイプおよびメンバーシップ基準を次の表２で説明しているが、本発明の範囲内でその他のコードグループタイプも企図される。さらに、コードグループタイプをプロパティに関連付けることができる。例えば、コードグループタイプ「ソフトウェア発行元」を「発行元：マイクロソフト（登録商標）」のように、特定の発行元「マイクロソフト（登録商標）」に関連付けることができる。
【００７０】
【表３】

【００７１】
さらに、セキュリティポリシー指定５００は、複数のポリシーレベルを定義することができる。図示する実施形態では、各ポリシーレベル（例えば、企業レベル５０６、マシンレベル５０８、およびユーザレベル５１０）が個別のコードグループ集合を有する。前述した通り、本発明の範囲内で複数のポリシーレベルが割り振られる（例えば、ルートノードの子に関連するサブツリー１つあたり１つのポリシー）１つ以上のコードグループ集合などの、その他のポリシーレベル構成を使用してもよい。
【００７２】
図示する実施形態では、各ポリシーレベルからポリシーレベル許可セット（例えば、企業レベル許可セット５１２、マシンレベル許可セット５１４、またはユーザレベル許可セット５１６）が生成される。ポリシーレベル許可セットマージャ５１８が、ポリシーレベル許可セット５１２、５１４、および５１６をマージし、あるいは別の方法で処理して中間許可セット５２６を生成する。
【００７３】
許可／要求フィルタ５２４は、許可要求５２２を入力し、フィルタアルゴリズムを中間許可セット５２６に適用して、適切な場合、結果の許可交付セット５２０を生成する。
【００７４】
例としての実施形態では、許可／要求フィルタ５２４は、図６との組み合わせで説明する通り、フィルタアルゴリズムを適用して許可交付セット５２０を生成する。
１）ＭａｘＲＳ ＝（ＭｉｎＲＳ∪ＯｐｔＲＳ） ［動作６００］
２）Ｉｆ（ＭｉｎＲＳがＩｎｔＰＳのサブセットでない） ［動作６０２］、ｔｈｅｎ ポリシーマネージャ５０２が、ポリシー例外を発生させてコードアセンブリのロードおよび／または実行を防止する ［動作６０４］
３）Ｉｆ（ＭｉｎＲＳがＩｎｔＰＳのサブセットである） ［動作６０２］、ｔｈｅｎ ＰＧＳ ＝（ＭａｘＲＳ∩ＩｎｔＰＳ）− ＲｅｆｕｓｅＲＳ ［動作６０６］
４）Ｉｆ（ＰＧＳが実行許可を含む） ［動作６０８］、ｔｈｅｎ コードアセンブリが図３のローダ３０６によってロードされることが可能であり［動作６１０］、また、ＰＧＳがコードアセンブリに関連して図３のランタイムスタック３１８にロードされることが可能である［動作６１２］
５）Ｉｆ（ＰＧＳが実行許可を含まない） ［動作６０８］、ｔｈｅｎ ポリシーマネージャ５０２がポリシー例外を発生させてコードアセンブリのロードおよび／または実行を防止する ［動作６１４］
ただし、ＰＧＳは許可交付セット５２０を表し、ＩｎｔＰＳは中間許可セット５２６を表し、ＭａｘＲＳは最大限の要求セットを表し、ＭｉｎＲＳは最低限の許可要求を表し、ＯｐｔＲＳはオプションの許可要求を表し、また、ＲｅｆｕｓｅＲＳは拒否許可要求を表す。ＭｉｎＲＳ、ＯｐｔＲＳ、およびＲｅｆｕｓｅＲＳは、許可要求５２２の要素として受け取られる。
【００７５】
本発明の実施形態では、ＭｉｎＲＳ、ＯｐｔＲＳ、またはＲｅｆｕｓｅＲＳが指定されない場合、これらには、デフォルトの値が割り当てられる。ＭｉｎＲＳおよびＲｅｆｕｓｅＲＳに関して、デフォルトの値は、空集合である。ＯｐｔＲＳに関して、デフォルトの値は、全集合である。例えば、ＭｉｎＲＳおよびＯｐｔＲＳが指定されない場合、ＰＧＳは、ＩｎｔＰＳ−ＲｅｆｕｓｅＲＳに等しい。
【００７６】
論理集合演算６０６を使用して中間許可セットのサブセットを生成して、必要とされる許可だけが許可交付セットの中に含められるようにする。つまり、中間許可セットは、コードアセンブリによって必要とされるか、または要求される許可セットより、はるかに広い可能性がある。したがって、不必要な、または要求されていない許可を結果の許可交付セットから除外することができる。
【００７７】
以上に開示したアルゴリズムは、許可要求を使用して中間許可セットをフィルタするための例としてのアルゴリズムにすぎないことを理解されたい。本発明の範囲内で別のアルゴリズムも企図され、特に、別の許可要求の組み合わせが使用される場合はそうである（例えば、追加のタイプの許可要求セット）。
【００７８】
図７は、本発明の実施形態を実施するために役立つ例としてのシステムを示している。本発明の実施形態のための例としてのコンピュータシステムには、プロセッサユニット７０２と、システムメモリ７０４と、システムメモリ７０４を含む様々なシステム構成要素をプロセッサユニット７００に結合するシステムバス７０６とを含む従来のコンピュータシステム７００の形態の汎用コンピュータデバイスが含まれる。システムバス７０６は、様々なバスアーキテクチャの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造の任意のものであることが可能である。システムメモリは、読取り専用メモリ（ＲＯＭ）７０８およびランダムアクセスメモリ（ＲＡＭ）７１０を含む。コンピュータシステム７００内部の要素間における情報の転送を助ける基本ルーチンを含む基本入力／出力システム７１２（ＢＩＯＳ）がＲＯＭ７０８の中に記憶されている。
【００７９】
コンピュータシステム７００は、ハードディスクに対して読取りおよび書込みを行うためのハードディスクドライブ７１２と、取外し可能な磁気ディスク７１６に対して読取りおよび書込みを行うための磁気ディスクドライブ７１４と、ＣＤ−ＲＯＭ、ＤＶＤ、またはその他の光媒体などの取外し可能な光ディスク７１９に対して読取りおよび書込みを行うための光ディスクドライブ７１８とをさらに含む。ハードディスクドライブ７１２、磁気ディスクドライブ７１４、および光ディスクドライブ７１８は、それぞれ、ハードディスクドライブインターフェース７２０、磁気ディスクドライブインターフェース７２２、および光ディスクドライブインターフェース７２４でシステムバス７０６に接続される。以上のドライブおよび関連するコンピュータ可読媒体により、コンピュータシステム７００のためのコンピュータ可読命令、データ構造、プログラム、およびその他のデータの不揮発性ストレージが提供される。
【００８０】
本明細書で説明する例としての環境は、ハードディスク、取外し可能な磁気ディスク７１６、および取外し可能な光ディスク７１９を使用するが、データを記憶することができるその他のタイプのコンピュータ可読媒体も、例としてのシステムで使用することができる。例としての動作環境で使用することができるその他のタイプのコンピュータ可読媒体の例には、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、および読取り専用メモリ（ＲＯＭ）が含まれる。
【００８１】
オペレーティングシステム７２６、１つ以上のアプリケーションプログラム７２８、その他のプログラムモジュール７３０、およびプログラムデータ７３２を含め、いくつかのプログラムモジュールが、ハードディスク、磁気ディスク７１６、光ディスク７１９、ＲＯＭ７０８、またはＲＡＭ７１０の上に記憶されていることが可能である。ユーザは、キーボード７３４、およびマウス７３６またはその他のポインティングデバイスなどの入力デバイスを介してコンピュータシステム７００にコマンドおよび情報を入力することができる。その他の入力デバイスの例には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、およびスキャナが含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、しばしば、システムバス７０６に結合されたシリアルポートインターフェース７４０を介して処理装置７０２に接続される。それでも、以上の入力デバイスは、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースで接続されてもよい。また、モニタ７４２または他のタイプの表示デバイスも、ビデオアダプタ７４４などのインターフェースを介してシステムバス７０６に接続される。モニタ７４２に加え、コンピュータシステムは、通常、スピーカおよびプリンタなどのその他の周辺出力デバイス（図示せず）も含む。
【００８２】
コンピュータシステム７００は、遠隔コンピュータ７４６のような１つ以上の遠隔コンピュータに対する論理接続を使用するネットワーク化された環境で動作することができる。遠隔コンピュータ７４６は、コンピュータシステム、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードであることが可能であり、通常、コンピュータシステム７００に関連して前述した要素の多く、またはすべてを含む。ネットワーク接続は、ローカルエリアネットワーク（ＬＡＮ）７４８およびワイドエリアネットワーク（ＷＡＮ）７５０を含む。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。
【００８３】
ＬＡＮネットワーキング環境で使用される場合、コンピュータシステム７００は、ネットワークインターフェースまたはネットワークアダプタ７５２を介してローカルネットワーク７４８に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータシステム７００は、通常、インターネットなどのワイドエリアネットワーク７５０を介して通信を確立するためのモデム７５４またはその他の手段を含む。内部または外部にあることが可能なモデム７５４は、シリアルポートインターフェース７４０を介してシステムバス７０６に接続される。ネットワーク化された環境では、コンピュータシステム７００に関連して描いたプログラムモジュール、またはプログラムモジュールの部分を遠隔メモリ記憶デバイスの中に記憶することができる。図示したネットワーク接続は例としてのものであり、コンピュータ間で通信リンクを確立するその他の手段も使用できることが理解されよう。
【００８４】
図示する実施形態では、セキュリティポリシー指定が、例えばハードディスクドライブ７１２上のファイルからメモリ７０４に読み込まれることが可能である。ＣＰＵ７０２が仮想マシンを実装し、リソースロケーションから受け取られたコードアセンブリに関連付けられた分類された許可要求を使用して許可交付セットを生成するコンピュータプロセスのためのメモリ常駐命令コードを実行する。さらに、ＣＰＵ７０２は、特許請求の範囲で記載するポリシーマネージャを実装するソフトウェア構成要素も実行する。
【００８５】
図８は、本発明の実施形態におけるリソースロケーションから受け取られたコードアセンブリに関連する分類された許可要求を使用して許可交付セットを生成するための動作を示す流れ図である。定義する動作８００が、セキュリティポリシー指定に従ってコードグループ集合を定義する。コードグループ集合は１つ以上のコードグループを含み、またコードグループ階層として構成することができる。受け取る動作８０２がコードアセンブリに関連する証拠を受け取る。メンバーシップ動作８０４がコードグループとの関係でコードアセンブリのメンバーシップを評価する。一般に、この評価は各コードグループに関連するメンバーシップ基準に基づく。
【００８６】
生成する動作８０６が、メンバーシップ動作８０４によって行われた１つ以上のメンバーシップ判定に基づいて許可セットを生成する。例えば、コードグループ集合がコードグループ階層として構成される一実施形態では、許可セットは、コードアセンブリがメンバーであると判定された親コードグループおよび子コードグループに関連する許可を組み合わせることによって動的に生成される。組み合わせられた許可は、生成する動作８０６から許可セットとして出力され、この許可セットが許可／要求フィルタモジュールによって受け取られる。
【００８７】
受け取る動作８０８が、コードアセンブリに関連する許可要求を受け取る。この許可要求は、コードアセンブリの一部として受け取ること、あるいはローカルのリソースロケーション（例えば、コンピュータシステム内部で、接続された周辺機器または記憶媒体から、またはローカルのネットワーク記憶場所から）、または遠隔のリソースロケーション（例えば、インターネットを介して）などの別のソースから受け取る（または取得する）ことが可能である。
【００８８】
フィルタする動作（ｆｉｌｔｅｒｉｎｇ ｏｐｅｒａｔｉｏｎ）８１０が、許可要求セットに基づいて許可セットをフィルタして、コードアセンブリの実行を制御する。フィルタする動作８１０が、最低限の要求セットがコードアセンブリに関連して提供される場合、その要求セットが許可セットのサブセットでないと判定した場合、ポリシーマネージャがコードアセンブリのロードまたは実行を防止することができる。同様に、実行許可が許可セットに含まれない場合、フィルタする動作８１０はコードアセンブリのロードまたは動作を防止することができる。
【００８９】
また、フィルタする動作８１０は、最低限の要求セットまたはオプションの要求セットがコードアセンブリに関連して提供される場合、コードアセンブリによって要求されていない許可を交付するのを回避するために許可交付セットを生成するとき、その要求セットに含まれない許可を除外することもできる。さらに、拒否要求セットがコードアセンブリに関連して提供される場合、その要求セットに含まれる許可も許可交付セットから除外することができる。
【００９０】
本明細書で説明する本発明の実施形態は、１つ以上のコンピュータシステムにおける論理ステップとして実施される。本発明の論理動作は、（１）１つ以上のコンピュータシステムにおいて実行される一続きのプロセッサによって実施されるステップとして、また（２）１つ以上のコンピュータシステム内部の相互に接続されたマシンモジュールとして実施される。実施形態は、本発明を実施するコンピュータシステムのパフォーマンス要件に応じた選択の問題である。したがって、本明細書で説明する本発明の実施形態を構成する論理動作は、動作、ステップ、オブジェクト、またはモジュールと様々に呼ばれる。
【００９１】
以上の明細、例、およびデータにより、本発明の例としての実施形態の構造および使用法の完全な説明が提供される。本発明の多くの実施形態を本発明の趣旨および範囲を逸脱することなく実施することができるので、本発明は、頭記の特許請求の範囲に存する。
【図面の簡単な説明】
【図１】
本発明の実施形態における証拠ベースのセキュリティポリシーマネージャを描いた図である。
【図２】
本発明の実施形態におけるランタイム呼出しスタックを示す図である。
【図３】
本発明の実施形態における証拠ベースのセキュリティを管理するためのコンピュータシステムを描いた図である。
【図４】
本発明の実施形態における証拠ベースのセキュリティを管理するためのポリシーマネージャモジュールを描いた図である。
【図５】
本発明の実施形態におけるポリシーマネージャが動作する例としてのポリシーレベルを描いた図である。
【図６】
本発明の実施形態で使用されるフィルタリングを示す流れ図である。
【図７】
本発明の実施形態を実施するのに役立つ例としてのシステムを示す図である。
【図８】
本発明の実施形態における許可セットを処理するための動作（ｏｐｅｒａｔｉｏｎｓ）を示す流れ図である。[0001]
This application has been filed as a PCT application by Microsoft® Corporation (MICROSOFT® CORPORATION), United States of America, designating all countries other than the United States.
[0002]
(Technical field)
The present invention relates generally to computer security, and more particularly, to filtering permission sets using permission requests associated with code assemblies.
[0003]
(Background of the Invention)
Security risks, such as allowing unauthorized access to a user's system, are associated with many online activities. Therefore, security mechanisms have been developed to protect the user's system. For example, a user can download an on-demand application from the Internet and execute the application from within a browser. To prevent unauthorized access to a user's system resources (eg, directories on the user's hard disk), the user's system is protected by "sandbox" security implemented within a browser environment. Sandbox security involves a limited secure area of computer memory where an application can be executed to prevent the application from accessing system resources residing outside the secure area.
[0004]
However, in some situations, the user may wish to allow the downloaded application to have controlled access to certain resources within the user's system. For example, a user may generate a document using an on-demand word processing application and then desire to save the document to a directory in the user's system.
[0005]
Existing approaches to providing such applications with secure, controlled access to the user's system are too cumbersome and inflexible. On the one hand, for example, a security policy in which a given application is associated with a permission set is defined inside the policy database. This security policy, in combination with origin information, signature information, and access constraints, helps define a "trusted" relationship between the application and the user's system.
[0006]
Consider the following example.
[0007]
[Table 1]

[0008]
In this example, if an applet from the source location “www.BobsWidgets.com” is signed with a key corresponding to another key included in BobsCertificate, a certain file access permission is issued to this applet. Applets are traditionally programs that are designed to be executed from within a browser, rather than directly from within an operating system. This applet is given permission to read files from the "/ tmp" directory on the host system and create and write files in the "/ tmp / bwdir" directory. Another common permission qualifier is "execute" permission. Other security policy designations, for example, allow broad permissions to access files at any system location, regardless of the source of the application or whether the application is signed or unsigned It is.
[0009]
In such an approach, security policies are particularly static and remain fixed for long periods of time. In essence, as on-demand application processing over the Internet becomes more common, static security policies are too restrictive. In addition, less frequent security policy changes that are actually made (usually made by the system administrator) can introduce security weaknesses or gaps, or gain access to previously authorized applications. Denying may prevent authorized applications from running. Because of this, existing security architectures cannot dynamically and flexibly determine whether an application (or a given code assembly of an application) can delegate a certain amount of access to a user's system.
[0010]
Further, in existing security frameworks, the allocation of permissions is determined by security policies defined in the user's system, and in some cases by queries to the user while the application is running or loading. Thus, components of an on-demand application generally do not affect which permissions are allocated according to security policies. For example, a component from an authorized location may be granted extensive access to a protected area of a computer system, and that component does not require or even desire such access Even if there is a possibility, it may be issued. For liability reasons, a component may want more limited access. Further, a component may not be able to perform without a minimum set of permissions. With existing security frameworks, during code assembly execution, an insufficient grant set is detected only when the requested operation fails due to lack of permissions, at which point execution time is wasted. And error recovery may be more complex.
[0011]
(Summary of the Invention)
According to the present invention, these and other problems are solved by an evidence-based policy manager that generates a grant set for code assemblies received from a resource location. The permission grant set can be affected (eg, filtered) by a permission request received in connection with the code assembly. The authorization request may define the characteristics of the authorization needs of the code assembly. For example, a permission request can include a minimum set of permissions that specify the permissions required by the code assembly to operate properly with at least the basic functionality. The permission request may also include an optional request set that specifies the permissions required by the code assembly to provide an alternate level of functionality. Further, the permission request may include a set of deny requests specifying permissions that should not be issued to the code assembly.
[0012]
In an embodiment of the invention, a method is provided for processing a permission set associated with a code assembly received from a resource location to control execution of the code assembly. The permission set includes at least one permission associated with the code assembly. A permission request set is received in association with the code assembly. The permission set is filtered based on the permission request set to control execution of the code assembly.
[0013]
In another embodiment of the invention, the method further includes generating a permission set based on the membership of the code assembly in one or more code groups. A code group set is defined based on the security policy specification. A code group set includes one or more code groups. Evidence is received in connection with the code assembly. Code assembly membership in one or more code groups is evaluated based on the evidence.
[0014]
In yet another embodiment of the present invention, there is provided a policy manager module for processing a permission set associated with a code assembly received from a resource location to control execution of the code assembly, the module comprising: And a filter that receives the permission set and permission request set associated with. The filter also controls execution of the code assembly by filtering the permission set based on the permission request set.
[0015]
In another embodiment of the present invention, the article of manufacture is provided as computer program products. One embodiment of a computer program is readable by a computer system for processing a set of permissions associated with a code assembly received from a resource location to execute a computer process for controlling execution of the code assembly. A computer program storage medium for encoding a computer program is provided. Another embodiment of a computer program is embodied on a carrier by a computer system and encodes a computer program for processing a permission set associated with a code assembly received from a resource location and controlling execution of the code assembly. It can be provided in a computer data signal.
[0016]
In one embodiment, the computer program encodes a computer program for executing a computer process on a computer system that defines a set of code groups based on a security policy specification. A code group set includes one or more code groups. Evidence is received in connection with the code assembly. Code assembly membership in one or more code groups is evaluated based on the evidence. A permission set is generated based on code assembly membership in the one or more code groups. The permission set includes at least one permission associated with the code assembly. A logical set operation is performed on the permission set and the permission request set to generate a permission grant set.
[0017]
A significant benefit of embodiments of the present invention is that permissions issued to the code assembly by the policy manager are filtered according to permission requests. This affects the permissions that code assemblies receive in concert with what the applicable security policy allows. Permissions are used to control the execution of code assemblies within a computer system. It is advantageous to only issue the permissions actually required by the code assembly. For example, security policies can grant broad permissions to trusted code assemblies. However, if the code assembly does not require a given permission, inadvertent access to a protected area of the computer system as caused by errors in the code assembly can be avoided. Further, the code assembly denies a given set of permissions to avoid being exposed to potential liability for accessing (and possibly destroying) a protected area of the computer system. be able to.
[0018]
These and various other features, as well as other advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings.
[0019]
(Detailed description of the invention)
Embodiments of the present invention provide an evidence-based policy manager that generates an authorization grant set for code assemblies received from a resource location. Generally, the code assembly is a. EXE file, or. It is a unit of packaged code such as a DLL file. The policy manager can execute on a computer system (eg, a Web client or a networked workstation) in combination with a validation module and a class loader of the runtime environment. However, the policy manager can run outside of the runtime environment. The permission grant set generated for the code assembly is applied in the runtime call stack to help the system determine whether a given system operation by the code assembly is permitted. The policy manager can process authorization requests received in connection with the code assembly. Further, both code assembly and evidence can be received from a local source (eg, from within a local machine), a local network or peripheral, or a remote resource location over a network (eg, the Internet).
[0020]
In embodiments of the present invention, a permission request is used to filter permissions initially provided by the policy manager based on security policy specifications and evidence received in connection with the code assembly. This allows the code assembly to affect the resulting permission grant set associated with the code assembly and avoid receiving excessive or unnecessary permissions.
[0021]
FIG. 1 depicts an evidence-based security policy manager 104 in an embodiment of the present invention. A resource location 100, such as a server, is accessible by a computer system 102 (eg, a web client or web server) via a network (not shown). The resource location is generally indicated by a URI (Uniform Resource Identifier), which is a generic term for all types of names and addresses that refer to objects on the World Wide Web. A URL (uniform resource locator) is a type of URI. Example resources can include, but are not limited to, documents, images, audio data, applications, routines, and other data and code data stores accessible over a network. It should be understood that the resource location can be local to computer system 102 or remote to computer system 102 (eg, coupled to the Internet).
[0022]
One type of resource relevant to embodiments of the present invention is code assembly. A code assembly can consist of, for example, applet code, application code, class code, routine code, and data. The code and data included in the code assembly can be in the form of bytecode, intermediate code, machine code, and data components (such as classes, images, audio clips and video clips). Further, the code assembly can be packaged in an archive file containing one or more classes downloaded from a resource location. In one embodiment of the present invention, classes of applications can be combined into modules (the output of a link process), and one or more modules can be combined into a code assembly.
[0023]
FIG. 1 is depicted with respect to a downloaded application running on computer system 102. Alternative embodiments may include downloaded applets, ACTIVEX controls, and other routines and objects. An example downloaded application consists of objects defined in one or more local or remote code assemblies. The local code assembly is stored within computer system 102 and loaded into memory when needed. The remote code assembly is downloaded from a resource location, such as resource location 100.
[0024]
Computer system 102 initiates a runtime environment to execute downloaded applications and manage security of system 102. The runtime environment of the computer system 102 can be initialized by a "trusted host" such as an operating system shell, browser, SQL server, or other code external to the runtime environment. The host also begins executing the application by downloading the various code assemblies 106 that make up the application to the system 102 and passing the code assembly 106 to the virtual machine 110 for execution.
[0025]
Virtual machines provide a self-contained operating environment that performs many of the functions of a separate computer. For example, applications can run in a virtual machine without having direct access to the host operating system. This design has at least two advantages.
-System independence: The application runs similarly on any virtual machine that supports the programming language in which the application is written, regardless of the underlying hardware and software of the system. For example, the same application (ie, the same programming code) can be executed in a virtual machine on a different computer system having a different type of microprocessor and a different type of operating system.
Security: applications running in virtual machines generally access protected system resources (ie, operating system, file system, protected area of memory, connected networks or connected peripherals). Is prevented. However, it should be understood that embodiments of the present invention can evaluate evidence and security policies to determine whether to allow an application to access protected system resources. If permission is granted for a given operation, the application is considered "trusted" for that operation. The permission request received in connection with the code assembly can be used to filter the resulting permission grant set used to determine what actions the code assembly can perform.
[0026]
An application component (e.g., downloaded code assembly 106) is received by the system 102 and the validation module 112 checks that the downloaded code in the code assembly 106 is properly formatted and secure the code language or virtual machine 110. Make sure you do not violate the constraints. Other checks can also be made, such as the absence of pointer addressing, the inability of the internal stack to overflow or underflow, and that code instructions have correctly classified parameters. . Next, the code assembly is passed to the class loader 113, which ensures that the application does not replace system-level components in the runtime environment (ie, the class loader is provided by the host). Code assembly is executed when requested, thereby eliminating name conflicts with the downloaded code assembly). Thereafter, the class loader 113 loads the code assembly 106 onto the runtime call stack 114 in response to a request from the virtual machine 110.
[0027]
For example, the virtual machine executes a first code assembly (eg, main code assembly 202 of FIG. 2) that calls a routine provided by a second code assembly (eg, parser code assembly of FIG. 2). A class loader 113 receives the virtual machine's request for a second code assembly, loads the second code assembly into the runtime call stack 114 so that the first code assembly can call the required routines. To
[0028]
Evidence 108 associated with each of the downloaded code assemblies 106 is entered into the policy manager 104 to ensure that unauthorized access to the protected area is prevented. The policy manager 104 determines a permission grant set associated with each code assembly (see permission grant set 414 in FIG. 4). A security policy specification 116 is also entered into the policy manager 104 to help calculate the appropriate grant. In addition, an authorization request 120 is received in association with the downloaded code assembly 106 to specify characteristics of the authorization needs of each downloaded code assembly 106. In one embodiment, the authorization request is recorded in a binary serialized format within the code assembly itself, and is thus downloaded with the code assembly in a single network communication. Alternatively, the authorization request may have been recorded elsewhere in the resource location accessible by the policy manager 104 in another network communication. Further, while a binary serialized format has been specified as an example format for recording authorization requests, other data formats (eg, XML) are contemplated within the scope of the present invention.
[0029]
Further, one data format, such as XML, can be used by the developer to initially specify the authorization request. Thus, the XML specification permission request can be encoded into another data format, such as a binary serialized format, for incorporation into a code assembly. In addition, some compilers allow developers to specify permission requests using declarative security annotations in the source code of a code assembly. The compiler can then encode the annotation into a permission request embedded in the code assembly.
[0030]
In embodiments of the present invention, permission requests 120 are "typed" so that each type of permission request can be applied to filter permissions differently. Based on these inputs, the policy manager 104 calculates the appropriate grant for each code assembly and passes the resulting grant grant set to the runtime call stack 114.
[0031]
To this end, each code assembly in the runtime call stack 114 is associated with a corresponding granting set (eg, the granting sets 208, 210, and 212 of FIG. 2). A grant set is received from the policy manager and defines various permissions calculated for the corresponding code assembly. The permissions associated with each code assembly are all referred to as "evidence" 108, the relative source of the code assembly (e.g., local or remote), the specific source of the code assembly (e.g., a specific URL), or other May vary significantly based on the reliability characteristics of In an embodiment of the present invention, a trust grant is used to determine a grant set for a given code assembly. Further, security policy specification 116 allows multiple policy levels to be defined within the security framework for a given company, machine, user, application, etc., where the trust characteristics of a given code assembly are evaluated. .
[0032]
FIG. 2 illustrates a runtime call stack 200 that includes individual code assemblies stacked in the order in which they were called. Individual code assemblies can be downloaded from a remote resource location or retrieved locally from the computer system 102 of FIG. Individual code assemblies are loaded into the runtime call stack 114 by a class loader 113 for access and execution by the virtual machine 110 of FIG.
[0033]
For example, an object of the main application class in the code assembly 202 is first loaded into the illustrated runtime call stack 200 by a class loader. When the virtual machine executes its main class, the main class creates a parser object from the code assembly 204 and calls methods in the parser object to parse data files in a protected area of the computer system. Accordingly, the class loader loads the parser code of the code assembly 204 into the runtime call stack 200. Thereafter, the parser object creates a file access object from the code assembly 206 and calls a method in the file access object to perform a read operation on the protected file. Thus, the class loader loads the file access code of code assembly 206 into runtime call stack 200.
[0034]
Each permission grant set corresponds to a code assembly in the runtime call stack. To this end, any attempt by the code assembly to access the protected resource is evaluated against the associated grant set, as well as the other code assembly grant sets in the runtime call stack 200. In the example of a read operation on a protected file by the application shown in FIG. 2, the main code assembly 202 is associated with the permission grant set 208. The main code assembly 202 invokes a method in the parser code assembly 204 associated with the authorization grant set 210 (represented by arrow 214). To access a protected file, parser code assembly 204 calls a method in file access code assembly 206 associated with permission grant set 212 (represented by arrow 216). To determine whether the file access code assembly 206 can access the protected file, the "intersection" of the permission grant sets 208, 210, 212 is calculated and the file access operation is permitted. Used to determine if For example, if the permission grant set 212 includes permission to read from a protected file, but one of the permission grant sets 208 or 210 does not, access to the protected file is denied.
[0035]
In general, the "intersection" operation (represented by the symbol "@") is a set operation that results in the common elements of the operand set. For example, if Set1 contains elements A, B, and C, and Set2 contains elements B, C, and D, the intersection of Set1 and Set2 (ie, Set1∩Set2) is equal to B and C. In contrast, a “union” operation (represented by the symbol “∪”) is a set operation that results in all elements in the operand set (ie, a non-overlapping set of all elements in the set). is there. For example, if Set1 includes elements A, B, and C, and Set2 includes elements B, C, and D, the union of Set1 and Set2 (ie, Set1∪Set2) is A, B, C, And D.
[0036]
FIG. 3 illustrates a computer system for managing evidence-based security in an embodiment of the present invention. A server 300 (eg, a web server) is coupled to a client 302 (eg, a web client) via a communication network (not shown). Client 302 executes a runtime environment (eg, a COM + 2.0 runtime environment from Microsoft® Corporation) to manage the execution of applications on client 302. In an embodiment of the present invention, the runtime environment includes a validation module 304, a loader module 306, and a policy manager 308.
[0037]
As described above, the code assembly is loaded into the runtime call stack 318 for execution by the virtual machine 312. The first category of code assembly is represented by local code assembly 314, which is generally considered a trusted code assembly because it originates on client 302. In contrast, a second category of code assemblies is represented by downloaded code assemblies 316, which may originate from remote or untrusted resource locations, such as server 300. there's a possibility that. In an embodiment of the present invention, local code assembly 314 and downloaded code assembly 316 are input to validation module 304 for validation. Thereafter, the code assembly is input to the loader module 306 and loaded into the runtime call stack 318.
[0038]
The code assemblies 314 and 316 generally relate to the evidence (or proofs) used to calculate the grant set for each code assembly. An example evidence component can be an AUTHENTICODE signature. Another example evidence component is a PICS (Platform for Internet Content Selection) label, which states the properties of the Internet resource (eg, executable code has been virus-scanned). For further details on PICS labels, see Resnick and J.M. Miller, "PICS: Internet Access Controls with Outsourcership", Communications of ACM, 39 (1996), pp. 87-93, and this paper is available at www.miller.com. w3. org / pub / WWW / PICS / iaccv2. It can also be viewed on http: // www. Other examples of evidence may include, but are not limited to, proof of purchase or license, creator identifier, vendor identifier, versioning information, and programmed proof. Programmatic proofs, for example, in the form of program code that examines statements made by other proofs, fetches supplemental information from the network, and then determines which proof statements to provide to policy manager 308 It is possible.
[0039]
Evidence for the code assembly itself can be provided by the host or extracted from the code assembly itself. Evidence 322, local or provided by the host, is implicitly trusted and believed to be true. However, evidence 320 downloaded or provided by the assembly is not implicitly trusted and must be self-verified (eg, digitally signed) or independently verified. Must. Downloaded evidence 320 may have been downloaded from one or more resource locations, and is not limited to evidence downloaded from the resource location from which the code assembly originated.
[0040]
The local evidence 322 and the downloaded evidence 320 are input to the policy manager 308, which evaluates the evidence based on the security policy. Within the policy manager 308, the evidence is evaluated in combination with the security policy specification 326 (and, optionally, a permission request 324 that defines the set of permissions required by the code assembly) to obtain the final corresponding to the given code assembly. A permission grant set is generated.
[0041]
In an embodiment of the present invention, the authorization request 324 is associated with one or more code assemblies 314 and 316, and has three types of authorization request sets: (1) a minimum request set (MinRS); And (3) a rejection request set (RefuseRS). It should be understood that other types of permission request sets are contemplated within the scope of the present invention.
[0042]
In one embodiment of the present invention (see the filtering flowchart of FIG. 6), the default values for MinRS and ReuseRS are equal to the empty set, and the default values for OptRS are equal to the entire set. As a result, if no permission request is provided, the intermediate permission set 422 of FIG. 4 is delivered as the resulting permission delivery set 414.
[0043]
The minimum set of requirements defines the minimum set of permissions and can include the minimum set of permissions required for the associated code assembly to be executed. If the permission grant set generated by the policy manager 308 does not meet the minimum permission conditions (eg, if the minimum request set is not a subset of the intermediate permission set output by the permission set generator 518 of FIG. 5). Causes the policy manager 308 to raise a policy exception that informs the loader 306 that the associated code assembly 314 or 316 should not be loaded. In this embodiment, security decisions involving a minimal set of requests are evaluated prior to loading and executing the code assembly. Alternatively, the policy manager 308 may allow the code assembly to be loaded with an insufficient grant set, however, because of this insufficient grant set, the code assembly may not execute. Can not.
[0044]
By way of non-limiting example, if at least one of the ordered request sets is a subset of the intermediate permission set, the present invention includes providing a plurality of ordered request sets where the minimum permission conditions are met. Other minimum permission conditions may be used within the scope. Thus, the intermediate permission set can be filtered using the first ordered set of requests that are satisfied.
[0045]
Further, prevent code assembly from being executed, including, but not limited to, setting attributes associated with the associated code assembly 314 or 316 indicating that the minimum permissions have not been met. Other techniques for can also be used. For example, the loader 306 may check the attributes for each code assembly before proceeding to load the code assembly. The loader 306 can also return the result to the virtual machine 312 to indicate that the loading of the code assembly has failed and cannot be performed.
[0046]
In another embodiment of the present invention, the runtime environment within client 302 may attempt to provide a corrective action in response to the code assembly failing to obtain permission to satisfy a minimal set of requests. It is possible. For example, if the minimum set of requests includes the required permissions to write to a given protected directory, the runtime environment can query the user and grant this permission. Further, the authority required for a user to interactively issue such required permissions can be limited based on the identity of the user (eg, only users with administrator status can Such permission may be issued to the ceremony).
[0047]
The optional request set includes permissions that the code assembly prefers to be issued, but are not absolutely necessary for the code assembly to be executed. Allowing such an option allows the code assembly to provide higher functionality. However, if no optional permissions are granted, the more basic functions defined by the minimal set of requirements are still available.
[0048]
One embodiment of the present invention addresses the optional nature of a request set of options by incorporating optional features into the code assembly. That is, if some or all of the permissions in the request set of options were not granted, the code assembly will be executed, when the operation of the request is denied (or when the permission of the request is denied). ), You can know this. In response to such a denial, the code assembly may execute another or additional code that utilizes a different permission, such as the permissions indicated in a minimal set of permissions. In this embodiment, security decisions involving an optional set of requests are evaluated during execution of the code assembly.
[0049]
In another embodiment, a plurality of optional request sets may be obtained by the policy manager 308. Multiple sets of optional requests may be processed to specify the required permissions corresponding to multiple levels of functionality. Based on a set of optional requests that may or may not be satisfied by the permission set, the policy manager 308 may signal the loader 306 to exclude loading one or more classes. For example, if the loader 306 knows in advance that the permissions required by a given class are not available, it may not be necessary to load that class. Such an optional set of requests can be ordered so that the highest level of granting loads the appropriate code assembly to provide the highest level of functionality.
[0050]
Alternatively, an optional request set can be used to specify a group of optional permissions. For example, to provide a first level of functionality, the code assembly requires permissions A, B, C, and D (specified by a first set of optional requests), while a second level of It is possible that the code assembly only needs permissions A and B (specified by a second optional request set) to provide the function. Thus, if the permission set can only provide permissions A, B, and C, the first optional request set is not satisfied, but the second optional request set is satisfied. Thus, the second optional request set filters the permission set to provide only permissions A and B, avoiding unnecessary granting of permission C.
[0051]
Further, the verification process in the verification module 304 and the security management process in the policy manager 308 can be performed simultaneously, and the two processes can communicate to affect each other. For example, policy manager 308 may evaluate the evidence to indicate that a given type of code assembly is secured. Thus, this type of security guarantee can be communicated to the validation module 304, which can skip the operation of verifying the type based on that information. Alternatively, validation module 304 may determine that a given code assembly does not pass a type security check. In response, the validation module 304 communicates with the policy manager 308 to query the code assembly for permission to execute despite failing the type safety check. It can be carried out.
[0052]
FIG. 4 depicts a module of a policy manager for managing evidence-based security in an embodiment of the present invention. The executable modules described in connection with FIG. 4 can be implemented as software modules executable on a computer system. Alternatively, executable modules implemented in hardware or in a combination of hardware and software are also contemplated within the scope of the present invention. Further, the modules disclosed herein can be merged into a smaller number of modules or split into additional modules without departing from the scope of the invention.
[0053]
Policy manager 400 is coupled to receive security policy specification 402 and evidence set 404. The security policy specification 402 specifies the definition of one or more code groups. In one embodiment, the code groups are organized into one or more code group sets. Alternatively, the code groups may be configured in one or more code group hierarchies. The security policy designation can also define one or more policy levels. Evidence set 404 defines trust characteristics associated with the code assembly received by the computer system.
[0054]
In one embodiment of the invention, parser module 406 receives security policy specification 402 and extracts the definition of one or more named code groups. Each code group is associated with a membership criterion, a child definition (specifying zero or more child code groups of the code group), and a code group permission set. Membership criteria specify the conditions of membership for a given code group, and the evidence set must meet that condition in order for the corresponding code assembly to be considered a member of that code group. The child code group definition specifies the children of a given code group. If a code assembly proves membership in a first code group (ie, a parent code group), that code assembly is considered to be a member of a child code group of that parent code group. A code group permission set represents a set of permissions that can be assigned to a code group. If a code assembly is determined to be a member of a code group, the permissions of the associated permission set can be issued to the code assembly, and the code assembly undergoes other actions within the policy manager.
[0055]
Other code group embodiments may include other data structures. For example, in one embodiment, the code group set is represented by a one-dimensional list of code groups, each including a membership criterion and a permission set, omitting the child code group definitions described above. In this embodiment, the one-dimensional list may be ordered or unordered. Further, other data configurations are also contemplated within the scope of the present invention.
[0056]
In an exemplary embodiment of the present invention, the permission set can be named, allowing identification in the security policy specification 402. Multiple code groups can be assigned to the same named permission set. Thus, if a change is made to a named permission set (eg, the insertion or deletion of an individual permission), the change affects all of the code groups associated with the named permission set. For example, defining a single named set of permissions and assigning them to several code groups to grant the same permissions to several extranet business partner websites that are members of different code groups Can be.
[0057]
In embodiments of the present invention, three types of named permission sets are supported. (1) a standard permission set-this set is predefined and cannot be changed; (2) a predefined permission set-this set can be changed by an administrator; and (3) ) Custom permission set-This set can be user defined as long as the name of the permission set does not conflict with the name of a standard permission set or the name of a predefined permission set. In one embodiment, the standard permission set is available at all policy levels and cannot be redefined at any individual policy level (general scope). In this embodiment, the predefined permission sets and the custom permission sets are defined and referenced in any given policy level, and cannot be referenced from other policy levels (policy level range). However, it should be understood that in other embodiments of the present invention, the scope of any permission set can extend beyond a given policy level.
[0058]
Table 1 below describes the standard permission sets available in embodiments of the present invention. Some standard permission sets, such as the Internet Set and the Local Intranet Set, are predefined, but can be changed by a user or administrator. Other permission sets, such as skip confirmation, cannot be changed in embodiments of the present invention. Other named permission sets are also contemplated within the scope of the present invention, and the named permission sets described in Table 1 can be changed without departing from the present invention.
[0059]
[Table 2]

[0060]
Although a number of permissions have been described herein as example permissions in embodiments of the invention, the list of possible permissions contemplated within the scope of the invention is not limited to these example permissions. For example, permission may be granted to allow code assembly to be executed despite a failed verification. A class in one code assembly may grant another permission (eg, a right to a subclass) that allows inheritance from a class in another code assembly.
[0061]
A code group permission set associated with a given code group can specify the permissions associated with the code group. Alternatively, the code group permission set associated with a given code group may specify the permissions associated with the code group and all parent code groups. This flexibility allows various security configurations (eg, policy levels, permission sets, membership criteria, etc.) to be defined within a security policy specification. As described below, policy managers can be developed to accommodate such various security configurations.
[0062]
In one embodiment, security policy specification 402 may also specify a plurality of policy levels, each having one or more code groups. Code groups can be organized into one or more code group sets. The policy level allows an administrator to define different security policies, for example, for different machines, different users, different applications, different time periods, different user groups, and so on. When generating a policy level permission set for a given policy level, the membership evaluator 410 traverses the entire code group associated with that policy level. Thus, the policy manager 400 can generate a set of permissions associated with an individual policy level. Thereafter, permission sets from multiple policy levels can be processed (eg, merged or selected) to generate a resulting permission grant set 414.
[0063]
In the illustrated embodiment, the code group set generator module 408 receives the parsed definition from the parser module 406 and generates one or more code group sets in the memory of the computer system. Membership evaluator module 410 receives evidence set 404 and extracts trust characteristics associated with the corresponding code assembly. Membership evaluator module 410 traverses the entire code group to determine whether the code assembly is a member of one or more code groups. A permission set generator module 412 receives the membership determination from the membership evaluator module 410 and determines an intermediate permission set based on a logical combination of code group permission sets associated with the code group for which the code assembly was determined to be a member. 422 is generated. A permission / request filter module 424 filters the intermediate permission set 422 to generate a resulting permission delivery set 414.
[0064]
FIG. 5 depicts an example policy level at which a policy manager operates in an embodiment of the present invention. Security policy specification 500 is processed on policy manager 502 to generate one or more security policy levels 506, 508, and 510 (this processing is represented by dashed lines pointing to each of the policy levels). In an embodiment of the present invention, the security policy specification 500 is written in an XML (Extensible Markup Language) file. However, in other embodiments, SGML (Standard Generalized Markup Language), HTML (Hypertext Markup Language), RDF (Resource Description Framework), Visual Basic, and other standard and customized data formats and codes Other data formats, including but not limited to formats, can also be used.
[0065]
In an embodiment of the present invention, security policy specification 500 is a persistent representation of a security policy in which each policy level is composed of code groups (eg, an ordered set of policy levels and / or a code group set). Lower policy levels generally specify more restrictive policy restrictions than higher policy levels. The security policy specification 500 is typically generated by a system administrator, user, or application setup program with appropriate permissions. Example policy levels can include, but are not limited to, a corporate policy level, a machine policy level, a user policy level, and an application policy level.
[0066]
In one embodiment of the present invention, the highest policy level is an enterprise policy level that can define a security policy that applies to all systems within any given enterprise. The lower policy level is a machine policy level that can define a security policy that applies to all users on a given system. A user policy level can define a security policy that applies to a given user, regardless of which particular system the user is logged into. An application policy level can define a security policy that applies to a given application, regardless of the user or system running the application. Additional policy levels and policy level orders are also contemplated within the scope of the present invention.
[0067]
The security policy specification 500 can also manage security using code group sets (eg, code group level sets), where code group sets are defined by membership conditions, permitting sets and special attributes. Including. Security policy specification 500 consists of a declaration of a code group that has an associated set of permissions. Code assemblies that are members of a given code group can be granted permissions from the permission set associated with that code group. Code group membership is determined by policy manager 502 using a set of evidence 504 associated with the code assembly, such as a digital signature, the origin of the code assembly. The administrator can add a code group to the code group set to grant additional permissions to code assemblies belonging to the new code group.
[0068]
In embodiments of the present invention, a code group may be provided with an "exclusive" property flag as an attribute, which indicates that only permissions associated with that particular code group should be applied to member code assemblies. specify. Permission sets from other member code groups are ignored (ie, not merged).
[0069]
In embodiments of the present invention, code groups are defined in a code group hierarchy having a root node corresponding to an "all" code assembly. This root node represents a parent code group having child nodes, and each of the child nodes can also have child nodes, and a code group hierarchy is formed in the same manner. Other code group sets, including, but not limited to, an ordered or unordered list of code groups, are also contemplated within the scope of the present invention. If the policy manager 502 determines that a code assembly is a member of a parent code group, the code assembly is tested against the children of the parent code group to determine its membership as a child. Exemplary code group types and membership criteria are described in Table 2 below, but other code group types are also contemplated within the scope of the present invention. In addition, code group types can be associated with properties. For example, the code group type "software publisher" can be associated with a specific publisher "Microsoft (registered trademark)" such as "publisher: Microsoft (registered trademark)".
[0070]
[Table 3]

[0071]
Further, the security policy specification 500 can define multiple policy levels. In the illustrated embodiment, each policy level (eg, enterprise level 506, machine level 508, and user level 510) has a distinct set of code groups. As described above, other policy level configurations, such as one or more code group sets, where multiple policy levels are allocated within the scope of the present invention (eg, one policy per subtree associated with children of the root node). May be used.
[0072]
In the illustrated embodiment, a policy level permission set (eg, a corporate level permission set 512, a machine level permission set 514, or a user level permission set 516) is generated from each policy level. A policy level permission set merger 518 merges or otherwise processes the policy level permission sets 512, 514, and 516 to generate an intermediate permission set 526.
[0073]
The permission / request filter 524 inputs the permission request 522 and applies the filter algorithm to the intermediate permission set 526 to generate the resulting permission delivery set 520, if appropriate.
[0074]
In an example embodiment, the grant / request filter 524 applies a filter algorithm to generate a grant grant set 520, as described in combination with FIG.
1) MaxRS = (MinRS∪OptRS) [Operation 600]
2) If (MinRS is not a subset of IntPS) [Act 602], then policy manager 502 raises a policy exception to prevent loading and / or execution of code assembly [Act 604].
3) If (MinRS is a subset of IntPS) [operation 602], then PGS = (MaxRS∩IntPS) -RefuseRS [operation 606]
4) If (PGS includes execute permission) [Act 608], the then code assembly can be loaded by loader 306 of FIG. 3 [Act 610] and PGS is shown in conjunction with the code assembly. 3 can be loaded into the runtime stack 318 [act 612].
5) If (PGS does not include execution permission) [action 608], then policy manager 502 raises a policy exception to prevent loading and / or execution of code assembly [action 614].
Where PGS represents permission grant set 520, IntPS represents intermediate permission set 526, MaxRS represents a maximum request set, MinRS represents a minimum permission request, OptRS represents an optional permission request, and , RefuseRS indicates a rejection permission request. MinRS, OptRS, and ReuseRS are received as elements of authorization request 522.
[0075]
In embodiments of the present invention, if MinRS, OptRS or RefuseRS are not specified, they are assigned default values. For MinRS and RefuseRS, the default value is an empty set. For OptRS, the default value is the entire set. For example, if MinRS and OptRS are not specified, PGS is equal to IntPS-RefuseRS.
[0076]
The logical set operation 606 is used to generate a subset of the intermediate permission set so that only the required permissions are included in the permission grant set. That is, the intermediate permission set may be much wider than the permission set required or required by the code assembly. Thus, unnecessary or unsolicited permissions can be excluded from the resulting set of permissions.
[0077]
It should be understood that the above-disclosed algorithm is merely an example algorithm for filtering intermediate grant sets using a grant request. Other algorithms are also contemplated within the scope of the present invention, especially if different combinations of authorization requests are used (eg, additional types of authorization request sets).
[0078]
FIG. 7 illustrates an exemplary system useful for implementing embodiments of the present invention. An exemplary computer system for an embodiment of the present invention includes a conventional processor unit 702, a system memory 704, and a system bus 706 coupling various system components including the system memory 704 to the processor unit 700. A general purpose computer device in the form of a computer system 700 is included. System bus 706 may be any of several types of bus structures, including a memory bus or memory controller using any of a variety of bus architectures, a peripheral bus, and a local bus. System memory includes read-only memory (ROM) 708 and random access memory (RAM) 710. A basic input / output system 712 (BIOS), containing the basic routines that help transfer information between elements within computer system 700, is stored in ROM 708.
[0079]
Computer system 700 includes a hard disk drive 712 for reading and writing to a hard disk, a magnetic disk drive 714 for reading and writing to a removable magnetic disk 716, and a CD-ROM, DVD, or An optical disk drive 718 for reading from and writing to a removable optical disk 719 such as another optical medium. The hard disk drive 712, magnetic disk drive 714, and optical disk drive 718 are connected to the system bus 706 by a hard disk drive interface 720, a magnetic disk drive interface 722, and an optical disk drive interface 724, respectively. The drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, programs, and other data for computer system 700.
[0080]
The example environment described herein uses a hard disk, a removable magnetic disk 716, and a removable optical disk 719, but other types of computer-readable media capable of storing data are also examples. Can be used in any system. Examples of other types of computer readable media that can be used in the exemplary operating environment include magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory (RAM), and read-only memory (ROM). ) Is included.
[0081]
Several program modules, including operating system 726, one or more application programs 728, other program modules 730, and program data 732 are stored on a hard disk, magnetic disk 716, optical disk 719, ROM 708, or RAM 710. It is possible that A user can enter commands and information into the computer system 700 via input devices such as a keyboard 734 and a mouse 736 or other pointing device. Examples of other input devices can include a microphone, joystick, game pad, satellite dish, and scanner. These and other input devices are often connected to the processing unit 702 via a serial port interface 740 coupled to the system bus 706. Nevertheless, the above input devices may be connected by other interfaces such as a parallel port, a game port, or a universal serial bus (USB). A monitor 742 or other type of display device is also connected to the system bus 706 via an interface, such as a video adapter 744. In addition to the monitor 742, the computer system typically also includes other peripheral output devices (not shown), such as speakers and a printer.
[0082]
Computer system 700 can operate in a networked environment that uses logical connections to one or more remote computers, such as remote computer 746. Remote computer 746 can be a computer system, server, router, network PC, peer device, or other common network node, and typically includes many of the elements described above in connection with computer system 700, or Including all. Network connections include a local area network (LAN) 748 and a wide area network (WAN) 750. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.
[0083]
When used in a LAN networking environment, the computer system 700 is connected to a local network 748 via a network interface or network adapter 752. When used in a WAN networking environment, computer system 700 typically includes a modem 754 or other means for establishing communication over a wide area network 750, such as the Internet. A modem 754, which can be internal or external, is connected to system bus 706 via serial port interface 740. In a networked environment, program modules depicted relative to the computer system 700, or portions of program modules, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
[0084]
In the illustrated embodiment, the security policy designation can be read into memory 704, for example, from a file on hard disk drive 712. A CPU 702 implements the virtual machine and executes memory-resident instruction code for a computer process that generates a permission grant set using the classified permission requests associated with the code assembly received from the resource location. Further, the CPU 702 also executes software components that implement the policy manager described in the claims.
[0085]
FIG. 8 is a flowchart illustrating operations for generating a permission grant set using a classified permission request associated with a code assembly received from a resource location in an embodiment of the present invention. The defining operation 800 defines a code group set according to the security policy specification. A code group set includes one or more code groups and can be organized as a code group hierarchy. A receiving operation 802 receives evidence associated with the code assembly. A membership operation 804 evaluates the membership of the code assembly in relation to the code group. Generally, this assessment is based on the membership criteria associated with each code group.
[0086]
Generate operation 806 generates a permission set based on one or more membership decisions made by membership operation 804. For example, in one embodiment where the code group set is configured as a code group hierarchy, the permission set is dynamically determined by combining the permissions associated with the parent and child code groups for which the code assembly has been determined to be members. Generated. The combined permissions are output as a permission set from the generate operation 806, and the permission set is received by the permission / request filter module.
[0087]
A receiving operation 808 receives a permission request associated with the code assembly. This authorization request may be received as part of the code assembly, or at a local resource location (eg, within a computer system, from a connected peripheral or storage medium, or from a local network storage location), or a remote resource location. It can be received (or obtained) from another source, such as a location (eg, via the Internet).
[0088]
A filtering operation 810 filters the permission set based on the permission request set and controls execution of the code assembly. Preventing the policy manager from loading or executing the code assembly if the filtering operation 810 determines that the minimum set of requests is provided in association with the code assembly and that the set of requests is not a subset of the permitted set; Can be. Similarly, if the execution permission is not included in the permission set, the filtering operation 810 can prevent loading or operation of the code assembly.
[0089]
The filtering operation 810 also includes a permission grant set to avoid issuing permissions not required by the code assembly when a minimal or optional set of requirements is provided in association with the code assembly. When generating a request, permissions that are not included in the request set can be excluded. Further, if a deny request set is provided in connection with the code assembly, the permissions included in that request set may also be excluded from the permission grant set.
[0090]
The embodiments of the invention described herein are implemented as logical steps in one or more computer systems. The logical operations of the present invention can be performed as (1) steps performed by a series of processors executing in one or more computer systems, and (2) interconnected machine modules within one or more computer systems. Will be implemented as Embodiments are a matter of choice depending on the performance requirements of the computer system implementing the invention. Accordingly, the logical operations making up the embodiments of the invention described herein are referred to variously as operations, steps, objects, or modules.
[0091]
The above specification, examples, and data provide a complete description of the structure and use of example embodiments of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
[Brief description of the drawings]
FIG.
FIG. 3 depicts an evidence-based security policy manager in an embodiment of the present invention.
FIG. 2
FIG. 4 illustrates a runtime call stack in an embodiment of the present invention.
FIG. 3
FIG. 2 depicts a computer system for managing evidence-based security in an embodiment of the present invention.
FIG. 4
FIG. 4 illustrates a policy manager module for managing evidence-based security in an embodiment of the present invention.
FIG. 5
FIG. 4 is a diagram illustrating a policy level as an example in which a policy manager operates in the embodiment of the present invention.
FIG. 6
5 is a flowchart illustrating filtering used in an embodiment of the present invention.
FIG. 7
FIG. 1 illustrates an example system useful for implementing embodiments of the present invention.
FIG. 8
5 is a flowchart illustrating operations for processing a permission set in an embodiment of the present invention.

Claims (37)

A method of processing permission sets associated with a code assembly received from a resource location to control execution of the code assembly, the method comprising:
Receiving the permission set including at least one permission associated with the code assembly;
Receiving a permission request set associated with the code assembly; and
Filtering the permission set based on the permission request set to control execution of the code assembly. The method of claim 1, wherein the act of filtering comprises generating a permission grant set from a subset of the permission set specified by the permission request set. The method of claim 1, wherein the act of filtering includes calculating a logical set operation on the permission set and the permission request set to generate a permission grant set. The permission request set specifies a minimum permission condition, and the act of filtering includes preventing the loading of the code assembly if the permission set cannot meet the minimum permission condition. The method of claim 1, wherein: The permission request set specifies a minimum permission condition, and the act of filtering includes preventing the execution of the code assembly if the permission set cannot meet the minimum permission condition. The method of claim 1, wherein: Defining a code group set that includes one or more code groups based on the security policy specification;
Receiving evidence relating to said code assembly;
Evaluating the membership of the code assembly in the one or more code groups based on the evidence; and
The method of claim 1, further comprising generating the permission set based on the membership of the code assembly in the one or more code groups. The permission request set specifies a plurality of classified permission request sets, and each type of permission request set specifies a distinct type of permission preference required in connection with the code assembly. The method of claim 1, wherein: The method of claim 1, wherein the permission request set specifies a minimum request set that specifies a minimum set of permissions required in connection with the code assembly. The act of filtering is characterized by filtering the permission set based on the minimum request set to generate a permission grant set such that the permission grant set includes a subset of the permission set. The method according to claim 8. 9. The method of claim 8, further comprising preventing loading of the code assembly if the minimum request set is not a subset of the permission set. The method of claim 8, further comprising preventing execution of the code assembly if the minimum request set is not a subset of the permission set. The method of claim 1, wherein the permission request set specifies an optional request set that specifies a set of optional permissions required in connection with the code assembly. The method wherein the act of filtering includes filtering the permission set based on the request set of options to generate a permission grant set.
Performing a first level of code assembly functionality if the optional set of requests is a subset of the set of grants;
The method of claim 12, further comprising performing a second level code assembly function if the optional request set is not a subset of the grant set. The method of claim 1, wherein the permission request set specifies a deny request set that specifies one or more sets of permissions to be excluded from a permission grant set in association with the code assembly. The method of claim 14, wherein the act of filtering comprises excluding the set of one or more permissions specified by the set of deny requests from the permission grant set. An optional request set wherein the permission request set specifies an optional set of permissions required in connection with the code assembly, and a minimum request set specifying a minimum set of permissions required in connection with the code assembly. A request set, comprising:
The filtering operation includes:
Calculating the union of the optional requirement set and the minimum requirement set to provide a maximum requirement set; and
The method of claim 1, comprising calculating an intersection of the maximum request set and the permission set. A method further comprising specifying a denial request set that specifies one or more sets of permissions in which the permission request set is excluded from a permission grant set in association with the code assembly.
The filtering operation includes:
17. The method of claim 16, further comprising removing the set of one or more permissions specified in the deny request set from the intersection of the maximum request set and the permission set. the method of. The method of claim 1, wherein the act of receiving a permission request set comprises receiving the permission request set and the code assembly in a single network communication. The method of claim 1, wherein the act of receiving a permission request set comprises receiving the permission request set in a network communication separate from a network communication in which the code assembly is received. A policy manager module for processing a set of permissions associated with a code assembly received from a resource location to control execution of the code assembly, comprising:
A module comprising: a filter for receiving the permission set and permission request set associated with the code assembly and filtering the permission set based on the permission request set to control execution of the code assembly. 21. The policy manager module of claim 20, further comprising a permission set generator receiving a set of evidence and generating a permission set in association with the code assembly based on the set of evidence. 21. The policy manager module of claim 20, wherein the filter generates a permission grant set from a subset of the permission set specified by the permission request set. 21. The policy manager module of claim 20, wherein the filter computes a logical set operation on the permission set and the permission request set to generate a permission grant set. 21. The policy manager module of claim 20, wherein the filter prevents loading of the code assembly if the permission set cannot satisfy the minimum permission condition. The policy manager module of claim 20, wherein the filter prevents execution of the code assembly if the permission set fails to satisfy the minimum permission condition. The permission request set specifies a plurality of categorized permission request sets, and each type of permission request set specifies a distinct type of permission preference required in connection with the code assembly. 21. The policy manager module according to item 20. 21. The policy manager module of claim 20, wherein the permission request set specifies a minimum request set that specifies a minimum set of permissions required in connection with the code assembly. 21. The policy manager module of claim 20, wherein the permission request set specifies an optional request set that specifies a set of optional permissions required in connection with the code assembly. 21. The policy manager module of claim 20, wherein the filter generates a permission grant set excluding one or more permissions specified in a denial request set. An optional request set wherein the permission request set specifies an optional set of permissions required in connection with the code assembly, and a minimum request set specifying a minimum set of permissions required in connection with the code assembly. A policy manager module that specifies the request set of the
The filtering operation includes:
Calculating the union of the optional requirement set and the minimum requirement set to provide a maximum requirement set; and
21. The module of claim 20, comprising calculating an intersection of the maximum request set and the permission set. The filter generates an authorization grant set based on an optional request set, the authorization grant set being associated with a first level code assembly function if the optional request set is a subset of the authorization grant set. 21. The policy manager module of claim 20, wherein the optional request set is associated with a second level code assembly function if the request set is not a subset of the permission grant set. A code group set generator that generates a code group set including one or more code groups based on a security policy specification;
A membership evaluator that determines membership of the code assembly in the one or more code groups based on evidence associated with the code assembly; and
The policy manager module of claim 20, further comprising a permission set generator that generates the permission set based on the membership of the code assembly in the one or more code groups. A computer program, embodied on a carrier wave by a computer system, for executing a computer process for performing processing of a permission set associated with a code assembly received from a resource location and controlling execution of the code assembly. A computer data signal to be converted,
The computer process comprises:
Receiving the permission set including at least one permission associated with the code assembly;
Receiving a permission request set associated with the code assembly; and
A computer data signal comprising: filtering the permission set based on the permission request set to control execution of the code assembly. A computer program storage medium readable by a computer system and encoding a computer program for executing a computer process for processing a permission set associated with a code assembly received from a resource location, the computer program storage medium comprising:
The computer process comprises:
Receiving the permission set including at least one permission associated with the code assembly;
Receiving a permission request set associated with the code assembly; and
A computer program storage medium comprising filtering the permission set based on the permission request set to control execution of the code assembly. A computer program encoding a computer program for processing a set of permissions associated with a code assembly received from a resource location to execute on a computer system a computer process for controlling execution of the code assembly, comprising:
The computer process comprises:
Defining a code group set that includes one or more code groups based on a security policy specification;
Receiving evidence relating to said code assembly;
Evaluating the membership of the code assembly in the one or more code groups based on the evidence;
Generating the permission set based on the membership of the code assembly in the one or more code groups;
Receiving the permission set including at least one permission associated with the code assembly;
Receiving a permission request set in connection with the code assembly; and
A computer program comprising calculating a logical set operation on the permission set and the permission request set to generate a permission grant set. An optional request set wherein the permission request set specifies an optional set of permissions required in connection with the code assembly, and a minimum request set specifying a minimum set of permissions required in connection with the code assembly. A computer program comprising a request set of
The filtering operation includes:
Calculating the union of the optional requirement set and the minimum requirement set to provide a maximum requirement set; and
The computer program product of claim 35, comprising calculating an intersection of the maximum request set and the permission set. A computer program further specifying a deny request set that specifies one or more sets of permissions, wherein the set of permission requests is excluded from a permission grant set in association with the code assembly,
The filtering operation includes:
37. The method of claim 36, further comprising removing the set of one or more permissions specified in the deny request set from the intersection of the maximum request set and the permission set. Computer programs.

Images