(57)【要約】【課題】  １つまたは複数の論理的被保護コンピューティング環境を含む高信頼性コンピューティングプラットフォームを備えるシステムを提供する。【解決手段】  それぞれの論理的被保護コンピューティング環境は上記システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連する。システムは、それぞれの上記論理的被保護コンピューティング環境のオペレーションを制御する１つまたは複数のセキュリティルールを含む所定のセキュリティポリシを上記高信頼性コンピューティングプラットフォーム上にロードするように構成される。上記論理的被保護コンピューティング環境の少なくとも１つに対するセキュリティルールは、その論理的被保護コンピューティング環境に関連するサービスまたはプロセスが開始される時にそのサービスまたはプロセスに適用されるべきセキュリティ属性を規定する実行制御ルールを含む。【選択図】  図３
2004303242.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」）に記載されている。
【０００６】
いずれにしても、多くの高信頼性コンピューティングプラットフォームは、比較的簡便な形態のオペレーティングシステムコンパートメントを採用している。
一般的に、保護したいコンピューティングプラットフォームの各リソースに、そのリソースが属するコンパートメントを示すラベルが与えられる。
あるコンパートメントからのリソースが別のコンパートメントからのリソースと干渉しないようにするために、セキュリティポリシを組み込んだ強制的アクセス制御がホストオペレーティングシステムのカーネルにより実行される。
セキュアなシステムでは、システムリソースへのアクセスは、セキュリティまたはサブジェクト属性によって規定される。
【０００７】
上記のセキュリティポリシは、セキュリティルールの形態で表現されることが多い（各セキュリティルールは一般に、セキュリティ属性を規定する命令行を含む）。
一般的に、１つまたは複数のセキュリティルールが１つのコンパートメントに関連する。
また、各コンパートメントが１つまたは複数のサービスに関連してもよい。
【０００８】
従来、セキュリティルールは、プラットフォームの起動シーケンス中のできるだけ早いうちにロードし、サービスまたはプロセスが起動されたら直ちに関連するセキュリティルールが有効になるようにするのが望ましいと考えられている。
そこで、従来技術のシステムでは、すべてのセキュリティルールがシステム初期化時にプラットフォームにロードされることが多い。
すなわち、完全なセキュリティルールがシステム起動時にロードされる。
したがって、セキュリティ属性はセキュリティ初期化によって割り当てられることになり、特別の権限を有するプロセスによらなければ変更することができない。
【０００９】
セキュアなオペレーティングシステムでは、多くの場合（例えば、プロセスが別のプログラムをフォークして実行する時には、サービスがコンパートメントに入るためにセキュリティＩＤを必要とするので）、いくつかのポイントでプログラムのセキュリティ属性を変更する（すなわち「セキュリティ遷移」を実行する）ことが必要になる。
したがって、従来技術のシステムでは、サービスを開始する方法を変更して（すなわち、サービスを開始するスクリプト、制御プログラムまたは他のファシリティを変更して）、そのサービスが確実に正しいコンパートメントに入るようにするか、またはこの問題に対処するために何らかの形のマッピングファンクションを構成するかのいずれかが必要である。
【００１０】
すなわち、いくつかのポイントにおけるプログラムのセキュリティ属性の変更は、従来は、属性を変更するために特別のシステムコールを用いて、または高信頼性ゲートウェイプログラムを用いて、明示的になされているが、これは不便である。
というのは、これは、特別のシステムコールを含めるため、または必要とされるプログラムの代わりに高信頼性ゲートウェイプログラムを呼び出すために、呼出し側プログラムを（上記のように）変更することを伴うからである。
また、呼出し側プログラムが被呼出し側プログラムの属性を変更することを可能にする追加のセキュリティ属性を呼出し側プログラムに与えることも必要になることがある。
【非特許文献１】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」と題する本出願人の国際特許出願ＰＣＴ／ＧＢ００／００７５１にさらに記載されており、その出願の内容は参照により本明細書に援用される）。
プラットフォーム１０には複数のモジュール１５がある。
これらは、当該プラットフォームに適した、実質的に任意の種類の高信頼性プラットフォームの他の機能要素である（このような要素の機能的意味は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない）。
【００２６】
図面の図２を参照すると、高信頼性コンピューティングプラットフォーム１０のマザーボード２０は、（標準的なコンポーネントのうちでも特に）メインプロセッサ２１、メインメモリ２２、高信頼性デバイス２４、データバス２６ならびにそれぞれの制御ライン２７およびアドレスライン２８、プラットフォーム１０のためのＢＩＯＳプログラム（これは、リセット後に、その内部でオペレーティングシステムプログラムが実行されることになる適切な環境を構築する）を含むＢＩＯＳメモリ２９、ならびに入出力（Ｉ／Ｏ）デバイス２３を含む。
Ｉ／Ｏデバイス２３は、マザーボードのコンポーネントと、スマートカードリーダ１２、キーボード１４、マウス１６およびＶＤＵ１８との間の対話を制御する。
メインメモリ２２は通常、ランダムアクセスメモリ（ＲＡＭ）である。
動作において、プラットフォーム１０は、ハードディスク（図示せず）からＲＡＭにオペレーティングシステムをロードする。
【００２７】
そこで、リセット後、メインプロセッサは最初に、高信頼性デバイスによって制御される。
すると、高信頼性デバイスは、プラットフォーム固有のＢＩＯＳプログラムに制御を渡し、このＢＩＯＳプログラムが通常通りすべての入出力デバイスを初期化する。
ＢＩＯＳプログラムが実行された後、制御はオペレーティングシステムプログラムに渡される。
オペレーティングシステムプログラムは通常、ハードディスクドライブ（図示せず）からメインメモリ２２にロードされる。
ＢＩＯＳブートブロックが高信頼性デバイス２４内に含まれることが強く望まれる。
これは、完全性メトリックの取得の妨害（これは不正なソフトウェアプロセスが存在する場合に起こり得る）を防ぐとともに、ＢＩＯＳ（たとえ正しくても）がオペレーティングシステムのための適切な環境を構築できない状況を不正なソフトウェアプロセスが作り出すことを防ぐ。
【００２８】
高信頼性デバイス２４の構成は、本出願人による前述の国際特許出願ＰＣＴ／ＧＢ００／００５２８にさらに詳細に記載されている。
高信頼性デバイスの具体的構成は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない。
【００２９】
高信頼性コンピューティングプラットフォームは、いったん起動された後は、コンパートメント化すなわち高信頼性オペレーティングシステムを有することになる。
つまり、オペレーティングシステムによってサポートされる必要のある１つまたは複数のサービスまたはプロセスが、論理的被保護コンピューティング環境であるコンパートメント内で実行される。
既に述べたように、コンパートメント内でのアクションまたは特権は、特に、コンパートメントの外部に効果を有するメソッドおよびオペレーション（例えば、ネットワークアクセスやコンパートメントの外部のファイルへのアクセスを要求するメソッド）を実行するプロセスの能力を制限するように（セキュリティポリシによって）制約される。
さらに、コンパートメント内のプロセスのオペレーションは、外部の影響による干渉およびのぞき見から高度に隔離されて実行される。
【００３０】
好ましい一実施形態では、コンパートメントは、オペレーティングシステムカーネルによって制御されるオペレーティングシステムコンパートメントであり、既に述べたように、これは、コンパートメント化オペレーティングシステムまたは高信頼性オペレーティングシステムとも呼ばれる。
【００３１】
コンパートメントとネットワークリソースの間の通信は、ＴＣＰ／ＵＤＰのようなトランスポートメカニズムへの狭いカーネルレベル制御のインタフェースを通じて行われる。
これらの通信インタフェースへのアクセスは、コンパートメントごとに指定されたルールによって統制される。
カーネル内の適当なポイントで、例えばどのコンパートメントがどのコンパートメントのリソースにアクセスすることが許容されるかを示すルールのテーブルを参照する動的ロード可能セキュリティモジュールへのフックを用いることにより、アクセス制御チェックが実行される。
コンパートメント間アクセスが行われることを明示的に許容するルールがない場合、アクセス試行はカーネルによって拒否される。
ルールは、別のコンパートメントのリソースにアクセスすることが明示的に許容されたコンパートメントを除いて、個別のコンパートメント間の強制的セグメンテーションを実施する。
【００３２】
図面の図３を参照すると、本発明によるプロセスの例示的な一実施形態はステップ１００から開始され、プラットフォームの起動が実行される。
起動時に、プラグ式認証モジュール（ＰＡＭ）として知られるセキュリティモジュールをロードするためのスクリプトが実行され、２個の入力ファイルがメモリにロードされる。
これらの２個の入力ファイルはそれぞれ、コンパートメント名と番号の間のマッピング、およびネットワークインタフェース名とネットワークインタフェース番号の間のマッピングである。
プラットフォームは、システム上に構成されるコンパートメントごとに１個ずつの、いくつかのサブディレクトリを含むディレクトリを含み、この時点で、システム初期化（のみ）に関連するコンパートメントに関連するサブディレクトリがアクセスされる。
また、これらのサブディレクトリにわたって反復されるもう１つのスクリプトが実行される。
このスクリプトは、システム初期化に関連するコンパートメントをロードするとともに、それぞれのロードされたコンパートメントに関連するセキュリティルールをロードする。
【００３３】
ステップ１０２で、セキュリティコンフィグレーションがロードされる。
【００３４】
ステップ１０６で、システムはサービスを開始することを決定し、（ステップ１０８で）そのサービスに関連するコンパートメントがロードされるとともに、（ステップ１１０で）付随するセキュリティルールがロードされる。
セキュリティルールには、１つまたは複数のｅｘｅｃルール、すなわち、サービスまたはプロセスが実行された後でそれに適用されるルールが含まれてもよい。
これらのｅｘｅｃルールはステップ１１２で適用される。
【００３５】
ｅｘｅｃルールは２つの主要な用途を有する。
第１に、それらは、プロセスが開始される時にプロセスが有するべきセキュリティ属性を規定するために使用可能である（ステップ１１４）。
一例として、次のｅｘｅｃルールを考える。
exec[   from.comp system;
filename /sbin/mingetty;
comp system;
permitted.raise CAP_MAC_ADMIN
CAP_MAC_SETCID   ]
【００３６】
このように、「filename /sbin/mingetty」によって識別されるプロセスが「system」コンパートメント内で実行されている場合、そのコンパートメントに特権「CAP_MAC_ADMIN」および「CAP_MAC_SETCID」が与えられるため、ＰＡＭは、各ユーザが正しい特権を取得することを保証することができる。
すなわち、ＰＡＭには、必要な特権を全ユーザに与える能力が付与される。
より詳細には、ユーザログインを制御するプログラムが提供され、ＰＡＭモジュールがログイン時に実行されて、ユーザのログインに対してユーザのコンパートメントおよび権限を設定する。
これは特権オペレーションであるため、ユーザログインを制御するプログラムは規定された権限（CAP_MAC_ADMINおよびCAP_MAC_SETCID）を有する必要がある。
それにより、それらの権限はＰＡＭを実行するプロセスによって継承され、そのプロセスはログインを正しく設定するための特権を有する。
【００３７】
第２に、ｅｘｅｃルールは、プロセスがどこで実行されるべきかを規定するマッピングを提供するために使用可能である。
そこで例えば、サービスａがコンパートメントＡで実行される場合を考える。
コンパートメントＡがオープンまたはロードされると、そのコンパートメントに関連するルールもまたロードされる。
それらのルール内には、サービスａが開始される時に、それをコンパートメントＡ内で実行することを指定するｅｘｅｃルールがあってもよい。
その場合、そのルールが（ステップ１１６で）適用される。
こうして、サービスａは通常通り開始されることが可能であり（したがってサービスａは変更される必要がない）、コンパートメントＡがロードされる時に関連するｅｘｅｃルールがロードされる正しいコンパートメントに移動される。
各ｅｘｅｃルールは、影響を受けるファイル（複数可）および当該ルールが適用されるコンパートメントを指定するので、ｅｘｅｃルールを使用することにより、高信頼性ゲートウェイを使用することが不要になる。
【００３８】
要約すれば、本発明のこの例示的実施形態によるｅｘｅｃルールは、次のような、プロセスのセキュリティ関連プロパティを制御する：
・ｕｉｄ：結果として得られるユーザｉｄ（指定がなければ変更されない）
・ｇｉｄ：結果として得られるグループｉｄ（指定がなければ変更されない）
・権限：有効なセット、許容されるセットおよび継承可能なセットに対する権限モディファイア。
（権限は、引き上げられ、引き下げられ、またはフィルタリングされ得る。
引き上げられた権限はオンに設定される。
引き下げられた権限はオフに設定される。
フィルタセット内の権限は変更されず、フィルタセット内にない権限は引き下げられる。
権限モディファイアは、それがなければシステム管理者の立場からなされ得る種々の（機密に関わる）ことを制限するために使用可能である。
権限制限は、無権限者がこれらの権限を取得しないように、「ｒｏｏｔ」権能を制限するために使用可能である。）
・コンパートメント：結果として得られるコンパートメント（指定がなければ変更されない）
・ｃｈｒｏｏｔ：プロセスをｃｈｒｏｏｔする先のディレクトリ（指定がなければｃｈｒｏｏｔはない）
【００３９】
上記のプロセスでは、ｅｘｅｃルールは、それが適用されるプロセスを、コンパートメントｉｄを与えることによって指定する。
ルールは、そのコンパートメントｉｄを有するプロセスのみに適用される。
本発明のこの例示的実施形態では、ｅｘｅｃルールはファイルパスも含む。
このファイルパスは、ディレクトリまたは個別のファイルの名前であってもよい。
ファイルパスがディレクトリである場合、それは、別のｅｘｅｃルールのほうが「より特定的」でない限り、当該ディレクトリおよびそのサブディレクトリ内の全ファイルに適用される。
ルール衝突がある場合に「より特定的」なルールを選択するという考え方は当業者に既知であろう。
さらに、このようなルール衝突が解決され得る方法は本発明とは直接の関連性がほとんどないので、本明細書ではこれ以上説明しない。
【００４０】
また、本発明のこの例示的実施形態では、ルールのパス自体がシンボリックリンクを表すのでない限り、ルールが適用されるファイルのセットを決定する場合に、シンボリックリンクはたどられないことになる。
【００４１】
適用可能なｅｘｅｃルールを有するファイルは、呼出し側がａｄｍｉｎ権限を持っていない限り、全コンパートメントからリードオンリにするのが好ましい。
その理由は、ｅｘｅｃルールを有するファイルは実質上、それに付与される特権を有し、変更されるファイルにこの特権が付与されるのは望ましくないからである。
場合によっては、無権限エンティティが、ファイルへのハードリンクを作成することによって、そのファイルに適用されるルールを変更することが可能であるかもしれない。
しかし、本発明のこの例示的実施形態では、不正なリンクは削除され、エラーが返される。
【００４２】
ｅｘｅｃルールがどのファイルに適用されるかの正しい認識を維持するため、ファイル名前空間を変更するオペレーション、すなわち、ファイル作成、ファイル名変更、リンク作成、リンク削除、マウント、アンマウントを監視するのが好ましい。
【００４３】
要約すれば、ｅｘｅｃルールは、別のプログラムを呼び出した後にプロセスのセキュリティ属性を直接に指定することによって、既存のプログラムを変更することや、高信頼性ゲートウェイを使用することを不要にする。
図３のプロセスを実行するのに適した例示的装置は、論理的被保護コンピューティング環境の権限のセットをフィルタリングするフィルタリング手段を備えてもよい。
フィルタリング手段は、それらの権限のうち、フィルタリング手段によって選択される１つまたは複数の権限のみを変更する。
実行制御ルールが適用されるサービスまたはプログラムを構成するファイルの名前を変更する（システムによって実行される）オペレーションを監視する監視手段が提供されてもよい。
【００４４】
実行制御ルールは、関連する論理的被保護コンピューティング環境を識別することによって、その実行制御ルールが適用されるサービスまたはプロセスを指定してもよい。
その結果、ルールは、論理的被保護コンピューティング環境を指定するサービスまたはプロセスのみに適用される。
【００４５】
以上、本発明の一実施形態を単なる例として説明したが、当業者には明らかなように、添付の請求項によって規定される本発明の範囲から逸脱することなく、記載した実施形態に対して変更および変形を行うことが可能である。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施形態を実施することが可能なシステムを示す図である。
【図２】スマートカードリーダおよびモジュール群と通信するように構成された高信頼性デバイスを含むマザーボードである。
【図３】本発明の例示的な一実施形態による（簡略化された）方法を示す流れ図である。
【符号の説明】
【００４７】
１０・・・高信頼性コンピューティングプラットフォーム、
１２・・・スマートカードリーダ、
１４・・・キーボード、
１６・・・マウス、
１８・・・視覚表示装置（ＶＤＵ）、
２０・・・マザーボード、
２１・・・メインプロセッサ、
２２・・・メインメモリ、
２３・・・Ｉ／Ｏデバイス、
２４・・・高信頼性デバイス、
２６・・・データバス、
２７・・・制御ライン、
２８・・・アドレスライン、
２９・・・ＢＩＯＳメモリ、
【図１】
2004303242.tif 000003
【図２】
2004303242.tif 000004
【図３】
2004303242.tif 000005
【外国語明細書】
Security Attributes 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 permitted access to system resources.
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.
In the past, it has been considered desirable to load the security rules as early in the startup sequence of a platform as possible, such that relevant security rules are in force as soon as a service or process is started. As such, in prior art systems, all security rules tend to be loaded to the platform at the time of system initialisation, i.e. a complete security policy is loaded at system startup. Thus, security attributes tend to be assigned by security initialisation and cannot be changed except by processes with special authorisation.
In secure operating systems, there is often a need to change the security attributes of programs at certain points (i.e. perform a 'security transition'), for example, when when a process forks and runs another program, because a service requires a security ID to enter a compartment. Thus, in prior art systems, it has either been necessary to modify the manner in which a service starts (i.e. modify the script, control program or other facility by which the service starts) so as to ensure that it is put in the correct compartment, or some form of mapping function has been configured to handle this issue.
In other words, the changing of security attributes of programs at certain points has, in the past, been done explicitly, using special system calls, or by using trusted gateway programs to change the attributes. This is inconvenient because it involves modifying the calling program (as mentioned above) to include the special system calls or to call the trusted gateway program instead of the required program. It can also involve making it necessary to give the calling
program extra security attributes allowing it to change the attributes of called programs.
Disclosure of the Invention
In accordance with the present invention, there is provided a system comprising a trusted computing platform and one or more logically protected computing environments, each of which is associated with at least one service or process supported by said system, the system being arranged to load onto said trusted computing platform data defining a predetermined security policy defining security attributes to be applied to one or more of the at least one service or process when said service or process is started.
In one embodiment the policy included one or more security rules for controlling operation of logically protected computing environments.
Preferably the or each security rule for at least one of the logically protected environments will include an execution control rule which defines the security attributes.
Also in accordance with the present invention, there is provided a method of applying a security policy in a system including a trusted computing platform and one or more logically protected computing environments, each of which is associated with at least one service or process supported by said system, the method including the step of:
Marking a service or process associated with at least one of the logically protected computing environments; and controlling the operation of the at least one logically protected environment by applying, upon starting of the service or process, security attributes to the service of process.
Preferably the attributes are defined by execution control rules, which are included in security rules complementing at least part of the policy.
It will be appreciated that, in the context of the present invention, the term "trust" is used in the sense that something can be "trusted" if it always behaves in the expected manner for the intended purpose.
Thus, the present invention provides the ability to include in the security rules for a logically protected computing environment (or "compartment") an execution control rule (hereinafter referred to as an "exec rule") which defines or modifies security attributes to be applied to a service or process when that service or process is started. This removes the need to modify existing programs or use security-trusted gateway programs.
The security attributes may include or comprise one or more capabilities to be provided to the respective logically protected computing environment when the service or process has started; one or more functions which change or modify the capabilities of the respective logically protected computing environment when the service or process is started; a function which, when a service or process is started, causes the service or process to be placed and run in a specified logically protected computing environment; a function which can modify a user id, a group id, or a logically protected computing environment in which a service or process is to be run; and/or a function defining a directory to which the respective service or process is to be chrooted. As will be understood by a person skilled in the art, the term "chroot" is a command to make the root directory (1) become something other than its default for the lifetime of the current process.
In the case where the security attributes include or comprise one or more functions which change or modify the capabilities of the respective logically protected computing environment when the process or service has started, such functions may raise or lower a specified capability. In one embodiment of the invention, means for filtering a set of capabilities may be provided such that only one or more of said capabilities as selected by the filtering means is modified.
The or each execution control rule preferably specifies the service or process to which it applies by identifying the associated logically protected computing environment, with the effect that the rule applies only to services and processes specifying that logically protected computing environment.
The files making up a service or process are preferably read-only, and means are preferably provided for monitoring operations performed by the system which modify the names of such files.
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; and
Figure 3 is flow diagram illustrating a (simplified) method according to an exemplary embodiment of the present invention.
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.
Referring to Figure 3 of the drawings, an exemplary embodiment of a process according to the present invention begins at step 100, where startup of the platform is performed. At startup, a script is run to load a security module known as a pluggable authentication module (or PAM) and then two input files are loaded into memory, which two input files are the compartment name and number mappings and the network interface name and network interface number mappings respectively. The platform includes a directory containing a number of subdirectories, one for each compartment configured on the system and, at this point, the subdirectories associated with the compartments associated (only) with system initialisation are accessed, and another script is run which iterates through these subdirectories and loads the compartments associated with system initialisation, and the security rules associated with each loaded compartment.
At step 102, the security configuration is loaded.
At step 106, the system determines that a service is starting, and the compartment associated with that service is loaded (at step 108), together with the accompanying security rules (at step 110). Included in the security rules, there may be one or more exec rules, i.e. rules to be applied to a service or process after it has been executed, and these exec rules are applied at step 112.
Exec rules have two primary uses. Firstly, they can be used to define the security attributes a process is to have when it is started (step 114). As an example, consider the following exec rule:
exec[   from.comp system;
filename /sbin/mingetty;
comp system;
permitted.raise CAP_MAC_ADMIN
CAP_MAC_SETCID   ]
Thus, if the process identified by "filename/sbin/mingetty" is running in the "system" compartment, that compartment is given the privileges "CAP_MAC_ADMIN" and "CAP_MAC_SETCID", such that PAM can ensure that each user gets the correct privileges, i.e. this gives PAM the ability to give all users the required privileges. In more detail, a program is provided to control user logins, and a PAM module runs on login, setting user compartment and capabilities for the user's login. This is a privileged operation, so the program controlling user logins needs to have the defined capabilities (CAP_MAC_ADMIN and CAP_MAC_SETCID) so that they will be inherited by the process that runs PAM, and it will have the privilege to configure the login correctly.
Secondly, exec rules can be used to provide mappings to define where a process is to be run. Thus, for example, consider the case where service a is to be run in compartment A. When compartment A is opened or loaded, the rules associated with that compartment are also loaded. In those rules, there may be an exec rule which specifies that, when service a is started, run it in compartment A, which rule is then applied (at step 116). Thus, service a can be started in the conventional way (such that it does not need to be modified), and it is moved to the correct compartment the relevant exec rule which is loaded when compartment A is loaded. Each exec rule specifies the file(s) affected and the compartment the rule applies to, such that the use of exec rules avoids the need to use trusted gateways.
In summary, exec rules according to this exemplary embodiment of the present invention have control over the security-relevant properties of a process, including:
・ uid: resulting user id (unmodified if not specified)
・ gid: resulting group id (unmodified if not specified)
・ capabilities: capability modifiers for the effective, permitted and inheritable sets.
(Capabilities may be raised, lowered or filtered. A raised capability is set on. A lowered capability is set off. Capabilities in the filtered set are unmodified, and capabilities not in the filtered set are lowered. Capability modifiers can be used to restrict various (sensitive) things which can otherwise be done from a system administration point-of view. Capability restrictions can be used to limit "root" powers to prevent unauthorised persons from obtaining these capabilities).
・ compartment: resulting compartment (unmodified if not specified)
・ chroot: a directory to chroot the process to (no chroot if not specified)
In the process described above, an exec rule specifies the processes it applies to by giving a compartment id. The rule only applies to processes with that compartment id. In this exemplary embodiment of the invention, an exec rule also contains a file path, which may be the name of a directory or individual file. If the file path is a directory it applies to all files in that directory and its subdirectories, unless another exec rule is "more specific". The concept of
selection of the "more specific" rule when there is a rule conflict will be known to a person skilled in the art. Furthermore, the manner in which such rule conflicts may be resolved is of little relevance to the present invention and will not be discussed any further herein.
Further, symbolic links tend not to be followed in this exemplary embodiment of the invention when determining the set of files a rule applies to, unless the rule's path itself denotes a symbolic link.
It is preferred to make files having applicable exec rules read-only from all compartments, unless the caller has admin capability. This is because a file with an exec rule essentially has a privilege conferred on it and it would be undesirable for this privilege to be conferred on a modified file. In some cases, it may be possible for an unauthorised entity to change the rules applying to a file by creating a hard link to it. However, in this exemplary embodiment of the invention, the offending link would be caused to be removed and an error would be returned.
In order to maintain a correct view of which exec rules apply to which files, it is preferred to monitor operations modifying the file namespace, i.e. file create, file rename, link create, link delete, mount, unmount.
In summary, exec rules remove the need to modify existing programs or use trusted gateways, by directly specifying the security attributes of a process after calling another program. Exemplary apparatus suitable for carrying out the process of Figure 3 may comprise may include filtering means for filtering a set of capabilities of a logically protected computing environment and modifying only one or more of those capabilities, as selected by the filtering means. Monitoring mean s may be provided for monitoring operations performed by the system which modify names of files making up services or programs to which an execution control rule applies.
An execution control rule may specify the service or process to which it applies by identifying the associated logically protected computing environment, with the effect that the rule applies only to the services or processes specifying that logically protected computing environment.
An embodiment of the present invention has been described by way of example only, and it will be apparent to persons skilled in the art that modifications and variations can be made to the described embodiment without departing from the scope of the invention as defined by the appended claims.
1. A system comprising a trusted computing platform and one or more logically protected computing environments, each of which is associated with at least one service or process supported by said system, the system being arranged to load onto said trusted computing platform data defining a predetermined security policy defining security attributes to be applied to one or more of the at least one service or process when said service or process is started.
2. A system according to claim 1 wherein the policy included one or more security rules for controlling operation of logically protected computing environments.
3. A system according to claim 2 wherein the or each security rule for at least one of the logically protected environments will include an execution control rule which defines the security attributes.
4. A system according to claim 3, wherein said security attributes include or comprise one or more capabilities to be provided to the respective logically protected computing environment when said service or process is started.
5. A system according to claim 3, wherein said security attributes include or comprise one or more functions which change or modify the capabilities of the respective logically protected computing environment when said service or process is started.
6. A system according to claim 3, wherein when a service or process is started said security attribute operate to cause the service or process to be placed and run in a specified logically protected computing environment.
7. A system according to claim 3, wherein said security attributes operate to modify a user id, a group id or a logically protected computing environment in which a service or process is to be run.
8. A system according to claim 3, wherein said security attributes operate to define a directory to which the service or process is to be chrooted.
9. A system according to claim 5, wherein said execution control rule can raise or lower a specified capability.
10. A system according to claim 5 or claim 9, wherein the security attributes operate to filter a set of capabilities of a logically protected computing environment and modifying only one or more of said capabilities as selected by said filtering means.
11. A system according to any one of the preceding claims, wherein said execution control rule specifies the service or process to which it applies by identifying the associated logically protected computing environment, with the effect that said rule applies only to services or processes specifying that logically protected computing environment.
12. A system according to any one of the preceding claims, wherein the files making up a service or process to which said execution control rule applies are of read-only configuration.
13. A system according to any one of the preceding claims, including means for monitoring operations performed by the system which modify names of files making up services or programs to which said execution control rule applies.
14. A system substantially as herein described with reference to the accompanying drawings.
15. A method of applying a security policy in a system including a trusted computing platform and one or more logically protected computing environments, each of which is associated with at least one service or process supported by said system, the method including the steps of starting a service or process associated with at least one of the logically protected computing environments; and controlling the operation of the at least one logically protected environment by applying, upon starting of the service or process, security attributes to the service or process.
16. A method according to claim 15 wherein the attributes are defined by execution control rules, which are included in security rules implementing at least part of the policy.
17. A method of applying a security policy in a system including a trusted computing platform, the method being substantially as herein described with reference to the accompanying drawings.
Security/Attributes in Trusted Computing Systems
A system comprising a trusted computing platform including one or more logically protected computing environments, each of which is associated with at least one service or process supported by said system, the system being arranged to load onto said trusted computing platform a predetermined security policy including one or more security rules for controlling the operation of each of said logically protected computing environments, the security rules for at least one of said logically protected computing environments including an execution control rule which defines the security attributes to be applied to a service or process associated with said logically protected computing environment when said service or process is started.
[Figure 3]
2004303242.tif 000006
2004303242.tif 000007
2004303242.tif 000008