(57)【要約】【課題】  高信頼性コンピューティングプラットフォームに適用されるセキュリティポリシ内のルール衝突を解決するシステムおよび方法を提供する。【解決手段】  衝突しているルールｖおよびｓのそれぞれが参照するファイル集合（すなわち「スコープ」）を判定する（ステップ１０）。次に（ステップ１２で）、一方のルールｓのスコープがルールｒのスコープの完全部分集合であるかどうかを判定する。そうである場合、（ステップ１４で）ルールｓをアクセスされるファイルｆに適用する。そうでない場合、別の方法、例えば、（ステップ１６で）ルールｒおよびｓのうち限定的なほうを判定し、それに従って結果を適用する（ステップ１８）ことによって、衝突を解決する。【選択図】  図９
2004303243.tif 000002
【特許請求の範囲】
【請求項１】
高信頼性コンピューティングプラットフォームと、
１つまたは複数の論理的被保護コンピューティング環境と、
複数のファイルおよび該ファイル間のアクセスパスを規定するリンクを備えるファイルシステムと
を備えるシステムであって、
前記論理的被保護コンピューティング環境および／または前記ファイルの１つまたは複数に関する複数のセキュリティルールを含む所定のセキュリティポリシを、前記高信頼性コンピューティングプラットフォーム上にロードするように構成され、さらに、
指定されたファイルまたはファイルの集合に第１および第２セキュリティルールが適用されることを決定し、
前記第１および第２セキュリティルールのそれぞれが適用されるファイルの完全な集合（ファイル集合）を判定し、
前記第１セキュリティルールのファイル集合が、前記第２セキュリティルールのファイル集合の完全部分集合であるかどうかを判定し、
完全部分集合である場合、前記第１セキュリティルールを前記指定されたファイルまたはファイルの集合に適用し、
完全部分集合でない場合、前記第１および第２セキュリティルールの一方をそれらの別の属性に基づいて選択し、
該選択されたセキュリティルールを前記指定されたファイルまたはファイルの集合に適用する
ように構成されるシステム。
【請求項２】
前記セキュリティルールは、
前記論理的被保護コンピューティング環境および／またはファイルの１つまたは複数に関する任意的アクセス制御を規定する複数のファイルルール
を含む
請求項１に記載のシステム。
【請求項３】
前記セキュリティルールは、
前記論理的被保護コンピューティング環境および／またはファイルの１つまたは複数に関するセキュリティ属性を規定および／または変更する複数の実行制御ルール
を含む
請求項１または２に記載のシステム。
【請求項４】
前記第１および第２セキュリティルールはファイルルールであり、
前記第１セキュリティルールが適用されるファイル集合は、前記第２セキュリティルールが適用されるファイル集合の完全部分集合ではなく、
該システムは、前記第１および第２セキュリティルールのいずれのほうが限定的であるかを判定し、そのルールを前記指定されたファイルまたはファイルの集合に適用するように構成される
請求項２に記載のシステム。
【請求項５】
前記第１および第２セキュリティルールは、実行制御ルールであり、
前記第１セキュリティルールが適用されるファイル集合は、前記第２セキュリティルールが適用されるファイル集合の完全部分集合ではなく、
該システムは、前記セキュリティポリシに一番最近に追加されたルールを選択し適用するように構成される
請求項３に記載のシステム。
【請求項６】
ルール衝突が存在することをユーザに知らせる警告またはエラーメッセージを提供するように
構成される請求項５に記載のシステム。
【請求項７】
ファイルまたはファイルの集合の間のリンクが作成される時に、ルール衝突の生成を識別し、それに従ってエラーメッセージまたは警告を提供する手段
を含む請求項１〜６のいずれかにに記載のシステム。
【請求項８】
不正なリンクを削除し、それによって、前記衝突を除去するように
構成される請求項７に記載のシステム。
【請求項９】
添付図面を参照して本明細書に実質的に記載された
システム。
【請求項１０】
高信頼性コンピューティングプラットフォームと、
１つまたは複数の論理的被保護コンピューティング環境と、
複数のファイルおよび該ファイル間のアクセスパスを規定するリンクを備えるファイルシステムと
を有するシステムに、
所定のセキュリティポリシを適用する方法であって、
該セキュリティポリシは、
前記論理的被保護コンピューティング環境および／または前記ファイルの１つまたは複数に関する複数のセキュリティルール
を含み、
指定されたファイルまたはファイルの集合に第１および第２セキュリティルールが適用されることを決定するステップと、
前記第１および第２セキュリティルールのそれぞれが適用されるファイルの完全な集合（ファイル集合）を判定するステップと、
前記第１セキュリティルールのファイル集合が前記第２セキュリティルールのファイル集合の完全部分集合であるかどうかを判定するステップと、
完全部分集合である場合、前記第１セキュリティルールを前記指定されたファイルまたはファイルの集合に適用するステップと、
完全部分集合でない場合、前記第１および第２セキュリティルールの一方をそれらの別の属性に基づいて選択し、該選択されたセキュリティルールを前記指定されたファイルまたはファイルの集合に適用するステップと
を含むセキュリティポリシを適用する方法。
【請求項１１】
前記セキュリティルールは、アクセス制御の規定およびセキュリティ属性の変更またはこれらのいずれかを行う
請求項１０に記載のセキュリティポリシを適用する方法。
【請求項１２】
高信頼性コンピューティングプラットフォームに所定のセキュリティポリシを適用する方法であって、
添付図面を参照して本明細書に実質的に記載された
セキュリティポリシを適用する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
［発明の分野］
本発明は、包括的に、信頼性の高いコンピューティングシステム、すなわち高信頼性コンピューティングシステムで使用されるセキュリティポリシに関し、特に、高信頼性コンピューティングシステムにおけるファイルのアクセス権限およびシステムリソースへの許容されるアクセスに関するセキュリティ属性を規定する方法および装置に関する。
【背景技術】
【０００２】
［発明の背景］
商用アプリケーションでは、クライアントコンピューティングプラットフォームは通常、その挙動がローカルまたはリモートのエンティティによる変更に対して脆弱であるような環境で動作する。
プラットフォームのこの潜在的なセキュリティの欠如は、例えば電子商取引の目的で、セキュリティがあればそのプラットフォームを使用しても構わないと考えているローカル当事者や、セキュリティがあればそのプラットフォームと通信するかもしれないリモート当事者によるその使用を制約している。
【０００３】
本出願人による同時係属中の開示ＷＯ００／４８０６３（参照により本明細書に援用する）には、組込みハードウェアおよびソフトウェアコンポーネントの形態で「高信頼性コンポーネント」を有するコンピューティングプラットフォームを備える「高信頼性コンピューティングプラットフォーム」の概念が開示されている。
この文書には、高信頼性デバイス（ＴＤ、Trusted Device）または高信頼性プラットフォームモジュール（ＴＰＭ、Trusted Platform Module）を用いて、完全性メトリックの信頼できる測定および報告により、コンピューティング装置の完全性(integrity)の検証を可能にすることが記載されている。
ＴＤ／ＴＰＭは、Trusted Computing Platform Alliance（ＴＣＰＡ）仕様に準拠している。
例えば非特許文献１（www.trustedpc.org）を参照されたい。
【０００４】
高信頼性デバイスまたは高信頼性プラットフォームモジュールは、その内部でサービスまたはプロセスを実行することが可能な１つまたは複数の論理的に保護されたコンピューティング環境（論理的被保護コンピューティング環境）すなわち「コンパートメント」を含み得る。
コンパートメント内でのアクションまたは特権は、特に、コンパートメントの外部に効果を有するメソッドおよびオペレーション（例えば、ネットワークアクセスやコンパートメントの外部のファイルへのアクセスを要求するメソッド）を実行するプロセスの能力を制限するように制約される。
また、コンパートメント内のプロセスまたはサービスのオペレーションは、外部の影響による干渉およびのぞき見(prying)から高度に隔離されて実行される。
各コンパートメントは、オペレーティングシステムカーネルによって制御されるオペレーティングシステムコンパートメントであってもよい。
これは、コンパートメント化オペレーティングシステムまたは高信頼性オペレーティングシステムとも呼ばれる。
【０００５】
高信頼性オペレーティングシステムは、機密（軍事）情報を取り扱いかつ処理するために設計された形態で数年前から利用可能となっており、オペレーティングシステムのカーネルによって実施される閉じ込めメカニズムを用いて、ファイル、プロセスおよびネットワークコネクションのようなコンピューティングプラットフォームのリソースに対する強制的アクセス制御を行う。
オペレーティングシステムは、リソースにラベルを付加し、それらのラベル値に基づいて、リソース間の許容される相互作用を統制するセキュリティポリシを実施する。
多くの高信頼性オペレーティングシステムは、Bell-Lapadulaモデルに基づくセキュリティポリシを適用している。
このモデルは、非特許文献２（C I DaltonとJ F GriffinによるComputer Networks and ISDN Systems 29 (1997) 1799-1808に発表された論文「Applying Military Grade Security to the Internet」）に記載されている。
【０００６】
いずれにしても、多くの高信頼性コンピューティングプラットフォームは、比較的簡便な形態のオペレーティングシステムコンパートメントを採用している。
一般的に、保護したいコンピューティングプラットフォームの各リソースに、そのリソースが属するコンパートメントを示すラベルが与えられる。
あるコンパートメントからのリソースが別のコンパートメントからのリソースと干渉しないようにするために、セキュリティポリシを組み込んだ強制的アクセス制御がホストオペレーティングシステムのカーネルにより実行される。
セキュアなシステムでは、システムリソースへのアクセスは、セキュリティまたはサブジェクト属性によって規定される。
【０００７】
上記のセキュリティポリシは、セキュリティルールの形態で表現されることが多い（各セキュリティルールは一般に、セキュリティ属性を規定する命令行を含む）。
一般的に、１つまたは複数のセキュリティルールが１つのコンパートメントに関連し、各コンパートメントは１つまたは複数のサービスに関連してもよい。
通常の任意的アクセス制御に加えて、強制的アクセス制御を規定するためにファイルルールを使用してもよい。
一般的に、ファイルルールは、どのコンパートメントにルールが適用されるかを規定するｃｏｍｐフィールドと、ルールが適用されるディレクトリまたはファイルを規定するｆｉｌｅｎａｍｅフィールドを有する。
ディレクトリに対するファイルルールは、そのディレクトリおよびそのディレクトリから到達可能な全ファイルに適用される。
ファイルルールによって許可されるアクセスは、そのａｃｃｅｓｓフィールドによって規定される。
【０００８】
ある既知のシステムでは、アクセスの形式は、読み出し(read)、書き込み(write)、追加(append)、実行(execute)である。
ほとんどのファイルオペレーションについて、そのオペレーションによって要求されるアクセスが、適用可能なファイルルールによって許可される場合、または適用されるファイルルールが存在しない場合にのみ、そのオペレーションは許可される。
【０００９】
／ｃｏｍｐｔ／ｗｅｂ（注意：文中で下線を付した文字はイタリック体である）の配下のウェブサイトがコンパートメントｗｅｂ内で実行されている場合を考える。
ウェブサイトが汚損されないようにするため、リードオンリルールを／ｃｏｍｐｔ／ｗｅｂに課することができる：
file [ comp web; filename /comp/web; access read; ]
【００１０】
しかし、ウェブマスタがログを書き込む必要があるかもしれないので、読み書きアクセスを／ｃｏｍｐｔ／ｗｅｂ／ｌｏｇｓに与えてもよい：
file [ comp web; filename /comp/web/logs; access read, write ]
【００１１】
その趣旨は、ファイルルールはそのファイル名(filename)から到達可能なファイルの最高パーミッションを規定するということである。
１つのファイルが複数のルール内でファイル名から到達可能であるような一部の従来のシステムでは、「最も特定的な(most specific)」ルール、すなわち、最も長いファイル名を有するルールが使用される。
あるファイルに適用されるルールがない場合、そのパーミッションは制約されず、それに対するファイル制御オペレーションに関する通常のパーミッションが指定される。
異なるコンパートメントに対するルールは独立に扱われることになる。
【００１２】
しかし、挙動のこの規定は不十分であることが分かっている。
一部の既知のシステムでは、ファイルシステムがファイル名をファイル自体にマッピングし、ファイルはデバイス番号およびｉノード番号によって一意に識別される。
ハードリンク、シンボリックリンク、多重マウント、およびあるディレクトリを別のディレクトリ上にマウントするために−ｂｉｎｄを使用するマウントが存在するために、多くのファイル名が同一ファイルとして解決されることがある。
これは「ファイル名エイリアシング」と呼ぶことができる。
すなわち、いつ複数のルールが１つのファイルに適用されるか、さらに、いかなるルールであれそれがファイルに適用されるかどうかは、常に明らかであるわけではない。
さらに、ルール衝突の問題も存在する。
すなわち、ファイル名エイリアシングがある場合、異なるファイル名を有する２つのルールにおいて、いくつかのファイルには一方のルールのみが適用され、いくつかのファイルには潜在的に両方のルールが適用される可能性がある。
【００１３】
図面の図３を参照して、次のファイルルールｒ１を考える：
file [comp web; filename /x; access read;]
【００１４】
ここで、もしユーザがコンパートメントｗｅｂからファイル／ｘ／ｆに書き込みを試みるとすれば、オペレーションが許可されずに失敗するであろう（その理由は、ディレクトリｘはｒ１によって規定されるリードオンリアクセスを有し、それは／ｘ／ｆにも適用されるからである）。
一方、別のディレクトリ／ｙも存在し、それに次のルールｒ２が適用される場合を考える：
file [comp web; filename /y; access read, write]
【００１５】
ユーザは、／ｙ／ｆという／ｘ／ｆへのハードリンクを作成することができる。
その理由は、ユーザは／ｙへの書き込みアクセスを有し、そのリンクを作成するには／ｘ／ｆへの読み出しアクセスがあればよいからである。
したがって、ファイル名／ｙ／ｆがアクセスされる場合、これは／ｘ／ｆと同じｉノード１００として解決されるが、カーネルｄエントリは、／ｙ／ｆがファイル／ｘ／ｆの別名であることを知らずに、／ｙをその親として示し、たとえｒ１が適用されるべきであってもｒ２を適用するであろう。
他方、／ｙ／ｆが／ｘ／ｆへのシンボリックリンクである場合、ｉノード１００に対するカーネルｄエントリはその親として／ｘを有し、ｒ１が正しく適用されるであろう。
【００１６】
これに対して、図面の図４を参照して、シンボリックリンク／ｘ／ｙが／ｙに与えられたと仮定する。
すると、ファイル名／ｘ／ｙ／ｆはｙ／ｆと同じファイルｉノード１００として解決されるため、一見したところ、ｒ１が／ｘ／ｙ／ｆに適用されるはずである。
しかし、／ｘ／ｙはシンボリックリンクであるため、カーネルは／ｘ／ｙ／ｆを／ｙ／ｆのｄエントリとして解決するであろう。
【００１７】
ファイル別名は、同じファイルシステムを複数のディレクトリにマウントすることによっても生成され得る。
ディレクトリへのハードリンクは防止することができるが、ある既知のシステムでは「ｍｏｕｎｔ−ｂｉｎｄ」コマンドを用いて類似の効果を生じさせることができる。
このコマンドは、ディレクトリを他のいかなるディレクトリにマウントすることも可能にし、実質上、マウントポイントをマウントされるディレクトリにリンクする。
【００１８】
ウェブサイトは、攻撃者がウェブサーバのバッファオーバーフローバグを用いて、ウェブサーバに攻撃者のコードを実行させてウェブサイトファイルへの書き込みを行わせることによって汚損され得る。
上記の例示的なウェブサイトルールは、たとえウェブサーバがバッファオーバーフローバグを有する場合であってもこの汚損を防ぐことを意図している。
しかし、それらのルールがすべての場合に有効にこれを達成するには、ファイル名エイリアシングの問題が解決されなければならない。
さもなければ、攻撃者は、ウェブサーバに、／ｃｏｍｐｔ／ｗｅｂ／ｌｏｇｓ（これは読み書きアクセスを有する）内に／ｃｏｍｐｔ／ｗｅｂ（これは読み出しアクセスのみを有する）配下のファイルへのハードリンクを作成させることができる。
そして攻撃者は、リードオンリ保護を迂回して、ハードリンクを通じてファイルにアクセスすることができる。
したがって、ファイル名エイリアシングの問題が解決されない限り、ルールはウェブサイトが汚損されることを必ずしも防止することにならない。
【非特許文献１】www.trustedpc.org
【非特許文献２】C I DaltonとJ F GriffinによるComputer Networks and ISDN Systems 29 (1997) 1799-1808に発表された論文「Applying Military Grade Security to the Internet」
【発明の開示】
【発明が解決しようとする課題】
【００１９】
さらに、いくつかの既知のシステムではセキュリティポリシが使用される。
セキュリティポリシは、ファイルを各タイプに分類して、それらのタイプに基づいて許可されるアクセスを規定する。
分類は別個のフェーズとして行われ、その結果が格納される。
ファイルは、リネームされる時や、ファイルへのリンクが作成される時には再分類されない。
代わりに、分類プロセスは、ポリシが変更される時に手作業で実行されなければならない。
これは、複雑でエラーを起こしやすいことは言うまでもなく、不便で時間がかかることは明らかである。
【課題を解決するための手段】
【００２０】
したがって、本発明によれば、高信頼性コンピューティングプラットフォームと、１つまたは複数の論理的被保護コンピューティング環境と、複数のファイルおよび上記ファイル間のアクセスパスを規定するリンクを備えるファイルシステムとを備えるシステムであって、上記論理的被保護コンピューティング環境および／または上記ファイルの１つまたは複数に関する複数のセキュリティルールを含む所定のセキュリティポリシを高信頼性コンピューティングプラットフォーム上にロードするように構成され、さらに、指定されたファイルまたはファイルの集合に第１および第２セキュリティルールが適用されることを決定し、上記第１および第２セキュリティルールのそれぞれが適用されるファイルの完全な集合（ファイル集合）を判定し、上記第１セキュリティルールのファイル集合が上記第２セキュリティルールのファイル集合の完全部分集合であるかどうかを判定し、完全部分集合である場合、上記第１セキュリティルールを上記指定されたファイルまたはファイルの集合に適用し、完全部分集合でない場合、上記第１および第２セキュリティルールの一方をそれらの別の属性に基づいて選択し、選択されたセキュリティルールを上記指定されたファイルまたはファイルの集合に適用するように構成されるシステムが提供される。
【００２１】
セキュリティルールは、以下でさらに詳細に説明するように、アクセス制御を規定し、かつ／またはセキュリティ属性を変更してもよいことが理解されるであろう。
【００２２】
また、本発明によれば、高信頼性コンピューティングプラットフォームと、１つまたは複数の論理的被保護コンピューティング環境と、複数のファイルおよび上記ファイル間のアクセスパスを規定するリンクを備えるファイルシステムとを有するシステムに所定のセキュリティポリシを適用する方法であって、上記セキュリティポリシは、論理的被保護コンピューティング環境および／または上記ファイルの１つまたは複数に関する複数のセキュリティルールを含み、指定されたファイルまたはファイルの集合に第１および第２セキュリティルールが適用されることを決定するステップと、上記第１および第２セキュリティルールのそれぞれが適用されるファイルの完全な集合（ファイル集合）を判定するステップと、上記第１セキュリティルールのファイル集合が上記第２セキュリティルールのファイル集合の完全部分集合であるかどうかを判定するステップと、完全部分集合である場合、上記第１セキュリティルールを上記指定されたファイルまたはファイルの集合に適用するステップと、完全部分集合でない場合、上記第１および第２セキュリティルールの一方をそれらの別の属性に基づいて選択し、選択されたセキュリティルールを上記指定されたファイルまたはファイルの集合に適用するステップとを含む、セキュリティポリシを適用する方法が提供される。
【００２３】
このように、本発明の方法および装置は、もっぱら上記の「最も特定的なルール」という概念に基づいてルール衝突を解決しようとするのではなく、まず、衝突しているルールのうちの一方が適用されようとしているファイルシステムが、他方のセキュリティルールが適用されようとしているファイルシステムの完全部分集合であるかどうかを判定し、そうである場合、そのルールを、アクセスされた指定されたファイルまたはファイルの集合に適用する。
この判定の結果が、衝突しているルールのいずれも他方の完全部分集合であるファイルシステム（すなわち「スコープ」）を持たないという判定である場合に限り、衝突は別の方法を用いて解決される。
ファイルルールが衝突する場合、２つのルールのいずれのほうが限定的であるかを判定し、そのルールを適用することによって、衝突を解決してもよい。
実行制御（すなわちｅｘｅｃ）ルールの場合、セキュリティポリシに一番最近に追加されたルールを選択し適用することによって、衝突を解決してもよい。
この場合には少なくとも、システムは、好ましくは、ルール衝突が存在することをユーザに知らせる警告またはエラーメッセージを提供するように構成される。
【００２４】
本発明の一実施形態では、システムは、ファイルまたはファイルの集合の間のリンクが作成される時にルール衝突の生成を識別し、それに従ってエラーメッセージまたは警告を提供する手段を含んでもよい。
システムは、不正なリンクを削除して衝突を除去するように構成されてもよい。
【００２５】
ここで、本発明の一実施形態が、一例として添付図面を参照して以下に説明される。
【発明を実施するための最良の形態】
【００２６】
［発明の詳細な説明］
以下の説明では、本発明の十分な理解を提供するために数多くの具体的詳細が記載される。
しかし、当業者には明らかなように、本発明はこれらの具体的詳細に限定されることなく実施されてもよい。
他の場合、既知の方法および構造は、本発明を不必要に分かりにくくすることがないように、詳細には記載されていない。
【００２７】
本発明の一実施形態を実行するのに一般的に好適なタイプの高信頼性コンピューティングプラットフォームが、２０００年２月１５日に出願された「Trusted Computing Platform」と題する本出願人の国際特許出願ＰＣＴ／ＧＢ００／００５２８に詳細に記載されており、その内容は参照により本明細書に援用される。
この文書には、高信頼性コンピューティングプラットフォームの構成の本質的要素、およびコンピューティングプラットフォームの状態を当該プラットフォームのユーザに知らせる完全性メトリックを提供する際のその役割、ならびに当該メトリックをユーザに通信することが記載されている。
【００２８】
簡単に述べれば、図面の図１を参照すると、高信頼性コンピューティングプラットフォーム１０は、キーボード１４、マウス１６および視覚表示装置（ＶＤＵ）１８の標準的機能を含み、これらはプラットフォームの物理的な「ユーザインタフェース」を提供する。
高信頼性プラットフォームのこの実施形態はスマートカードリーダ１２も含むが、これは本発明のすべての実施形態に必須ではない。
スマートカードリーダ１２のそばに、高信頼性プラットフォームとの高信頼性ユーザ対話を可能にするスマートカード１９が図示されている（この態様は、２０００年３月３日に出願された「Smartcard User Interface for Trusted Computing Platform」と題する本出願人の国際特許出願ＰＣＴ／ＧＢ００／００７５１にさらに記載されており、その出願の内容は参照により本明細書に援用される）。
プラットフォーム１０には複数のモジュール１５がある。
これらは、当該プラットフォームに適した、実質的に任意の種類の高信頼性プラットフォームの他の機能要素である（このような要素の機能的意味は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない）。
【００２９】
図面の図２を参照すると、高信頼性コンピューティングプラットフォーム１０のマザーボード２０は、（標準的なコンポーネントのうちでも特に）メインプロセッサ２１、メインメモリ２２、高信頼性デバイス２４、データバス２６ならびにそれぞれの制御ライン２７およびアドレスライン２８、プラットフォーム１０のためのＢＩＯＳプログラム（これは、リセット後に、その内部でオペレーティングシステムプログラムが実行されることになる適切な環境を構築する）を含むＢＩＯＳメモリ２９、ならびに入出力（Ｉ／Ｏ）デバイス２３を含む。
Ｉ／Ｏデバイス２３は、マザーボードのコンポーネントと、スマートカードリーダ１２、キーボード１４、マウス１６およびＶＤＵ１８との間の対話を制御する。
【００３０】
メインメモリ２２は通常、ランダムアクセスメモリ（ＲＡＭ）である。
動作において、プラットフォーム１０は、ハードディスク（図示せず）からＲＡＭにオペレーティングシステムをロードする。
【００３１】
そこで、リセット後、メインプロセッサは最初に、高信頼性デバイスによって制御される。
すると、高信頼性デバイスは、プラットフォーム固有のＢＩＯＳプログラムに制御を渡し、このＢＩＯＳプログラムが通常通りすべての入出力デバイスを初期化する。
ＢＩＯＳプログラムが実行された後、制御はオペレーティングシステムプログラムに渡される。
オペレーティングシステムプログラムは通常、ハードディスクドライブ（図示せず）からメインメモリ２２にロードされる。
ＢＩＯＳブートブロックが高信頼性デバイス２４内に含まれることが強く望まれる。
これは、完全性メトリックの取得の妨害（これは不正なソフトウェアプロセスが存在する場合に起こり得る）を防ぐとともに、ＢＩＯＳ（たとえ正しくても）がオペレーティングシステムのための適切な環境を構築できない状況を不正なソフトウェアプロセスが作り出すことを防ぐ。
【００３２】
高信頼性デバイス２４の構成は、本出願人による前述の国際特許出願ＰＣＴ／ＧＢ００／００５２８にさらに詳細に記載されている。
高信頼性デバイスの具体的構成は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない。
【００３３】
高信頼性コンピューティングプラットフォームは、いったん起動された後は、コンパートメント化すなわち高信頼性オペレーティングシステムを有することになる。
つまり、オペレーティングシステムによってサポートされる必要のある１つまたは複数のサービスまたはプロセスが、論理的被保護コンピューティング環境であるコンパートメント内で実行される。
既に述べたように、コンパートメント内でのアクションまたは特権は、特に、コンパートメントの外部に効果を有するメソッドおよびオペレーション（例えば、ネットワークアクセスやコンパートメントの外部のファイルへのアクセスを要求するメソッド）を実行するプロセスの能力を制限するように（セキュリティポリシによって）制約される。
さらに、コンパートメント内のプロセスのオペレーションは、外部の影響による干渉およびのぞき見から高度に隔離されて実行される。
【００３４】
好ましい一実施形態では、コンパートメントは、オペレーティングシステムカーネルによって制御されるオペレーティングシステムコンパートメントであり、既に述べたように、これは、コンパートメント化オペレーティングシステムまたは高信頼性オペレーティングシステムとも呼ばれる。
【００３５】
コンパートメントとネットワークリソースの間の通信は、ＴＣＰ／ＵＤＰのようなトランスポートメカニズムへの狭いカーネルレベル制御のインタフェースを通じて行われる。
これらの通信インタフェースへのアクセスは、コンパートメントごとに指定されたルールによって統制される。
カーネル内の適当なポイントで、例えばどのコンパートメントがどのコンパートメントのリソースにアクセスすることが許容されるかを示すルールのテーブルを参照する動的ロード可能セキュリティモジュールへのフックを用いることにより、アクセス制御チェックが実行される。
コンパートメント間アクセスが行われることを明示的に許容するルールがない場合、アクセス試行はカーネルによって拒否される。
ルールは、別のコンパートメントのリソースにアクセスすることが明示的に許容されたコンパートメントを除いて、個別のコンパートメント間の強制的セグメンテーションを実施する。
【００３６】
以下では、２種類のファイルセキュリティルールが言及される。
すなわち、
・ファイルルール。
これは、通常の任意的アクセス制御（ＤＡＣ）に加えて強制的アクセス制御（ＭＡＣ）を規定する。
・ｅｘｅｃルール。
これは、プログラムが実行される時にプロセスのセキュリティ属性を変更する方法を規定する。
【００３７】
本発明の例示的な一実施形態の以下の詳細な説明では、ファイルルールは、どのコンパートメントにルールが適用されるかを規定するｃｏｍｐフィールドと、ルールが適用されるディレクトリまたはファイルを規定するｆｉｌｅｎａｍｅフィールドを有する。
ファイルルールによって許可されるアクセスは、そのａｃｃｅｓｓフィールドによって規定される。
一般的に、ディレクトリに対するファイルルールは、そのディレクトリおよびそのディレクトリから到達可能な全ファイルに適用される。
【００３８】
本発明のこの例示的実施形態では、ｅｘｅｃルールは、フィールドのうちでも特に、どのコンパートメントにルールが適用されるかを規定するｆｒｏｍ．ｃｏｍｐフィールドと、ルールが適用されるディレクトリまたはファイルを規定するｆｉｌｅｎａｍｅフィールドを有する。
一般的に、ディレクトリに対するｅｘｅｃルールは、そのディレクトリおよびそのディレクトリから到達可能な全ファイルに適用される。
【００３９】
以下では、「ルール」という一般的用語は、ファイルルールまたはｅｘｅｃルールを意味するために使用され、すべてのルールはコンパートメントフィールド（ファイルルールでは「ｃｏｍｐ」フィールド、ｅｘｅｃルールでは「ｆｒｏｍ．ｃｏｍｐ」フィールド）およびｆｉｌｅｎａｍｅフィールドを有し、他のすべてのフィールドは属性として「ひとまとめにされている」と仮定する。
【００４０】
本発明のこの例示的実施形態の目的は：
・ファイル名への依存を排除すること、
・ルール順序の関連性を排除すること、
・リンキング攻撃を排除すること、
および、これらの目的を果たすように、ルールの集合によってファイルに付与される属性を規定することである。
【００４１】
一般的に、ルールｒがファイル名／ｘを有する場合、そのルールのスコープｒは、／ｘから到達可能な全ファイルである。
これは、／ｘがディレクトリである場合には／ｘのすべての子孫を含み、さらにマウントポイントを渡ることによってアクセス可能な全ファイルを含む。
【００４２】
上記で言及された用語「シンボリックリンク」は、ファイルまたはプログラムを、複数のコピーを有することなく複数の場所に持つ必要がある場合に使用可能である。
例示的実施形態では、シンボリックリンクは下記を用いて設定することができる：
ln -s filename linkname
ここでｆｉｌｅｎａｍｅは実際のファイルまたはプログラムの名前であり、ｌｉｎｋｎａｍｅはリンクの名前である。
これが行われた後、「ｌｉｎｋｎａｍｅ」はｆｉｌｅｎａｍｅの代わりに使用可能であり、依然として正しいファイルに到達するであろう。
【００４３】
本発明のこの例示的実施形態では、ルール内のｆｉｌｅｎａｍｅフィールドがシンボリックリンクである場合、ルールは、そのリンクを解決することにより到達可能なあらゆるものに適用される。
ルール内のｆｉｌｅｎａｍｅがディレクトリである場合、そのディレクトリおよびすべてのサブディレクトリの内容が再帰的にそのスコープに含まれるが、シンボリックリンクは種々の理由からたどられない。
【００４４】
以下で、ルール集合Ｓによってコンパートメントｃ内のファイルｆに付与される属性が規定される。
【００４５】
記法：
Ｓ｜ｆ＝Ｓ内のルールのうちそのスコープ内にファイルｆを有するルールの集合
Ｓｃ＝Ｓ内のルールのうちコンパートメントｃを有するルールの集合
ＳＸ＝Ｓ内のｅｘｅｃルールの集合
ＳＦ＝Ｓ内のファイルルールの集合
【００４６】
ここで、そのスコープ内にｆを有し、コンパートメントｃに適用されるルール、すなわち集合Ｓｃ｜ｆを考える。
ＳｃＦ｜ｆがその中に１つのファイルルールｒを有する場合、結果は明白である。
すなわち、ｃ内のｆに対してＳによって規定されるパーミッションはｒ内のものである。
ＳｃＦ｜ｆが空である場合、いかなるファイルルールも適用されず、Ｐが付与される。
ここでＰは全パーミッションの集合である。
同様に、ＳｃＸ｜ｆがその中に１つのｅｘｅｃルールｒを有する場合、その属性はｒ内のものである。
ＳｃＸ｜ｆが空である場合、図面の図５に示す通り、いかなるｅｘｅｃルールも適用されず、ｆはｅｘｅｃ属性を持たない。
【００４７】
しかし、ＳｃＦ｜ｆまたはＳｃＸ｜ｆが複数のルールを含む場合、上記で言及したように、「最も特定的な」ルールという一般的概念を使用する必要がある。
あるファイルについて「最も特定的な」ルールを見つけるために提案されている１つの方法は、そのファイルのｉノードから出発して、ルールを有するｉノードが見つかるまでｄエントリ内の親チェインを上っていくことである。
あるｉノードに関連する複数の親チェインがある場合、最も近いｉノードに関連するルールが選択される。
しかし、例えば、関連するルールを有する最も近いｉノードから当該ｉノードまでが等しく近いような親チェインが２つある場合には、この手法は常に満足な結果を与えるとは限らない。
【００４８】
本発明によれば、どのルールをｉノードに適用するかについて決定する時にスコープ包含関係が評価されるような代替手法が使用される。
まず、「衝突」という用語を定義しよう。
ルールｒとｓが衝突するとは、図面の図６に示すように、それらの属性が等しくなく、両者のスコープ内にｓのファイル名を通らずにｒのファイル名から（またはその逆も同様）到達可能なファイルｆが存在する場合をいう。
ここでルールｒはノードｘで適用され、ルールｓはノードｗで適用される。
ファイルｆはｘからｚ経由でアクセス可能であるとともに、ｈからのハードリンクを通じてｗ経由でもアクセス可能である。
すなわち、ファイルｆはルールｒおよびｓの両方のスコープ内にあり、ｓのファイル名（ｗ）を通らずにｒのファイル名（ｘ）から到達可能であって、その逆も同様である。
このように、ルールｒとｓの属性が等しくない場合、ルールｒとｓの間に衝突があるという。
他方、ルールの集合において、その中のどのルールも衝突しない場合、そのルールの集合は無矛盾であるとみなし得る。
【００４９】
ここで、２つのルールが異なる属性を有する場合を考える。
図面の図７に示すように、それらのスコープが全く交わらない場合、それらは衝突しないので、無矛盾であるとみなすことができる。
しかし、２つのルールが異なる属性を有し、ファイルｆが両方のスコープ内に存在する場合には、それらのスコープが「ネスティング」していない限り、ルールは衝突するといえる。
「ネスティング」は次のように定義することができる：
【００５０】
ルールｒおよびｓがそれぞれファイルｘおよびｚというファイル名を含むとする。
ｓのスコープがｒのスコープ内にネスティングしているとは、ｓ？？ｒであり、かつｓ内のあらゆるファイルがｘからｚを通るパス上でのみ到達可能である場合であるということができる。
こうして、図面の図８を参照すると、ルールｓのスコープがルールｒのスコープ内にネスティングしていることがわかる。
その理由は、ｓはルールｒの完全部分集合であり、ルールｓのスコープ内のあらゆるファイルがファイル名ｘからファイル名ｚを通るパス上でのみ到達可能であるからである。
したがって、本発明のこの例示的実施形態によれば、ｓがｒよりも一般的でなく、ｓのスコープがｒのスコープ内にネスティングしている場合、ｓが最も特定的なルールとしてファイルｚに適用される。
しかし、図面の図６に示した例では、ｓのスコープはｒのスコープ内にネスティングしておらず、これらのスコープは交わっているので、ファイルｆに適用可能なルールを選択するためには別のルールを適用しなければならない。
本発明のこの例示的実施形態によれば、ファイルｆに適用されるべきルールは、ルールｒおよびｓのうち限定的なほうを選択することによって決定される。
【００５１】
そこで、図面の図９を参照すると、本発明のこの例示的実施形態による簡略化された方法は、ファイルｆが２つのルールｒおよびｓのスコープ内にあると判定された後、Ａから続行される。
ステップ１０で、ルールｒおよびｓのスコープを判定する。
ステップ１２で、ｒがｓの完全部分集合である（またはその逆）かどうかを判定する。
ＹＥＳである場合、ステップ１４で、スコープが他のルールの完全部分集合であるルールをファイルｆに適用する。
そうでない場合、ステップ１６で、２つのルールのいずれのほうが限定的であるかを判定し、ステップ１８で、限定的なほうのルールをファイルｆに適用する。
各ルールのスコープが判定される時、ルールのパス自体がシンボリックリンクを表すのでない限り、シンボリックリンクはたどらないのが好ましい。
【００５２】
上記のプロセスは、前に説明したリンクに関連する問題を回避している。
しかし、リンクは一般にパーミッションを広げることは決してできないが、交わりをとることによってそれを狭めることはできる。
本発明の一実施形態によれば、この問題に対する解決法として、ルール衝突を生成するリンクの作成を検出し、その作成を防止するかまたはそれを削除する手段を提供することにより、オペレーションの失敗を引き起こすことがある。
別法として、ファイルまたはファイルの集合の間のリンクが作成される時にルール衝突の生成を識別し、それに従ってエラーメッセージまたは警告を提供する手段を提供することも可能である。
【００５３】
ｅｘｅｃルールは、パーミッションだけではなくプロパティを設定する。
ファイルルールと同様、ｅｘｅｃルールｓがｅｘｅｃルールｒに比べて「より特定的」であるとは、ｒおよびｓが同じコンパートメントを有し、ｓのファイル集合がｒのファイル集合の真部分集合である場合をいう。
しかし、それらのルールが交わりのあるファイル集合を有するが、いずれのファイル集合も他方の真部分集合でない場合、ルールは衝突しているという。
したがって、例えば、ｒおよびｓが潜在的にノードｆに適用され、ｒが「コンパートメントｘを使用する」と言明し、ｓが「コンパートメントｙを使用する」と言明している場合、解決すべき非常に明確な衝突がある。
本発明の例示的な一実施形態によれば、最新の追加されたルール（最新追加ルール）を、ノードｆに適用されるべきとして選択する。
また、衝突についてユーザに警告するためにエラーメッセージを出してもよい。
これを解決するためには、警告時に、ユーザは、ノードｆに特に適用されるべき別のルールｔを規定するだけでもよい。
その場合、このルールはルールｒおよびｓの両方に優先する。
【００５４】
このように、上記の実施形態の装置および方法は、ノードがどのようにアクセスされるか、あるいはルールがどのような順序でロードされるかに関わらず、最も好ましくは上記の最も特定的なルール／最新追加ルールの判定を用いて、ルールがノードに適用されるかどうかを高い信頼性で判定する。
また、どのルールが現在ノードに適用されているかを、その名前に関わらず、正確に追跡することも提供する。
【００５５】
ファイルルールがどのファイルに適用されるかの正しい認識を維持するため、ファイル名前空間を変更するオペレーション、すなわち、ファイル作成、ファイル名変更、リンク作成、リンク削除、マウント、アンマウントを監視してもよい。
【００５６】
以上、本発明の一実施形態を単なる例として説明したが、当業者には明らかなように、添付の請求項によって規定される本発明の範囲から逸脱することなく、記載した実施形態に対して変更および変形を行うことが可能である。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施形態を実施することが可能なシステムを示す図である。
【図２】スマートカードリーダおよびモジュール群と通信するように構成された高信頼性デバイスを含むマザーボードである。
【図３】簡略化されたファイルシステムを示す概略図である。
【図４】もう１つの簡略化されたファイルシステムを示す概略図である。
【図５】本発明の一実施形態による、ルールをノードに適用する方法の一部を示す流れ図である。
【図６】２つのルールが衝突している簡略化されたファイルシステムを示す概略図である。
【図７】２つのルールが衝突していない簡略化されたファイルシステムを示す概略図である。
【図８】１つのルールがもう１つのルールの完全部分集合である簡略化されたファイルシステムを示す概略図である。
【図９】図５の方法のもう１つの部分を示す流れ図である。
【符号の説明】
【００５８】
１０・・・高信頼性コンピューティングプラットフォーム、
１４・・・キーボード、
１５・・・モジュール、
１６・・・マウス、
１８・・・視覚表示装置（ＶＤＵ）、
１２・・・スマートカードリーダ、
１９・・・スマートカード、
２０・・・マザーボード、
２１・・・メインプロセッサ、
２２・・・メインメモリ、
２３・・・I／Ｏデバイス、
２４・・・高信頼性デバイス、
２６・・・データバス、
２７・・・制御ライン、
２８・・・アドレスライン、
２９・・・ＢＩＯＳメモリ、
【図１】
2004303243.tif 000003
【図２】
2004303243.tif 000004
【図３】
2004303243.tif 000005
【図４】
2004303243.tif 000006
【図５】
2004303243.tif 000007
【図６】
2004303243.tif 000008
【図７】
2004303243.tif 000009
【図８】
2004303243.tif 000010
【図９】
2004303243.tif 000011
【外国語明細書】
Security Attributes of Nodes in Trusted Computing Systems
Field of the Invention
This invention relates generally to the security policy employed in trusted computing systems and, more particularly, to a method and apparatus for defining security attributes in respect of access capabilities of files and permitted access to system resources in trusted computing systems.
Background to the Invention
For commercial applications, a client computing platform typically operates in an environment where its behaviour is vulnerable to modification by local or remote entities. This potential insecurity of the platform is a limitation on its use by local parties who might otherwise be willing to use the platform, or remote parties who might otherwise communicate with the platform; for example, for the purposes of E-commerce.
In the applicant's co-pending disclosure WO 00/48063, incorporated herein by reference, there is disclosed the concept of a 'trusted computing platform' comprising a computing platform which has a 'trusted component' in the form of a built-in hardware and software component. This document describes the use of a Trusted Device (TD) or Trusted Platform Module (TPM) to enable verification of the integrity of computing apparatus by the reliable measurement and reporting of integrity metrics. A TD/TPM conforms to the Trusted Computing Platform Alliance (TCPA) specification, see for example www.trustedpc.org.
A Trusted Device or Trusted Platform Module may include one or more logically protected computing environments or "compartments" within which a service or process may be run. The actions or privileges within a compartment are constrained , particularly to restrict the ability of a process to execute methods and operations which have effect outside the compartment, such as methods that request network access or access to files outside of the compartment. Also, operation of a process or service within a compartment is performed with a high level of isolation from interference and prying by outside influences. The or each compartment may be an operating system compartment controlled by an operating system kernel. This is also referred to as a compartmented operating system or a trusted operating system.
Trusted operating systems have been available for several years in a form designed for handling and processing classified (military) information, using a containment mechanism enforced by a kernel of the operating system with mandatory access controls to resources of the computing platform such as files, processes and network connections. The operating system attaches labels to the resources and enforces a security policy which governs the allowed interaction between these resources based on their label values. Many trusted operating systems apply a security policy based on the Bell-Lapadula model discussed in the paper "Applying Military Grade Security to the Internet" by C I Dalton and J F Griffin published in Computer Networks and ISDN Systems 29 (1997) 1799 - 1808.
In any event, many trusted computing platforms adopt a relatively simple and convenient form of operating system compartment. As a general rule, each resource of the computing platform which it is desired to protect is given a label indicating the compartment to which that resource belongs. Mandatory access controls, incorporating a security policy, are performed by the kernel of the host operating system to ensure that resources from one compartment cannot interfere with resources from another compartment. In a secure system, access to system resources is defined by security or subject attributes.
The above-mentioned security policy tends to be expressed in the form of security rules (each generally comprising an instruction line defining security attributes). In general, one or more security rules are associated with a compartment, and each compartment may be associated with one or more services. File rules may be used to define mandatory access controls in addition to the usual discretionary access control. In general, a file rule has a comp field defining which compartment the rule applies to, and a filename field defining the directory or file the rule applies to. File rules on a directory apply to the directory and all files reachable from the directory. The access permitted by a file rule is defined by its access field.
The forms of access, in one known system, are read, write, append, execute. For most file operations, the operation is only permitted if the access requested by the operation is granted by the applicable file rules, or there are no applying file rules.
Consider the case where a website under /compt/web(NOTE: underlined letters in the sentences are in italic) is running in compartment web. To prevent the website being defaced, a read-only rule may be put on /compt/web:
file [ comp web; filename /comp/web; access read; ]
However, the webserver may need to write logs, so read-write access may be given to /compt/web/logs:
file [ comp web; filename /comp/web/logs; access read, write ]
The intention is that a file rule defines the maximum permission of files reachable from itsfilename. In some conventional systems, where a file is reachable from the filename in more than one rule, the "most specific" rule is used, i.e. the one with the longest filename. If there is no rule applying to a file, its permissions are not constrained, and the usual permissions specified on the file control operations on it. Rules for different compartments tend to be treated independently.
However, this definition of the behaviour has been found to be inadequate. In some known systems, the filesystem maps filenames onto the files themselves, which are identified uniquely by device number and inode number. Many filnames can resolve to the same file because of the presence of hard links, symbolic links, multiple mounts and mounts using -bind to mount one directory on another. This may be called 'filename aliasing', and it means that it is not always clear when more than one rule applies to a file, or indeed if any rule applies to a file. In addition, there is also the problem of rule conflict, in the sense that filename aliasing means that two rules with different filenames can have some files to which only one rule applies, and some files to which both rules potentially apply.
Referring to Figure 3 of the drawings, consider the following file rule r1:
file [comp web; filename /x; access read;]
Thus, if a user were to try and write to a file /x/f from compartment web, it will fail with operation not permitted (because directory x has read-only access defined by r1, which also applies to /x/f). However, consider the case that another directory /y also exists, to which rule r2 applies:
file [comp web; filename /y; access read, write]
A user could create a hard link to /x/f called /y/f because they have write access to /y and only need read access to /x/f to create the link. Thus, if filename /y/f is accessed, this will resolve to the same inode 100 as /x/f, but the kernel dentry will show /y as the parent and will apply r2 even though r1 should be applied, without knowing that /y/f is an alias for a file /x/f. On the other hand, if /y/f were a symbolic link to /x/f, the kernel dentry for the inode 100 has /x as the parent and r1 would be correctly applied.
On the other hand, referring to Figure 4 of the drawings, suppose a symbolic link /x/y is provided to /y. Then the filename /x/y/f resolves to the same file inode 100 as y/f, so on the face of it r1 should apply to /x/y/f . However, the kernel would resolve /x/y/f to a dentry for /y/f, since /x/y is a symbolic link.
File aliases can also be produced by mounting the same filesystem on more than one directory. Although hard-linking to a directory can be prevented, a similar effect can be produced in one known system using a 'mount-bind' command which allows a directory to be mounted on any other directory, effectively linking the mount point to the directory mounted.
Websites can be defaced by attackers using buffer overflow bugs in the webserver to get it to run their code and write to the website files. The exemplary website rules given above are intended to prevent this, even if the webserver has a buffer overflow bug. However, they do not effectively achieve this in all cases, unless the issue of filename aliasing is resolved. Otherwise, an attacker can cause the webserver to create a hard link in /compt/web/logs (which has read-write access) to file under /compt/web (which only has read access). The attacker can then access the file via the hard link, by-passing the read-only protection, so the rules do not necessarily prevent the website being defaced, unless the issue of filename aliasing is resolved.
Furthermore, in some known systems, a security policy is used which classifies files into types and then defines the access permitted on the basis of the types. Classification is done as a separate phase and the results are stored. Files are not reclassified when they are renamed, or when links to them are created, and the classification process must instead be run manually when the policy is changed. This is clearly inconvenient and time-consuming, not to mention complicated and prone to error.
Summary of the Invention
Thus, in accordance with the present invention, there is provided a system comprising a trusted computing platform, one or more logically protected computing environments and a filesystem comprising a plurality of files and links defining access paths between said files, the system being arranged to load onto said trusted computing platform a predetermined security policy including a plurality of security rules in respect of one or more of said logically protected computing environments and/or said files, the system being further arranged to determine that first and second security rules apply to a specified file or set of files, determine the complete set of files (or fileset) to which each of said first and second security rules applies, determine if the fileset of said first security rule is a complete subset of the fileset of said second security rule, and if so, apply said first security rule to said specified file or set of files, and otherwise, select one of said first and second security rules on the basis of another attribute thereof, and apply the selected security rule to said specified file or set of files.
It will be appreciated that the security rules may define access controls and/or modify security attributes, as explained in more detail later.
Also in accordance with the present invention, there is provided a method of applying a predetermined security policy to a system having a trusted computing platform, one or more logically protected computing environments and a filesystem comprising a plurality of files and links defining access paths between said files, said security policy including a plurality of security rules in respect of one or more of logically protected computing environments and/or said files, the method comprising the steps of determining that first and second security rules apply to a specified file or set of files, determining the complete set of files (or fileset) to which each of said first and second security rules applies, determining if the fileset of said first security rule is a complete subset of the fileset of said second security rule, and if so, applying said first security rule to said specified file or set of files, and otherwise, selecting one of said first and second security rules on the basis of another attribute thereof, and applying the selected security rule to said specified file or set of files.
Thus, instead of trying to resolve a rule conflict entirely on the basis of the 'most specific rule' concept described above, the method and apparatus of the invention first determine if the filesystem to which one of the conflicting rules is intended to apply is a complete subset of the filesystem to which the other security rule is intended to apply, and if so, apply that rule to the specified file or set of files which has been accessed. Only if the result of this determination is that neither of the conflicting rules has a filesystem (or 'scope') which is a complete subset of the other, is the conflict resolved using another method. In the case of conflicting file rules, the conflict may be resolved by determining which of the two rules is the most restrictive, and applying that rule. In the case of execution control (or exec) rules, the conflict may be resolved by selecting and applying the rule which was most recently added to the security policy. In this case at least, the system is preferably arranged to provide a warning or error message indicating to a user that a rule conflict exists.
In one embodiment of the invention, the system may include means for identifying the creation of a rule conflict when a link between files or sets of files is created, and providing an error message or warning accordingly. The system may also be arranged to remove the offending link to remove the conflict.
Brief Description of the Drawings
An embodiment of the present invention will now be described by way of example only and with reference to the accompanying drawings, in which:
Figure 1 is a diagram that illustrates a system capable of implementing embodiments of the present invention;
Figure 2 is a motherboard including a trusted device arranged to communicate with a smart card reader and with a group of modules;
Figure 3 is a schematic diagram illustrating a simplified filesystem;
Figure 4 is a schematic diagram illustrating another simplified filesystem;
Figure 5 is a flow diagram illustrating a portion of a method of applying rules to nodes, according to an exemplary embodiment of the invention;
Figure 6 is a schematic diagram illustrating a simplified filesystem in which two rules conflict;
Figure 7 is a schematic diagram illustrating a simplified filesystem in which two rules do not conflict;
Figure 8 is a schematic diagram illustrating a simplified filesystem in which one rule is a complete subset of another rule; and
Figure 9 is a flow diagram illustrating another portion of the method of Figure 5.
Detailed Description of the Invention
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the invention may be practised without limitation to these specific details. In other instances, well known methods and structures have not been described in detail so as to avoid unnecessarily obscuring the present invention.
A trusted computing platform of a type generally suitable for carrying out an embodiment of the present invention is described in detail in the applicant's International Patent Application No. PCT/GB00/00528 entitled 'Trusted Computing Platform' and filed on 15th February 2000, the contents of which are incorporated herein by reference. This document describes the essential elements of the construction of a trusted computing platform, and its role in providing integrity metrics indicating the state of the computing platform to a user of that platform, and communication of such metrics to a user.
Briefly, and referring to Figure 1 of the drawings, a trusted computing platform 10 includes the standard features of a keyboard 14, a mouse 16 and a visual display unit (VDU) 18, which provide the physical 'user interface' of the platform. This embodiment of a trusted platform also contains a smart card reader 12, although this is not essential in all embodiments of the present invention. Alongside the smart card reader 12, there is illustrated a smart card 19 to allow trusted user interaction with the trusted platform (this aspect is further described in the applicant's International Patent Application No. PCT/GB00/00751 entitled "Smartcard User Interface for Trusted Computing Platform" and filed on 3rd March 2000, the contents of which application are incorporated herein by reference). In the platform 10, there are a plurality of modules 15: these are other functional elements of the trusted platform of essentially any kind appropriate to that platform (the functional significance of such elements is not relevant to the present invention and will not be discussed further herein).
Referring to Figure 2 of the drawings, the motherboard 20 of the trusted computing platform 10 includes (among other standard components) a main processor 21, main memory 22, a trusted device 24, a data bus 26 and respective control lines 27 and address lines 28, BIOS memory 29 containing the BIOS program (which, after reset, builds a proper environment within which the operating system program will be run) for the platform 10, and an input/output (I/O) devices 23, which controls interaction between the components of the motherboard and the smart card reader 12, the keyboard 14, the mouse 16 and the VDU 18.
The main memory 22 is typically random access memory (RAM). In operation, the platform 10 loads the operating system into RAM from hard disk (not shown).
Thus, after reset, the main processor is initially controlled by the trusted device, which then hands control over to the platform-specific BIOS program, which in turn initialises all input/output devices as normal. After the BIOS program has executed, control is handed over to an operating system program, which is typically loaded into the main memory 22 from a hard disk drive (not shown). It is highly desirable for the BIOS boot block to be contained within the trusted device 24. This prevents subversion of the obtaining of the integrity metric (which could otherwise occur if rogue software processes are present) and prevents rogue software processes creating a situation in which the BIOS (even if correct) fails to build a proper environment for the operating system.
The structure of the trusted device 24 is described in more detail in the applicant's abovementioned International Patent Application No. PCT/GB00/00528. The specific structure of the trusted device is not relevant to the present invention and will not be discussed further herein.
A trusted computing platform, once started up, tends to have a compartmented or trusted operating system. This means that one or more services or processes required to be supported by the operating system are run within a compartment which is a logically protected computing environment. As stated above, the actions or privileges within a compartment are constrained (by the security policy), particularly to restrict the ability of a process to execute methods and operations which have effect outside the compartment, such as methods that request network access or access to files outside of the compartment. In addition, operation of the process within the compartment is performed with a high level of isolation from interference and prying by outside influences.
In a preferred embodiment, the compartment is an operating system compartment controlled by the operating system kernel and, as stated above, this is also referred to as a compartmented operating system or a trusted operating system.
Communication between compartments and network resources is provided via narrow kernel level controlled interfaces to a transport mechanism such as TCP/UDP. Access to these communication interfaces is governed by rules specified on a compartment by compartment basis. At appropriate points in the kernel, access control checks are performed such as through the use of hooks to a dynamically loadable security module that consults a table of rules indicating which compartments are allowed to access the resources of another compartment. In the absence of a rule explicitly allowing a cross compartment access to take place, an access attempt is denied by the kernel. The rules enforce mandatory segmentation across individual compartments, except for those compartments that have been explicitly allowed to access another compartment's resources.
In the following, two types of file security rules will be referred to, namely
・      file rules defining mandatory access controls (MAC) in addition to normal discretionary access control (DAC); and
・      exec rules defining how to modify the security attributes of a process when programs are executed.
In the following specific description of an exemplary embodiment of the invention, a file rule has a comp field defining which compartment the rule applies to, and a filename field defining the directory or file the rule applies to. The access permitted by a file rule is defined by its access field. In general, file rules on a directory apply to the directory and all files reachable from that directory.
In this exemplary embodiment of the invention, an exec rule has, among other fields, a from.comp field defining which compartment the rule applies to and a filename field defining the directory or file the rule applies to. In general, exec rules on a directory apply to the directory and all files reachable from that directory.
In the following, the general term 'rule' will be used to mean file or exec rule, and it is assumed that all rules have compartment fields ('comp' field in a file rule, and 'from.comp' field in an exec rule) and filename fields, with all other fields being 'lumped' together as attributes.
The object of this exemplary embodiment of the invention is to:
・      eliminate any dependency on filename;
・      eliminate relevance of rule order;
・      eliminate linking attacks;
and to define the attributes conferred on a file by a set of rules in a way that satisfies these objects.
In general, if a rule r has filename /x, the rule's scope r is all files which are reachable from /x. This includes all descendants of /x if it is a directory, and all files which can be accessed by crossing mount points.
The term 'symbolic link', as referred to above, can be used if it is required to have a file or program in more than one place without having more than one copy. In exemplary embodiment, a symbolic link can be set up using:
ln -s filename linkname
where filename is the name of the real file or program and linkname is the name of the link. After this has been done, "linkname" can be used instead of filename, and the correct file will still be reached.
In this exemplary embodiment of the invention, if the filename field in a rule is a symbolic link, the rule applies to everything reachable by resolving the link. If the filename in a rule is a directory, the contents of the directory and all subdirectories is recursively included in its scope, but symbolic links are not followed for various reasons.
In the following, the attributes conferred on a file f in compartment c by rule set S are defined.
Notation:
S|f = the set of rules in S having file f in their scope;
Sc = the set of rules S having compartment c;
SX = the set of exec rules in S;
SF = the set of file rules in S.
Thus, consider the rules that have f in their scope and apply to compartment c, i.e. the set Sc|f .If ScF|f has one file rule r in it, then the result is obvious: the permissions defined by S for f in c are those in r. If ScF|f is empty, no file rules apply, and P is conferred, where P is the set of allpermissions. Similarly, if ScX|f has one exec rule r in it, the attributes are those in r. If ScX|f is empty, no exec rules apply, and f has no exec attributes, as illustrated in Figure 5 of the drawings.
However, in the case where ScF|f or ScX|f contains more than one rule, it is necessary to employ the general concept of "most specific" rule, as mentioned above. One way which has been proposed to find the 'most specific' rule for a file, is to start at the file's inode and go up to the parent chain in the dentry until an inode with a rule is found. If there is more than one parent
chain associated with an inode, the rule associated with nearest inode is selected. However, this approach does not always provide satisfactory results, for example, in the case where there are two parent chains in which the nearest inodes having rules associated with them are equally close to the inode of interest.
In accordance with the present invention, an alternative approach is employed, in which scope inclusion is assessed when deciding on which rule to apply to an inode. Firstly, let us define the term 'conflict'. Rules r and s conflict if their attributes are not equal and there exists a file f in both their scopes reachable from r's filename without passing through s's filename (or vice versa), as illustrated in Figure 6 of the drawings, in which rule r is applied at node x and rule s is applied at node w. File f is accessible from x via z, and also via w via a hard link from h, i.e. file f is in the scope of both rules r and s, and is reachable from r's filename (x) without passing through s's filename (w), and vice versa. Thus, if the attributes of rules r and s are not equal, there is said to be a conflict between rules r and s. On the other hand, a set of rules may be considered consistent if no rules in it conflict.
Now consider the case where two rules have differing attributes. If their scope does not intersect at all, as shown in Figure 7 of the drawings, then they can be considered to be consistent, as they do not conflict. However, if the two rules have differing attributes, and file f exists in both of their scopes, the rules are said conflict unless the scopes 'nest'. 'Nesting' can be defined, as follows:
Given rules r and s, with filename files x and z respectively, it can be said that the scope of s nests in the scope of r if s ??r and every file in s is only reachable from x on a path through z. Thus, referring to Figure 8 of the drawings, it can be seen that the scope of rule s nests in the scope of rule r because s is a complete subset of rule r and every file in the scope of rule s is only reachable from filename x on a path through filename z. Thus, in accordance with this exemplary embodiment of the invention, if s is less general than r, and the scope of s nests in the scope of r, then s is applied to file z as the most specific rule. However, in the example illustrated in Figure 6 of the drawings, the scope of s does not nest in the scope of r, but the scopes do intersect, another rule must be applied to select the rule applicable to file f. In accordance with this exemplary embodiment of the invention, the rule to be applied to file f is determined by selecting the most restrictive of rules r and s.
Thus, referring to Figure 9 of the drawings, a simplified method according to this exemplary embodiment of the invention continues from A, after it has been determined that the file f lies within the scope of two rules r and s. At step 10, the scope of rules r and s is determined. At step 12, it is determined whether r is a complete subset of s (or vice versa). If yes, the rule whose scope is a complete subset of the other rule is applied to file f at step 14. Otherwise, it is determined at step 16 which of the two rules is most restrictive, and the most restrictive rule is applied to file f at step 18. It is preferred that, when the scope of each rule is determined, symbolic links are not followed unless the rule's path itself denotes a symbolic link.
The above-described process avoids the problems associated with links, as explained above. However, although a link can generally never widen permissions, it can narrow them, by causing intersection. In accordance with one embodiment of the invention, a solution to this problem would be to provide means for detecting the creation of a link which creates a rule conflict and either preventing its creation or removing it, thereby causing a failed operation. Alternatively, means could be provided for identifying the creation of a rule conflict when a link between files or sets of files is created, and providing an error message or warning accordingly.
Exec rules set properties rather than just permissions. As with file rules, exec rule s is 'more specific' than exec rule r if r and s have the same compartment and the fileset of s is a proper subset of the fileset of r. However, if the rules have intersecting filesets, but neither fileset is a proper subset of the other, the rules are said conflict. Thus, for example, if r and s potentiallyapply to node f, and r states 'use compartment x' and s states 'use compartment y', there is a very clear conflict to be resolved. In accordance with an exemplary embodiment of the invention, the last-added rule is chosen to be applied to node f, and an error message may be raised to warn a user of the conflict. In order to resolve this, once alerted, the user may simply define another rule t to be applied specifically to node f, which rule would then take precedence over both rules r and s.
Thus, the apparatus and method of the illustrated embodiment reliably determines whether a rule applies to a node, irrespective of which way that node is accessed or the order in which the rules are loaded, using most preferably, the above-described most specific/last added rule determination. It also provides for accurate tracking of what rule currently applies to a node, irrespective of its name.
In order to maintain a correct view of which file rules apply to which files, operations modifying the file namespace may be monitored, i.e.. File create, file rename, link create, link delete, mount, unmount.
An embodiment of the present invention has been described above by way of example only, and it will be apparent to a person skilled in the art that modifications and variations can be made to the described embodiments without departing from the scope of the invention as defined by the appended claims.
1. A system comprising a trusted computing platform, one or more logically protected computing environments and a filesystem comprising a plurality of files and links defining access paths between said files, the system being arranged to load onto said trusted computing platform a predetermined security policy including a plurality of security rules in respect of one or more of said logically protected computing environments and/or said files, the system being further arranged to determine that first and second security rules apply to a specified file or set of files, determine the complete set of files (or fileset) to which each of said first and second security rules applies, determine if the fileset of said first security rule is a complete subset of the fileset of said second security rule, and if so, apply said first security rule to said specified file or set of files, and otherwise, select one of said first and second security rules on the basis of another attribute thereof, and apply the selected security rule to said specified file or set of files.
2. A system according to claim 1, wherein said security rules comprise or include a plurality of file rules defining discretionary access controls in respect of one or more of said logically protected computing environments and/or files.
3. A system according to claim 1 or claim 2, wherein said security rules comprise or include a plurality of execution control rules defining a modifying security attributes in respect of one or more of said logically protected computing environments and/or files.
4. A system according to claim 2, wherein in said first and second security rules are file rules, and the fileset to which said first security rule applies is not a complete subset of the fileset to which the second security rules applies, the system is arranged to determine which of the first and second security rules is the most restrictive, and apply that rule to said specified file or set of files.
5. A system according to claim 3, wherein if said first and second security rules are execution control rules and the fileset to which said first security rule applies is not a complete subset of the fileset to which said second security rule applies, the system is arranged to select and apply the rule which was most recently added to the security policy.
6. A system according to claim 5, arranged to provide a warning or error message indicating to a user that a rule conflict exists.
7. A system according to any one of the preceding claims, including means for identifying the creation of a rule conflict when a link between files or sets of files is created and providing an error message or warning accordingly.
8. A system according to claim 7, arranged to remove the offending link to remove the conflict.
9. A system substantially as herein described with reference to the accompanying drawings.
10. A method of applying a predetermined security policy to a system having trusted computing platform, one or more logically protected computing environments and a filesystem comprising a plurality of files and links defining access paths between said files, said security policy including a plurality of security rules in respect of one or more of logically protected computing environments and/or said files, the method comprising the steps of determining that first and second security rules apply to a specified file or set of files, determining the complete set of files (or fileset) to which each of said first and second security rules applies, determining if the fileset of said first security rule is a complete subset of the fileset of said second security rule, and if so, applying said first security rule to said specified file or set of files, and otherwise, selecting one of said first and second security rules on the basis of another attribute thereof, and applying the selected security rule to said specified file or set of files.
11. A method according to claim 10 wherein the security rules define access controls and/or modify security attributes.
12. A method of applying a predetermined security policy to a trusted computing platform, the method being substantially as herein described with reference to the accompanying drawings.
Security Attributes of Nodes in Trusted Computing Systems
A system and method for resolving a rule conflict within a security policy applied to a trusted computing platform, wherein the fileset to which each of the conflicting rules v and s refers (or "scope") is determined (step 10). It is then determined (at step 12) if the scope of one of the rules s is a complete subset of the scope of rule r. If so, rule s is applied to the accessed file f (at step 14). If not, the conflict is resolved in another way, for example, by determining the most restrictive of rules r and s (at step 16) and applying the result accordingly (step 18).
[Figure 9]
2004303243.tif 000012
2004303243.tif 000013
2004303243.tif 000014
2004303243.tif 000015
2004303243.tif 000016
2004303243.tif 000017
2004303243.tif 000018
2004303243.tif 000019
2004303243.tif 000020