(57)【要約】【課題】ネットワークサービスが損なわれた場合に、通常はセキュアであるシステムに与えられる可能性のある損傷を抑制または制御する。【解決手段】本発明にかかるアクセス制御システムおよびアクセス制御方法は、１つ以上のコンパートメントを定義し、このコンパートメントに適用され、このコンパートメントに関連付けられているエンティティによるネットワークサービスへのアクセスを制御する規則を提供する。この規則は、少なくとも、動的に割り当てられる通信ポートを使用するネットワークサービスへのアクセスを制御するための第１の種類の規則を含む。【選択図】図４
2009009566.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のコンパートメントを定義し、このコンパートメントに関連付けられているエンティティによるネットワークサービスへのアクセスを制御するために、前記１つ以上のコンパートメントに適用される規則を提供するアクセス制御システムであって、
前記規則は、
少なくとも、動的に割り当てられる通信ポートを使用するネットワークサービスへのアクセスを制御するための第１の種類の規則
を含む
システム。
【請求項２】
事前に割り当てられている通信ポートを使用するネットワークサービスへのアクセスを制御するための第２の種類の規則
を含む
請求項１に記載のシステム。
【請求項３】
前記第１の種類の規則と、前記第２の種類の規則とは異なる
請求項２に記載のシステム。
【請求項４】
前記第１の種類の規則は、いずれの通信ポートとも無関係に定義される
請求項１に記載のシステム。
【請求項５】
前記第１の種類の規則は、ネットワークサービス識別子に関して定義される
請求項１に記載のシステム。
【請求項６】
前記適用される規則は、前記システムの規則テーブルにおいて識別される
請求項１に記載のシステム。
【請求項７】
前記適用される規則は、モジュールにおいて定義され、
前記規則テーブルは適用される各規則を識別し、それぞれの前記モジュールへの関連するポインタ
を含む
請求項６に記載のシステム。
【請求項８】
前記ポインタは、不透明ポインタ（opaque pointer）である
請求項７に記載のシステム。
【請求項９】
エンティティからのネットワークサービスコールを受信するネットワークサービスハンドラ
を備える請求項１に記載のシステム。
【請求項１０】
前記ネットワークサービスハンドラは。ネットワークサービスコールを受信し、適用されるアクセス制御規則に関して、前記コール側エンティティが、前記識別されたネットワークサービスにアクセスするための許可を有するか否かを確認するように、このシステムに指示し直し（redirect）、適用されるアクセス制御規則が前記ネットワークサービスにアクセスする許可を付与する場合にのみ、前記ネットワークサービスコールを処理するように構成されている
請求項９に記載のシステム。
【請求項１１】
前記ネットワークサービスハンドラは、ネットワークサービスコールを処理するrpc_call()機能
を備える
請求項９に記載のシステム。
【請求項１２】
前記コール側エンティティが、前記ネットワークサービスにアクセスする権利を有するか否かを確認するための関数をコールする関数コール
を含む請求項１１に記載のシステム。
【請求項１３】
強制アクセス制御の規則を適用して、ネットワークサービスへのアクセスを制御する
請求項１に記載のシステム。
【請求項１４】
セキュアオペレーティングシステム
を含む請求項１に記載のシステム。
【請求項１５】
ＲＰＣネットワークサービスへのアクセスを制御するアクセス制御規則を提供する
請求項１に記載のシステム。
【請求項１６】
要求側エンティティからのネットワークサービスコールを受信することであって、この要求側エンティティは、セキュアオペレーティングシステムのコンパートメントに関連付けられ、前記ネットワークサービスは、動的に割り当てられる通信ポートを使用することと、
前記コンパートメントに適用されているあらゆる規則に関して、前記エンティティが、前記ネットワークサービスにアクセスするための許可を有するか否かを判断することと、
適用されるコンパートメント規則が、前記ネットワークサービスにアクセスするための許可を付与する場合にのみ、前記ネットワークサービスコールを処理することと
を含むアクセス制御方法。
【請求項１７】
ネットワークサービスコールを処理するように構成されるデータ処理システムであって、
このシステムのコンパートメントに関連付けられているエンティティから、動的に割り当てられる通信ポートを使用するネットワークサービスのコールを受信する入力と、
コンパートメントに適用され、関連するネットワークサービスアクセス許可を定義する規則を記憶するストアと、
前記ストアが、前記ネットワークサービスにアクセスするための許可を付与する前記コンパートメントの規則を含む場合にのみ、前記ネットワークサービスコールを実行に移すプロセスと
を備えるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムにおけるアクセス権に関する。
【背景技術】
【０００２】
オペレーティングシステムは、通常、コンピュータのその後のオペレーションを制御するためにコンピュータのメモリにロードされて実行されるコンピュータプログラムまたはコンピュータプログラムのセットである。
しかしながら、オペレーティングシステムは、特に、たとえば移動電話およびＰＤＡ等のポータブルデバイスでは、ファームウェアまたはハードウェアの組み込みプログラムとすることもできる。
【０００３】
ほとんどの従来のコンピュータオペレーティングシステムは、アクセス制御の形で、或る種の論理的保護をデータに提供する。
この論理的保護は、特定の人々または特定の人々のグループに対して付与または拒否することができる。
一般に、任意アクセス制御（ＤＡＣ）を提供するシステムでは、ユーザ（アドミニストレータと相対する者として）は、自身のデータに許可を割り当てることができる。
これによって、他者（または他者のグループ）のそのデータへのアクセスが許可または拒否される。
これは、個人にとっては満足のいくものである。
しかしながら、いくつかの組織、特に軍隊組織または政府機関等では、情報へのアクセスをより厳重に制御する能力が必要とされる。
たとえば、最高機密情報は、組織内のほとんどの人に見えるものであるべきではなく、制限情報は、そのラベルが示唆するように、一般に利用可能であるべきではないのに対し、非制限情報は、組織内のだれによるアクセスにも利用可能とすることができる。
【０００４】
したがって、組織の情報に対してより優れたアクセス制御を提供するセキュアオペレーティングシステムが知られている。
通常、セキュアオペレーティングシステムは、付加的な分類またはラベルをファイルに関連付け、いわゆる強制アクセス制御（ＭＡＣ）を適用する。
ＭＡＣは、（たとえば、機密ラベルによって表されるような）ファイルの機密性に基づいてファイルへのアクセスを制限する手段を提供する。
ＤＡＣとは対照的に、ＭＡＣの下では、ユーザは、誰が自身のデータを見るのかを決定する権利を有しない。
すなわち、互換性のある情報取扱許可（clearance）を有するユーザのみが、データを見ることを許可される。
たとえば、最高機密情報取扱許可を有するユーザは、それよりも下位の情報取扱許可を有する他者が自身のデータを見ることを許可する能力を有しない。
【０００５】
ＭＡＣは、「コンパートメント」によって表すことができる。
実際には、コンパートメントは、通常、名称等の識別子を有する論理構成体（logical construct）であって、そのコンパートメントを定義する一組のアドミニストレータが構成したアクセス制御規則が適用される論理構成体である。
コンパートメント規則は、アプリケーションの実行に必要な資源（ファイル、プロセス、プロセス間通信メソッド等）のみへのアクセスを許可するのに使用される。
これらの規則は、コンパートメントにおいて動作する許可を有するユーザおよびプロセスの双方に適用され、したがって、別段の指定のない限り、または、文脈上別の意味が指示されていない限り、このようなユーザおよびプロセスは、本明細書では「エンティティ」と総称される。
【０００６】
したがって、コンパートメント内で動作するエンティティは、デフォルトとは逆の特定のＭＡＣ規則が提供されない限り、デフォルトでは、同じコンパートメントにおいてアクセス可能であると定義されたファイル、他のプロセスおよび資源にしかアクセスすることができない。
【０００７】
コンパートメントは、アプリケーションについて隔離されたランタイム環境を提供することができる。
この隔離されたランタイム環境では、コンパートメント規則によって、アプリケーションの実行に必要な資源のみへのアクセスが可能になる。
これによって、たとえアプリケーションが損なわれていても、その損傷が、そのアプリケーションが実行されているコンパートメント（複数可）にのみ限定される可能性が増加する。
【０００８】
ファイルシステム等へのアクセスを制御することに加えて、ＭＡＣ規則を定義することによって、ＭＡＣが、一般のリモートサービス、より詳細にはネットワークサービスを提供するネットワークエンドポイント等、コンパートメントの外部の資源へのアクセスを制御するのに使用されることが知られている。
これらのＭＡＣ規則は、コンピューティングプラットフォームの特定の通信インターフェースへのアクセスを許可または拒否する。
本明細書で使用される場合、「ネットワークサービス（またはネットワーク接続サービス）」という用語は、ネットワーク接続された複数のコンピュータから成る分散コンピューティング環境においてリモートコンピュータ、すなわちサーバ上で実行されるコンピュータプログラムである。
ネットワークサービスは、サービスを実行するホストから遠隔にあるクライアント（たとえば、セキュアオペレーティングシステムを実行しているホスト）からアクセスして起動する、すなわち「呼び出す」ことができる。
ネットワークサービスの例は、既知のサービスを２〜３例を挙げると、ＲＰＣサービス（ypserv、mountd等）、ウェブサイト、Ｘ端末（X-terminal）、およびＦＴＰサイトである。
【０００９】
ネットワークサービスへのアクセスを制御する能力は、既に損なわれているおそれのあるネットワークサービスまたは今後損なわれるおそれのあるネットワークサービスにエンティティがアクセスすることを防止するためのメカニズムを提供することによって、セキュリティを増加させる。
ネットワークサービスが損なわれる可能性のある最も一般的な様態は、サービス拒否攻撃によるものである。
この攻撃は、適法なユーザに対してサービスを利用不能にしようとして、サービスのダミー要求でサービス（またはサービスを実行しているサーバ）をフラッドさせるものである。
【００１０】
資源アクセスのためのＭＡＣを定義する１つの既知の方法は、いわゆるラベル化セキュリティ保護プロファイル（labelled security protection profiles）（ＬＳＰＰ）に基づくものである。
このＬＳＰＰでは、資源（たとえば、ネットワークエンドポイント）は、資源上のアクセス制御ポリシーを指定するラベルを保持するように構成されている。
しかしながら、ＭＡＣをこのように実施するには、多大な労力と、従来のアプリケーションおよびシステムへの適応が必要とされる。
資源アクセスのためのＭＡＣを定義する既知のより簡単な方法は、アクセス制御規則を使用することに基づくものである。
アクセス制御規則は、個々のコンパートメントごとに指定される。
このような制御規則は、通常、ＴＣＰポート番号を使用して、ネットワークエンドポイント、たとえばネットワークサービスを一意に識別する。
多くのネットワークサービスは、事前に割り当てられている既知のポート番号を使用する。
たとえば、ＨＴＴＰはＴＣＰポート８０を使用し、ＰＯＰ３はポート１１０を使用し、ＩＲＣはポート１９４を使用する。
このような場合に、ＭＡＣ規則を使用してそれぞれのポートへのアクセスを付与または拒否することによって、サービスへのアクセスを付与または拒否することが可能である。
しかしながら、ＲＰＣサービスおよびＸＴＥＲＭサービス等のいくつかのネットワークサービスは、事前に割り当てられているポート番号を使用せず（すなわち、ポート番号は、ランタイムにおいて動的に配分、すなわち割り当てられ）、したがって、コンパートメント規則でポート番号を指定することによってアクセスを付与または拒否することが可能でない。
このようなアクセス制御がないことから、いずれかのこのようなネットワークサービスが損なわれた場合に、通常はセキュアであるシステムに与えられる可能性のある損傷を抑制または制御することが容易でない場合がある。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従来技術の問題の１つ以上を少なくとも軽減することが、本発明の実施の形態の目的である。
【課題を解決するための手段】
【００１２】
本発明の一態様によれば、１つ以上のコンパートメントを定義すると共に、当該コンパートメントに関連付けられるエンティティによるネットワークサービスへのアクセスを制御するための、コンパートメント（複数可）に適用される規則を提供するアクセス制御システムであって、規則は、動的に割り当てられる通信ポートを使用するネットワークサービスへのアクセスを制御するための少なくとも第１の種類の規則を含む、システムが提供される。
【００１３】
本発明の別の態様によれば、アクセス制御方法であって、
セキュアオペレーティングシステムのコンパートメントに関連付けられる要求側エンティティからのネットワークサービスコールを受信することであって、上記ネットワークサービスは、動的に割り当てられる通信ポートを使用する、受信すること、
コンパートメントに適用されているあらゆる規則に関して、エンティティがネットワークサービスにアクセスするための許可を有するか否かを判断すること、および
適用されるコンパートメント規則が、ネットワークサービスにアクセスするための許可を付与する場合にのみ、ネットワークサービスコールを処理することを含む、方法が提供される。
【００１４】
本発明のさらに別の態様によれば、ネットワークサービスコールを処理するように構成されているデータ処理システムであって、
該システムのコンパートメントに関連付けられるエンティティから、動的に割り当てられる通信ポートを使用するネットワークサービスのコールを受信するための入力と、
コンパートメントに適用されると共に関連するネットワークサービスアクセス許可を定義する規則を記憶するストアと、
ストアが、ネットワークサービスにアクセスするための許可を付与するコンパートメントの規則を含む場合にのみ、ネットワークサービスコールを実行に移すプロセスとを備える、システムが提供される。
【００１５】
既知のセキュアオペレーティングシステムは、ＳＥＬｉｎｕｘ（商標）、Ｔｒｕｓｔｅｄ  Ｓｏｌａｒｉｓ（商標）、およびＨＰ−ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔ（商標）であり、本発明の態様の実施の形態は、これらのオペレーティングシステムに適用することができる。ただし、教示される原理は、より広く適用可能である。
【００１６】
本発明のさらなる特徴および利点は、単なる例として与えられた、本発明の好ましい実施の形態の以下の説明から明らかになる。以下の説明は、添付図面を参照して為される。
【発明を実施するための最良の形態】
【００１７】
既知のポート番号を使用するネットワークサービスへのアクセス（またはその使用）を制御することが可能であることが知られているが、本発明の実施形態は、新しいクラスのコンパートメント規則に関するものであり、この新しいクラスのコンパートメント規則は、動的に割り当てられるポート番号を使用するネットワークサービスへのアクセス（またはその使用）を制御するものである。
【００１８】
次に、本発明の実施形態を詳細に説明する前に、本発明の特定の実施形態を実施するのに適したコンピューティング環境を説明する。
【００１９】
本発明の実施形態を実施するのに適した例示的なコンピューティングプラットフォーム１０を図１の図解に示す。
このコンピューティングプラットフォーム１０は、キーボード１４、マウス１６、および視覚表示ユニット（ＶＤＵ）１８の標準的な機能を有する。
これらは、プラットフォームの物理的な「ユーザインターフェース」を提供する。
プラットフォームは、マザーボード、および、ファイルシステムを記憶するためのハードディスクドライブ等の標準的なコンポーネントを含む。
【００２０】
図２に示すように、コンピューティングプラットフォーム１０のマザーボード２０は、（他の標準的なコンポーネントの中でも特に）メインプロセッサ２１、メインメモリ２２、データバス２６およびそれぞれのアドレス指定ライン２７および制御ライン２８、プラットフォーム１０のＢＩＯＳプログラムを含むＢＩＯＳメモリ２９、並びに入出力（ＩＯ）コントローラ２５を含む。
ＩＯコントローラ２５（１つ以上の独立したサブシステムを備えることができる）は、マザーボードのコンポーネントと接続されているデバイスとの間の相互作用を制御する。
接続デバイスは、（入力コントローラ２５３を介した）キーボード１４およびマウス１６、（出力コントローラ２５４、たとえば、スクリーンコントローラまたはグラフィックスコントローラを介した）ＶＤＵ１８、（ストレージコントローラ２５２を介した）ハードディスク等のストレージデバイス１２、並びに（ネットワークコントローラ２５１、たとえば、イーサネット（登録商標）ＬＡＮコントローラを介した）外部世界等である。
ネットワークコントローラ２５１は、ネットワークインターフェースカード（ＮＩＣ）上に具現化することができる。
たとえばインターネット全体にわたる外部世界との通信は、ネットワークコントローラ２５１を介して方向付けられ、通常、データパケットを含む。
既知のシステムでは、以下でより詳細に説明するように、データパケットは、通常、ＮＩＣ等の論理ポート番号を介して移動するようにアドレス指定される。
【００２１】
メインメモリ２２は、通常、ランダムアクセスメモリ（ＲＡＭ）であり、ＢＩＯＳメモリは、通常、ＥＥＰＲＯＭである。
ＥＥＰＲＯＭは、ＢＩＯＳ更新で「フラッシュ」することができる。
動作中、プラットフォーム１０は、ＢＩＯＳメモリ２９からＲＡＭ内へＢＩＯＳをロードし、次に、ハードディスク１２からＲＡＭ内へオペレーティングシステムをロードする。
オペレーティングシステムは、コンピューティングプラットフォームのオペレーションのあらゆる態様を制御し、本発明例では、コンパートメントを提供するセキュアオペレーティングシステムである。
加えて、動作中、オペレーティングシステムは、ハードディスク１２からＲＡＭ２２内へ、プラットフォーム１０によって実行することができるプロセスまたはアプリケーションもロードする。
【００２２】
図３の図解は、マシン１（３００）、マシン２（３１０）、およびマシン３（３２０）のラベルが付けられた３つのネットワーク接続されているコンピュータが存在するネットワークシナリオを示している。
マシン１は、ＲＰＣネットワークサービスrpcbind３０１、ypserv３０２、およびrpc.mountd３０３を実行するサーバである。
これらのＲＰＣサービスは、ネットワークカード３０５に対して動的に割り当てられるポート番号３０４を使用する。
マシン２は、セキュアオペレーティングシステム３１２を実行している。
このセキュアオペレーティングシステム３１２は、指定された「ファイル共有」３１３、「アイフェース」（ifaces）３１４、および「データベース」３１５の３つのコンパートメントを定義する。
これらのコンパートメントは、ネットワークカード３１４のポート３１５を使用して通信することができる。
マシン３は、ウェブサーバ３２２を実行している。
ウェブサーバ３２２は、ネットワークカード３２４に対して事前に割り当てられているポート番号８０（３２５）を使用する。
図解の斜線領域は、たとえばＬＡＮによって提供される、マシン間の通信ファブリックまたは通信インフラストラクチャを表している。
第１の斜線領域３３０は、マシン１およびマシン２が原則として互いに通信できることを示し、第２の斜線領域３４０は、マシン２およびマシン３が原則として互いに通信できることを示している。
しかしながら、通信を行うには、（パケットベースまたはストリームベースのいずれかの）論理接続が確立されなければならない。
マシン２のポート８１とマシン３のポート８０との間で通信を行うことを可能にするこのような１つの論理接続は、３５０として指定された実線矢印によって示されている。
【００２３】
既知のセキュアオペレーティングシステムを使用して、マシン２のコンパートメントで動作するエンティティによる、マシン３のウェブサーバ３２２へのアクセスを制御することが可能である。
この既知のセキュアオペレーティングシステムは、固定されたポート番号割り当てと、ポート番号（すなわち、より具体的には、ＮＩＣ、宛先ＩＰアドレス、およびポート番号）に基づくコンパートメント特有の規則とを使用するネットワークサービスへのアクセスを制御することができる。
次に、背景として、この種の例示的な既知の規則を説明する。
この規則は、次のシンタックスを有する。
「アクセス，方向，プロトコル，ポート（ポート番号），ピアポート（ポート番号），コンパートメント」
ここで、アクセスは、付与または拒否に設定される。
方向は、規則がクライアント（コンパートメントからのアウトバウンドメッセージ）に適用されるのか、またはサーバ（コンパートメントへのインバウンドメッセージ）に適用されるのかを指示する。
プロトコルは、たとえば、ＴＣＰまたはＵＤＰ（または他の任意の認識されているプロトコル）として設定することができる。
ポートは、コンパートメントを含むマシンのポートである。
ピアポートは、サービスを含むマシン（またはネットワークエンドポイント）によって使用されるポートである。
コンパートメントは、通信に使用されるネットワーク（またはＬＡＮ）インターフェースに関連付けられているコンパートメントの識別子または名称である。
たとえば、「ファイル共有」と呼ばれる、コンパートメントのアクセス規則は以下のように表され得る。
［従来技術のＭＡＣ規則］
10    compartment File_Sharing {
20        grant server tcp port 81 peer port 80 ifaces
30        deny client tcp port 81 peer port 80 ifaces
40    }
50    compartment ifaces {
60        interface lan0
70    }
【００２４】
このアクセス規則は、以下の意味を有する。
すなわち、ライン１０は、コンパートメントをFile Sharing（ファイル共有）と命名している。
ライン２０は、（サーバによって指定される）リモートコンピュータのＴＣＰポート８０からＴＣＰポート８１へのＴＣＰプロトコルインバウンド通信を受信するためのアクセス制御権をコンパートメントFile Sharingに付与している。
ＴＣＰポート８１は、インターフェースカードが指定するlan0（図示せず）に関連付けられている。
lan0は、それ自体ifaces（アイフェース）と呼ばれるコンパートメントに関連付けられている。
ライン３０は、ＴＣＰポート８１からlan0インターフェースカードを通じてリモートコンピュータのＴＣＰポート８０へＴＣＰ通信を送出するためのアクセス制御権を（クライアントによって指定される）コンパートメントFile Sharingに付与する。
ライン４０は、File Sharingコンパートメントの定義を終了する。
ライン５０は、ifacesと呼ばれるコンパートメントの定義を開始する。
ライン６０は、（File Sharingコンパートメントにライン２０および３０で付与されたように、他の任意のコンパートメントのエンティティが、ifacesコンパートメントにアクセスする許可を有する場合に、lan0インターフェースを介してのみ通信できるように）lan0インターフェースを含むようにifacesコンパートメントを定義する。
ライン７０は、ifacesコンパートメントの定義を終了する。
ポート８０は、ＨＴＴＰに関連付けられるＴＣＰポートであることが知られている。
ＨＴＴＰは、ウェブページを転送するのに使用され、したがって、File Sharingコンパートメントは、上述のアクセス制御規則によって、ウェブサーバと相互作用する許可を付与されている。
【００２５】
マシン１のポート３０５が動的に割り当てられ（したがって、それぞれのポート番号は、未知であるとして「？」のラベルが付けられ）、規則を適用することができないとき、ファイル共有コンパートメント３１３とウェブサーバ３２２との間のアクセスを制御することができるのとは対照的に、マシン１によってホスティングされているＲＰＣサービスへのファイル共有コンパートメント３１３によるアクセスを付与することは（上述したクラスの規則を使用して）可能でなく、同時に、マシン１のＲＰＣサービスへのデータベースコンパートメント３１５によるアクセスを拒否することも可能でない。
【００２６】
一方、本発明の特定の実施形態によれば、説明するように、コンパートメントのそれぞれについて独立したネットワークサービスアクセス制御を達成することができる。
本明細書で詳細に説明するように、本発明の実施形態は、動的に割り当てられるポート割り当てを使用するアクセスネットワークサービスを制御するように設計されている新しいクラスの規則に依存する。
この新しい規則は、例として、以下のように表すことができる。
DPR  G/D  <MODULE>  <STRING>
ここで、DPRは、「Dynamic Port Rule」（動的ポート規則）を表す規則名である。
G/Dは、許可ＧＲＡＮＴ（付与）またはＤＥＮＹ（拒否）である。
<MODULE>は、規則が適用されるネットワークサービス（および対応するモジュールまたは関数、説明する）の名称である。
<STRING>は、命名されたネットワークサービス（および対応するモジュールまたは関数）に関連付けられている一意の識別子（番号、名称、または他の任意の種類の参照子とすることができる）である。
【００２７】
図４の図解は、例示的なセキュアオペレーティングシステムの一部の高レベルの機能表現を提供する。
このセキュアオペレーティングシステムは、本発明の実施形態によるオペレーションに適合されている。
本発明の実施形態は、図４に示す配置にもアーキテクチャにも決して限定されるものではないことを強調しておく。
本発明の特定の実施形態を実施することができるセキュアオペレーティングシステムの一例は、ＨＰ−ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔのバージョン２、リリース１１．３１である。
このＨＰ−ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔは、ＭＡＣを提供するものであり、本明細書で説明するように、ネットワークサービスアクセス規則を、コンパートメント単位で、動的に割り当てられるポートを使用するネットワークサービスに提供するように適合することができる。
しかしながら、本発明の特定の実施形態は、他の既存のセキュアオペレーティングシステム上で実施することができ、本明細書で説明する原理は、ＨＰ−ＵＸ製品のアプリケーションに決して限定されるものではないことが認識されよう。
【００２８】
以下の例では、オペレーティングシステムは、説明するように、コンパートメント規則を使用して（ネットワークサービスに関連して）実施される、ＭＡＣを提供するコンパートメントベースのオペレーティングシステムである。
オペレーティングシステムは、ＵＮＩＸ（登録商標）のようなコマンドと、既知のポート番号を有するネットワークサービスへのアクセスを制御するための既存の規則と、動的に割り当てられるポート番号を有するネットワークサービスへのアクセスを制御するための新しい規則とをサポートする。
この場合も、本発明の実施形態は、ＵＮＩＸ（登録商標）のようなオペレーティングシステムに決して限定されるものではない。
たとえば、これらの原理は、Ｍｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステムにも等しく適用することができるし、さらには、ｂｅｓｐｏｋｅまたは組み込みオペレーティングシステム等を含む、他の任意の種類のオペレーティングシステムにも適用することができる。
【００２９】
図４のオペレーティングシステム４００は、カーネル空間４０２およびユーザ空間４０４を有するものとして示されている。
カーネル空間４０２は、オペレーティングシステムのカーネルを実行するために確保されたメモリである。
カーネルは、一般に、コンピューティングプラットフォームの資源の管理、および、ハードウェアコンポーネントとソフトウェアコンポーネントとの間の通信の管理を担当する。
ユーザ空間４０４は、ユーザアプリケーションが実行されて動作するメモリエリアである。
ユーザ空間４０４は、（時に「標準入力」と呼ばれるマウス１６またはキーボード１４を介して）ユーザからの入力を受け取り、その入力をシステムコールインターフェース４０６に引き渡す。
本発明の文脈では、この入力が、或る種のネットワークサービス要求に関するものであるとき、コマンドが、システムコールインターフェース４０６によってネットワークサービスハンドラ４０８へ渡される。
【００３０】
ネットワークサービスハンドラ４０８は、オペレーティングシステムにおける（または、オペレーティングシステムによってコールされる）ソフトウェアプログラムまたは関数である。
このソフトウェアプログラムまたは関数は、セキュリティコンテインメントコントローラ（Security Containment controller）４１０によって提供されるアクセス制御規則を参照してネットワークサービスコールを処理する。
セキュリティコンテインメントコントローラ４１０は、セキュリティコンテインメント規則関数４１２内にＭＡＣ規則を含む。
セキュリティコンテインメント規則関数４１２は、システムのコンパートメントのそれぞれを定義する一般の規則を含む。
特に、セキュリティコンテインメント規則関数４１２は、本発明の本実施形態によれば、以下でより詳細に説明するように、コンパートメントのネットワークサービスアクセス制御を定義する規則を含む。
【００３１】
ネットワークサービスハンドラ４０８は、コンパートメントに関連付けられている、ネットワークサービスコールを発行したエンティティ（すなわち、ユーザまたはプロセス）がコールの起動および完了に必要なアクセス制御権を有するか否かを、セキュリティコンテインメントコントローラ４１０を参照することによって確認する。
エンティティが権利を有する場合には、ネットワークサービスハンドラ４０８は、既知の方法で関連するネットワークサービスコールを実行し、ＬＡＮカードコントローラ４１４（ＢＩＯＳコールを使用する）と相互作用して、ＬＡＮカード４１６およびＬＡＮ３３０を介してそれぞれのネットワークサービスサーバ３００と相互作用する。
エンティティが権利を有しない場合には、アクセスは従来の方法で拒否される。
【００３２】
特にネットワークサービスアクセス制御規則に関しては、図４に示すように、セキュリティコンテインメント規則関数４１２は、アクセス制御許可を割り当てられる各ネットワークサービスについて、識別されるコンパートメントごとに、エントリー４２０を含むテーブル４１８を含む。
示される例では、「ＦＳ」コンパートメントの１つのテーブルエントリー４２０しか示されていないが、実際には、アクセス制御が必要とされるさまざまなコンパートメントについて多くの規則が存在し得ることが認識されよう。
原則として、コンパートメントは特定の規則を一切必要とせず、その場合に、デフォルトの姿勢は、コンパートメントで動作するエンティティがそれぞれのネットワークサービスへのアクセスを拒否されるということである。
【００３３】
図４に示すように、コンパートメント規則テーブル４１８は、コンパートメント名またはコンパートメントＩＤの列４２０と、モジュール名の列４２２と、ポインタの列４２４とを含む。
ここで、テーブルの各行（すなわち、識別されるコンパートメントの各モジュール名のエントリー）は、対応するポインタを有する。
この例では、（ポインタの列４２４の）ポインタ４２６は、好ましくは、「不透明ポインタ」である。
この不透明ポインタは、当該ポインタが汎用的であるという既知の利点を提供し、その結果、不透明ポインタは、動的なポート番号を使用するあらゆる種類のネットワークサービス（たとえば、ＲＰＣサービスおよびＸＴＥＲＭサービス）をサポートすることができる。
ただし、各種のネットワークサービスに固有の他の種類のポイントを代わりに使用することもできる。
ポイント４２６のそれぞれは、関連するネットワークサービスのＭＡＣ規則を提供する、対応するアクセスチェックモジュール４２８を指し示す。
ＲＰＣネットワークサービスの場合、たとえば（図示するように）、モジュール４２８の名称は、そのサービスを表す「ＲＰＣ」であり、ポイント４２６は、ＲＰＣサービスのアクセスチェックモジュール４２８を指し示す。
既に示したように、このモジュール名は、「ＦＳ」（図３のファイル共有コンパートメントとすることができる）と呼ばれるコンパートメントに関連付けられている。
アクセスチェックモジュール４２８のこのインスタンスでは、（ＲＰＣプログラム番号によって識別される）ＲＰＣサービスへの（ＦＳコンパートメントのエンティティの）アクセスはＧＲＡＮＴである。
【００３４】
各アクセスチェックモジュールは、それぞれのネットワークサービスのＭＡＣ規則を提供する。
各ネットワークサービスが異なるとき、各アクセスチェックモジュールは、適切なそれぞれの機能を備え、通常は、異なる入力要件（すなわち、異なる入力引数）で異なって動作する傾向があるが、それぞれのネットワークサービスへのアクセスをＧＲＡＮＴまたはＤＥＮＹすることになる同じ種類のＭＡＣ出力を有する。
【００３５】
原則として、各種のアクセスチェックモジュールの多数の異なるインスタンスを有することが必要な場合がある。
異なるコンパートメントは、ＲＰＣサービス（または、実際には他の任意のサービス）の異なるアクセス制御要件を有する場合がある（また、おそらく有する）ので、たとえば、ＲＰＣアクセスチェックモジュールの複数のインスタンスが存在する場合がある。
たとえば、規則テーブルの第２のエントリー４３０は、「ＤＢ」コンパートメント（図３のデータベースコンパートメント３１５とすることができる）に関するものである。
ＤＢエントリー４３０のそれぞれのポインタ４３２は、第２のＲＰＣアクセスチェックモジュール４３４を識別する。
この第２のＲＰＣアクセスチェックモジュール４３４は、このインスタンスでは、識別されたＲＰＣサービスへのアクセスを拒否する。
実際には、いずれの特定のネットワークサービスについてもコンパートメント規則がない場合にも、アクセスは拒否されることになり、それによって、拒否されるコンパートメントおよびネットワークサービスのあらゆる組み合わせについてアクセスチェックモジュールが存在する必要があるという事態が回避される。
【００３６】
しかしながら、同じネットワークサービスが、異なるコンパートメントの要件に応じるために、複数のアクセスチェックモジュールを必要とする場合があるが、２つ以上のコンパートメントが所与のネットワークサービスについて同じアクセス制御要件を有する場合に、コンパートメント規則テーブル４１８の２つのそれぞれのエントリーは、同じアクセスチェックモジュールを指し示すことができる。
【００３７】
単なる例示として、コンパートメント規則テーブル４１８の最後のエントリー４４０は、任意のネットワークサービス「ｘｙｚ」に関するものとして示されている。
このネットワークサービス「ｘｙｚ」は、動的に割り当てられるポートを使用する任意のネットワークサービスとすることができる。
それぞれのポインタ４４２は、ネットワークサービスへのアクセスを拒否する適切なアクセスチェックモジュール４４４を指し示す。
【００３８】
図５のフロー図を参照して、例示的なネットワークサービスＭＡＣプロセスを説明する。
この例では、ＲＰＣサービスコールを説明するが、まず、背景理解のためだけに、ＲＰＣサービスを一般的に説明する。
【００３９】
ＲＰＣによる例示的なリモートプロシージャコールは、コール側プロセスがコールメッセージをサーバプロセスへ送信して応答メッセージを待つことを伴う。
このコールメッセージは、プロシージャのパラメータを含み、応答メッセージは、プロシージャを実行したプロシージャ結果を含む。
コール側プロセスは、応答メッセージを受信すると、実行を続ける。
サーバ側では、ＲＰＣサービスは、通常、ドーマントであり、それぞれのＲＰＣコールメッセージの到着を待ち受けている。
ＲＰＣコールメッセージが到着すると、サービスは要求しているコール側プロセスへその後返信する応答を計算する。
【００４０】
一般に、ＲＰＣサービスは少なくとも、自身のＲＰＣプログラム番号、バージョン番号、および当該ＲＰＣサービスに到達することができるトランスポートアドレスによって識別することができる。
バージョン番号は、同じサービスのさまざまな異なるバージョン間を区別するために使用され、大部分は、時間と共にサービスを発展させるのに利用される。
トランスポートアドレスはネットワークアドレスおよびトランスポートセレクタから成る。
ＴＣＰまたはＵＤＰ上で利用可能なサービスの場合、ネットワークアドレスはＩＰアドレスであり、トランスポートセレクタはＴＣＰポート番号またはＵＤＰポート番号である。
コール側プロセスは、サービスを利用するために、そのサービスに対応するＲＰＣプログラム番号、バージョン番号、およびトランスポートアドレスを知っている必要がある。
これらのうち、ＲＰＣプログラム番号およびバージョン番号は、サービス定義の一部としてコール側プロセスに組み込むことができる。
トランスポートアドレスのネットワークアドレスコンポーネントは、通例、（たとえば、ＨＰ−ＵＸのディレクトリパス/usr/sbin/namedに見られる）「named」等のネームサービスデーモンから取得可能であるか、またはコール側プロセスにパラメータとして提供することができる。
本明細書で既に説明したように、ＲＰＣサービスの場合、トランスポートセレクタ（すなわち、ＴＣＰポートまたはＵＤＰポート）は通例、動的に決定され、サービスの各起動と共に変化する。
サーバプログラムは、トランスポートアドレスを配分し、ルックアップサービス（rpcbindまたはbind等）に登録する。
ルックアップサービスは、固定されたトランスポートセレクタ（すなわち、ＴＣＰポート番号１１１）に関連付けられ、サーバと同じネットワークアドレスに存在する。
コール側プロセスは通常、サーバのトランスポートアドレスを取得するために、ルックアップサービスを調べることが可能であり、その後、ＲＰＣサービスを起動して完了することができる。
【００４１】
次に図５に戻って、最初のステップ５００において、システムは、たとえばypserv ＲＰＣサービスのＲＰＣコールを受信する。
このＲＰＣコールは、ypservのＲＰＣプログラム番号を含めて受信される。
プログラム番号は１００００４である。
一般に既知のシステムでは、ＲＰＣコールはマシンにおいて既知のＲＰＣサービス（またはプロセス）によって受信される。
この既知のＲＰＣサービス（またはプロセス）は、rpc_call()と呼ばれ、rpc_call()は、ＲＰＣプログラム番号およびバージョン番号を含む、多数の引数またはパラメータを受信する予定である。
本発明の実施形態によれば、ＲＰＣコールは、システムコールインターフェース４０６によって受信されると、ネットワークサービスコールとして認識され、ネットワークサービスハンドラ４０８に渡される。
ネットワークサービスハンドラ４０８は、rpc_call()プロセスの修正バージョンを組み込む。
このrpc_call()プロセスは、たとえば、以下の形を有する新しいセキュリティコンテインメント関数コールを含めることによって適合されている。
"network_services_mac_access_check(
network_service_name,
rcp_info_pointer,
compartment)."
【００４２】
本発明のypservの例によれば、network_services_mac_access_check()の引数は、
network_service_name="RPC"
rcp_info_pointer=100004
compartment=FS
である。
【００４３】
ＸＴＥＲＭ等の他のサービスの場合、rpc_call()プロセスの均等物は、network_services_mac_access_check()関数コール（すなわち「hook」）を含むようになっている。
ただし、もちろん、パラメータは、ＲＰＣサービスのパラメータではなくＸＴＥＲＭサービスに必要とされるパラメータに一致する。
network_services_mac_access_check ()関数自体は、セキュリティコンテインメントコントローラの一部である。
【００４４】
図５の次のステップ５０５において、network_services_mac_access_check()関数は、ＦＳコンパートメントおよびモジュール名「ＲＰＣ」の双方に対応するエントリーを識別するために、セキュリティコンテインメント規則関数４１２を検索する。
ステップ５１０において、エントリーが存在しない場合には、デフォルトの応答は、アクセス制御要求がステップ５１５において拒否されるというものであり、この応答は、network_services_mac_access_check()関数を介してrpc_call()プロセスに戻され、コール側エンティティには、従来の方法で、アクセスが拒否されることが通知される。
一方、エントリーが存在する場合には（図４によれば、エントリーは存在する）、ステップ５２０において、それぞれの不透明ポインタ４２６が使用されて、対応するアクセスチェックモジュール４２８が識別される。
ステップ５２５において、モジュールが存在しない場合には、この場合も、デフォルトの応答は、アクセス要求がステップ５１５において拒否されるというものである。
モジュールが存在する場合（図４では、「ＲＰＣアクセスチェックモジュール」という名称のものが存在する）には、ステップ５３０において、そのモジュールは、rpc_info_pointer値を使用して、ypservプロシージャのそれぞれのアクセス許可を識別する。
図４の図解の複雑さを低減するために図示されていないが、ＲＰＣアクセスチェックモジュール４３４は、１つ以上のＲＰＣネットワークサービスのアクセス制御規則と、（ＲＰＣプログラム番号によって識別される）指定されたサービスの適切なアクセス制御規則を検索するためのロジックとを定義するテーブルを含む。
ステップ５３５において、アクセス許可が存在し、且つ、ＧＲＡＮＴである場合には、ステップ５４０において、サービスへのアクセスが付与され、許可は、network_services_mac_access_check()関数を介してrpc_call()プロセスへ戻される。
rpc_call()プロセスは、通常の方法によるターゲットＲＰＣサーバとの相互作用でＲＰＣサービスを起動することを引き受ける。
アクセス許可が「ＤＥＮＹ」である（または、指定されたＲＰＣネットワークサービスについて設定されたアクセス許可が存在しない）場合には、アクセス許可は、ステップ５１５において拒否され、応答は、network_services_mac_access_check()関数を介してrpc_call()プロセスへ戻され、コール側エンティティには、従来の方法でアクセスが拒否されことが通知される。
【００４５】
ネットワークサービスアクセス許可は、本発明の実施形態によれば、適切なエントリーをセキュリティコンテインメント規則関数４１２に追加することによって設定される。
セキュリティコンテインメント規則関数４１２は、図４の図解で示すように、セキュリティコンテインメントコントローラ４１０によって使用される。
【００４６】
次に、ＨＰ-ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔセキュアオペレーティングシステムにおいて、本発明の実施形態に従ってネットワークサービスアクセス許可を設定する一例を、「ＦＳ」と呼ばれる例示のコンパートメントについて説明する。
アクセス許可は、他のコンパートメント規則と同様に、database.rulesと呼ばれる（ＨＰ−ＵＸ製品内の）テキストファイルに入力される。
このテキストファイルは以下の形を取る。
compartment FS {
DPR G RPC 100003 {grant access to 'NFS'}
DPR G RPC 100004 {grant access to 'ypserv'}
DPR G RPC 100005 {grant access to 'mountd'}
DPR G RPC 100006 {grant access to 'rpcbind'}
DPR G XTERM putty {grant access to 1st xterm service, 'putty'}
DPR D XTERM refx {deny access to 2nd xterm service, 'refx'}
}
【００４７】
上記は、「ＦＳ」と呼ばれるコンパートメントを定義し、第１のＸＴＥＲＭサービス「putty」へのアクセスを付与すること、および、第２のＸＴＥＲＭサービス「refx」へのアクセスを拒否することに加えて、ＲＰＣサービス「NFS」、「ypserv」、および「mountd」へのアクセスを付与するＭＡＣ規則も定義している。
【００４８】
同様のテキスト構造は、ＭＡＣ規則が必要とされる他のあらゆるコンパートメントについても提供される。
【００４９】
説明してきたように、本発明の実施形態に従って動作するように適合することができるＨＰ−ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔオペレーティングシステムによれば、コンパートメントおよびそれぞれのＭＡＣ規則は通常、システムディレクトリ/usr/sbinに見られる、setrules（規則設定）と呼ばれるプログラムを使用して、セキュリティコンテインメント規則関数４１２内にロードされる。
setrulesプログラムは、database.rulesを解析すると共に、コンパートメントの各規則を順に設定するように構成されている。
setrulesプログラムは、アドミニストレータがdatabase.rulesを記憶しなければならない場所である/etc/cmptと呼ばれるシステムディレクトリからdatabase.rulesを読み出すように構成されている。
【００５０】
システムアドミニストレータは、以下のコマンドラインを使用してsetrulesを実行する。
# /usr/sbin/setrules
【００５１】
図４に示すセキュアオペレーティングシステムは、setrulesプログラムを表す機能ブロック４５０を含む。
既に説明したように、このプログラムは指定されたディレクトリ/usr/sbin/setrulesに存在するが、インターフェースを提供するので、セキュリティコンテインメントコントローラ４１０の一部として示されている。
このインターフェースによって、システムアドミニストレータはカーネルコードおよび関連する定義にアクセスすると共にそれらを生成または修正する必要なく、テキストファイルの定義に基づきコンパートメントをセットアップすることが可能になる。
システムアドミニストレータは、上述したようにコンパートメントのＭＡＣポリシーを定義することによってコンパートメントをセットアップしたいとき、たとえばdatabase.rulesと呼ばれるテキストファイルを生成し、そのテキストファイルを/etc/cmptディレクトリに記憶する。
次に、システムアドミニストレータは、
# /usr/sbin/setrules
等のコマンドラインを発行して、コンパートメントの生成を開始する。
システムコールインターフェース４０６は、このコマンド入力を受信して認識し、アクセス設定ハンドラ（Set Access Handler）４５２へ転送する。
アクセス設定ハンドラ４５２は、次に、setrules関数にアクセスし、コンパートメント定義をロードする。
【００５２】
次に、図６のフロー図を参照して、動的に割り当てられるポート番号を使用するネットワークサービスにアクセスするためのＭＡＣ規則を構築するための例示的なプロセスを説明する。
図６のフロー図は、ＦＳコンパートメントについて上述したコンパートメント定義に基づいている。
【００５３】
図６の最初のステップ６００において、システムコールインターフェース４０６は、setrulesコマンドを受信し、そのコマンドをアクセス設定ハンドラ４５２に渡す。
アクセス設定ハンドラ４５２は、ステップ６０５において、setrulesプログラムを起動する。
setrulesプログラムは、ステップ６１０において、database.rulesファイルにアクセスし、定義テキストの最初のラインを解析する。
この例では、定義ファイルの最初のラインは、「ＦＳ」と呼ばれる新しいコンパートメントを定義する。
ステップ６１５において、ラインがコンパートメント定義ラインである場合には、ステップ６２０において、新しいコンパートメントエントリーがセキュアオペレーティングシステムのコンパートメントリスト（図示せず）に追加され、後続のあらゆるＭＡＣ規則がそのコンパートメントに関連付けられ、プロセスはステップ６１０に戻る。
ステップ６１０において、定義テキストの次のラインが解析される。
ステップ６１５において、ラインがコンパートメントのＤＰＲ規則である場合には、プロセスはステップ６２５に続く。
この例では、ＤＰＲ規則のプロセスしか含まれていないが、他の既知のプロシージャおよび同等のプロシージャがこのような他の規則の種類について提供されることが認識されよう。
ステップ６２５において、プロセスは（<MODULE>フィールドを使用して）、規則が既存のアクセスチェックモジュールへの追加であるか、または、規則が新しいアクセスチェックモジュールの生成を必要としているかを識別する。
規則が新しいアクセスチェックモジュールに関するものである場合、ステップ６３０において、このプロセスは、それぞれのアクセスチェックモジュールの適切なＲＰＣサービステンプレートを見つけ（ＲＰＣサービステンプレートでは、規則を設定することができる既知の各サービスが、特定のアクセスチェックモジュールのフレームワークを提供する事前に定義されているテンプレートを有する）、（識別子としての<MODULE>フィールド、ＲＰＣプログラム番号フィールドを満たす<STRING>値１００００３、および許可であるＧ／Ｄ値を使用して）新しいアクセスチェックモジュールを生成する。
ステップ６３５において、このプロセスはエントリーを規則テーブル４１８に追加する。
このエントリーは、コンパートメントＩＤを含む第１のフィールド４２０、モジュール名を含む第２のフィールド４２２、および（第３のフィールド４２４の）不透明ポインタを含む。
この不透明ポインタはテーブルエントリーをアクセスチェックモジュールコードに向けるものである。
次に、ステップ６４０において、このプロセスは規則が定義内にさらに存在するか否かを判断する。
定義する規則がさらに存在する場合には、このプロセスはステップ６１０に戻って、定義の次のラインを解析する。
定義する規則がそれ以上存在しない場合には、このプロセスはステップ６４５において終了する。
【００５４】
ステップ６２５において、新しい規則が既存のアクセスチェックモジュールに追加されると判断された場合には、ステップ６５０において、このプロセスは、ＲＰＣプログラム番号フィールドを満たす<STRING>値１０００３、および許可であるＧ／Ｄ値を使用して、既存のアクセスチェックモジュールにエントリーを追加する。
このプロセスは次に、ステップ６４０に続く。
【００５５】
図６のプロセスは、新しい規則が発見されなくなるまで定義内の規則ごとに繰り返され、そして、プロセスは終了する。
その結果、規則テーブルは、セキュアオペレーティングシステムによってネットワークサービスへのアクセスを制御するのに必要とされるすべてのコンパートメント規則への参照子でポピュレートされる。
【００５６】
上記実施形態は本発明の説明例として理解されるべきである。
本発明のさらなる実施形態が予想される。
ＨＰ−ＵＸ  Ｓｅｃｕｒｉｔｙ  Ｃｏｎｔａｉｎｍｅｎｔセキュアオペレーティングシステムを適合させることによって本発明の特定の実施形態を実施できることが示されたが、ＳＥＬｉｎｕｘ（商標）またはＴｒｕｓｔｅｄ  Ｓｏｌａｒｉｓ（商標）等の他の既知のセキュアオペレーティングシステム、または実際には、動的に割り当てられるポートを使用するネットワークサービスにアクセスするためのコンパートメント規則を定義するように適合することができる他の任意のセキュアオペレーティングシステムを適合させることによって、他の実施形態を実施することができる。
【００５７】
本発明の実施形態は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせの形で実現することができることが認識されよう。
このようなどのソフトウェアも、たとえば、消去可能であろうとなかろうと、再書き込み可能であろうとなかろうと、ＲＯＭのようなストレージデバイス等の揮発性ストレージまたは不揮発性ストレージの形で記憶することもできるし、たとえば、ＲＡＭ、メモリチップ、デバイス、または集積回路等のメモリの形で記憶することもできるし、たとえば、ＣＤ、ＤＶＤ、または磁気ディスク、磁気テープ等の光可読媒体または磁気可読媒体に記憶することもできる。
これらのストレージデバイスおよびストレージ媒体は、実行されると本発明の実施形態を実施する１つ以上のプログラムを記憶するのに適したマシン可読ストレージの実施形態であることが認識されよう。
したがって、実施形態は、先行するいずれかの請求項に記載のシステムまたは方法を実施するためのコードを含むプログラム、および、このようなプログラムを記憶する機械可読ストレージを提供する。
またさらに、本発明の実施形態は、有線接続または無線接続によって運ばれる通信信号等のあらゆる媒体を介して電子的に搬送することもでき、実施形態はそれらも適切に包含する。
【００５８】
本明細書（添付のあらゆる請求項、要約書、および図面を含む）に開示された機能のすべて、および／または、そのように開示されたあらゆる方法若しくはプロセスのステップのすべては、このような機能および／またはステップの少なくともいくつかが相互に排他的である組み合わせを除いて、任意の組み合わせで組み合わせることができる。
【００５９】
本明細書（添付のあらゆる請求項、要約書、および図面を含む）に開示した各機能は、明示的に別段の定めをした場合を除き、同じ目的、等価な目的、または類似の目的を果たす代替的な機能に置き換えることができる。
したがって、明示的に別段の定めをした場合を除き、開示された各機能は、一般的な一連の等価な機能または類似の機能の一例にすぎない。
【００６０】
本発明は、上記のいずれの実施形態の詳細にも限定されるものではない。
本発明は、本明細書（添付したあらゆる請求項、要約書、および図面を含む）に開示した機能の新規ないずれのものにも若しくは新規ないずれの組み合わせにもおよび、または、そのように開示されたあらゆる方法またはプロセスのステップの新規ないずれのものにも若しくは新規ないずれの組み合わせにも及ぶ。
特許請求の範囲は、上記実施形態のみを包含するように解釈されるべきではなく、特許請求の範囲の範中に含まれるあらゆる実施形態も包含するように解釈されるべきである。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施形態によるオペレーションに適した例示的なコンピューティング環境を示す図解である。
【図２】図１に示す種類のコンピューティングプラットフォームと共に使用するための例示的なマザーボードを示す図解である。
【図３】分散コンピューティング環境における３つのコンピューティングプラットフォームを示す概略図解である。第１のプラットフォームはＲＰＣサーバとして動作し、第２のプラットフォームはコンパートメント化されたオペレーティングシステムを実行するクライアントとして動作し、第３のプラットフォームはウェブサーバとして動作する。
【図４】本発明の一実施形態を実施するのに必要なセキュアオペレーティングシステムの機能要素を示す概略図解である。
【図５】本発明の一実施形態によるネットワークサービスへのアクセスを制御することに関与するステップを示すフロー図である。
【図６】動的なポート割り当てを使用するネットワークサービスの新しいコンパートメント強制アクセス制御規則を定義することに関与するステップを示すフロー図である。
【符号の説明】
【００６２】
３００・・・マシン１，
４０２・・・カーネル空間，
４０４・・・ユーザ空間，
４０６・・・システムコールインターフェース，
４０８・・・ネットワークサービスハンドラ，
４１０・・・セキュリティコンテインメントコントローラ，
４１２・・・セキュリティコンテインメント規則，
４１４・・・ＬＡＮカードコントローラ，
４１６・・・ＬＡＮカード，
４２０・・・コンパートメントＩＤ，
４２２・・・モジュール名，
４２４・・・ポインタ，
４２８・・・ＲＰＣアクセスチェックモジュール，
４５２・・・アクセス設定ハンドラ，
【図１】
2009009566.tif 000003
【図２】
2009009566.tif 000004
【図３】
2009009566.tif 000005
【図４】
2009009566.tif 000006
【図５】
2009009566.tif 000007
【図６】
2009009566.tif 000008
【外国語明細書】
ACCESS CONTROL SYSTEM AND METHOD
Field of the Invention
The present invention relates to access rights in computer systems.
Background of the Invention
Operating systems are typically computer programs or sets of computer programs that are loaded into a computer's memory and executed in order to control the subsequent operation of a computer.  However, operating systems can also be embedded programs in firmware or hardware, particularly, for example, in portable devices such as mobile telephones and PDAs
Most, traditional computer operating systems offer some kind of logical protection to data in the form of access controls, which can be granted or denied to specific people or groups of people.  Generally, in a system that offers discretionary access control (DAC) a user (as opposed to an administrator) is able to assign permissions to their data, which permit or deny others (or groups of others) access to the data.  This is fine for individuals.  However, some organisations, such as military or government organisations in particular, require the ability to more closely control access to information.  For example, top secret information should not be visible to most people in an organisation, restricted information, as the label suggests, should not be generally available, whereas unrestricted information may be available for access by anyone in an organisation. 
Accordingly, secure operating systems are known, which provide greater access control over an organisation's information.  Typically, secure operating systems associate additional classifications or labels with files and apply so-called mandatory access control (MAC), which provides a means of restricting access to the files based on their sensitivity (for example, as represented by a sensitivity label).  In contrast to DAC, under MAC a user does not have the right to determine who sees their data: only users having a compatible clearance are permitted to see the data.  For example, a user with top secret clearance would not have the ability to permit others with a lesser clearance to see their data.
MAC can be expressed in terms of "compartments".  In practice, a compartment is typically a logical construct having an identifier such as a name, applied to which are a set of administrator-configured access control rules that define the compartment.  Compartment rules are used to permit access only to those resources (such as files, processes and inter-process communication methods) necessary for an application to execute.  These rules apply both to users and processes that have permission to operate in the compartment, and, accordingly, unless otherwise stated or unless the context dictates otherwise, such users and processes will be referred to herein generally as "entities".
Thus, entities operating within a compartment can by default only access files, other process and resources that are defined to be accessible in the same compartment, unless specific MAC rules are provided to the contrary.
Compartments can provide an isolated runtime environment for an application, wherein the compartment rules allow access to only those resources that are necessary for the application to execute.  This increases the likelihood that, even when an application is compromised, the damage is limited only to the compartment(s) where the application is running.
In addition to controlling access to file systems and the like, it is known for MAC to be used to control access to resources that are outside of a compartment, such as network end-points providing remote services generally and, more particularly, network services, by defining MAC rules, which grant or deny access to particular communications interfaces of a computing platform.  As used herein, the term "network (or networked) service" is a computer program, which runs on a remote computer, or server, in a distributed computing environment of networked computers.  Network services can be accessed, invoked, or "called", from a client (for example a host running a secure operating system), which is remote from the server running the service.  Examples of network services are RPC services (such as ypserv, mountd etc), Web sites, X-terminals and FTP sites, to name just a few of the well-known services.
The ability to control access to network services increases security, by providing mechanisms for preventing an entity from accessing network services that may have been, or may in future be, compromised.  The most common way in which a network service can be compromised is from a denial-of-service-attack, which floods the service (or server running the service) with dummy requests for service, in an attempt to render the service unavailable to legitimate users.
One known way of defining MAC for resource access is based on so-called labelled security protection profiles (LSPP), where the resource (for example, a network end-point) is arranged to carry a label that specifies the access control policy on the resource.  However, implementing MAC in this way requires a significant amount of effort and adaptation to traditional applications and operating systems.  A known simpler way of defining MAC for resource access is based on using access control rules, which are specified for each individual compartment.  Such control rules typically use TCP port numbers to uniquely identify network end-points, for example network services.  Many network services use well-known, pre-assigned port numbers; for example, HTTP uses TCP port 80, POP3 uses port 110 and IRC uses port 194.  In such cases, it is possible to grant or deny access to the services by granting or denying access to the respective ports using MAC rules.  However, some network services, such as RPC services and XTERM services, do not use pre-assigned port numbers (that is, the port numbers are allocated or assigned dynamically at run time) and it is, therefore, not possible to grant or deny access by specifying port number in compartment rules.  In the absence of such access control, if any such network service is compromised, then it may not be easy to contain or control the damage that can be done to an otherwise secure system.
It is an object of embodiments of the invention to at least mitigate one or more of the problems of the prior art. 
Summary of the Invention
In accordance with one aspect of the present invention, there is provided an access control system defining one or more compartments and providing rules, which are applied to the compartment(s), to control access to network services by entities that are associated with a said compartment, the rules comprising at least a first kind of rule for controlling access to network services that use dynamically-assigned communications ports.
In accordance with another aspect of the present invention, there is provided an access control method comprising:
receiving a network service call from a requesting entity, which is associated with a compartment of a secure operating system, the said network service using a dynamically assigned communications port;
determining, with respect to any rules that have been applied to the compartment, whether the entity has permission to access the network service; and
processing the network service call only if an applied compartment rule grants permission to access the network service.
In accordance with yet another aspect of the present invention, there is provided a data processing system arranged to process a network service call, comprising:
an input for receiving, from an entity that is associated with a compartment of the system, a call for a network service that uses a dynamically assigned communications port;
a store storing rules that are applied to compartments and which define associated network service access permissions; and
a process which enacts the network service call only if the store contains a said compartment rule that grants permission to access the network service.
Known secure operating systems are SELinux(tm), Trusted Solaris(tm) and HP-UX Security Containment(tm), and embodiments of aspects of the present invention can be applied to these operating systems, although the principles taught are more widely applicable.
Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.  
Brief Description of the Drawings
Figure 1 is a diagram showing an exemplary computing environment suitable for operation according to embodiments of the present invention;
Figure 2 is a diagram showing an exemplary motherboard for use with a computing platform of the kind shown in Figure 1;
Figure 3 is a schematic diagram illustrating three computing platforms in a distributed computing environment; the first platform operating as an RPC server, the second one operating as a client executing a compartmented operating system and the third one operating as a Web server;
Figure 4 is a schematic diagram illustrating the functional elements of a secure operating system that are necessary for implementing an embodiment of the present invention;
Figure 5 is a flow diagram showing steps involved in controlling access to a network service according to an embodiment of the present invention; and
Figure 6 is a flow diagram showing the steps involved in defining new compartment Mandatory Access Control rules for network services which use dynamic port assignments.
Detailed Description of the Invention
While it is known to be able to control access to (or use of) network services, which use known port numbers, embodiments of the present invention relate to a new class of compartment rule, which controls access to (or use of) network services which use dynamically assigned port numbers.
Before describing embodiments of the invention in detail, a computing environment suitable for implementing certain embodiments of the invention will now be described. 
An exemplary computing platform 10 suitable for implementing embodiments of the invention is illustrated in the diagram in Figure 1.  The computing platform 10 has 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.  The platform contains standard components such as a mother board and a hard disk drive for storing a file system.
As illustrated in Figure 2, the motherboard 20 of the computing platform 10 includes (among other standard components) a main processor 21, main memory 22, a data bus 26 and respective addressing lines 27 and control lines 28, BIOS memory 29 containing the BIOS program for the platform 10 and an Input/Output (IO) controller 25.  The IO controller 25 (which may comprise one or more independent subsystems) controls interaction between the components of the motherboard and connected devices such as the keyboard 14 and the mouse 16 (via an input controller 253), the VDU 18 (via an output controller 254, for example a screen or graphics controller), a storage device 12 such as a hard disk (via a storage controller 252) and the outside world (via a network controller 251, for example an Ethernet LAN controller), which may be embodied on a network interface card (NIC).  Communications with the outside world, for example across the Internet, are directed via the network controller 251 and, typically, include data packets.  In known systems, the data packets are typically addressed to travel via a logical port number of a NIC or the like, as will be described in more detail hereinafter.
The main memory 22 is typically random access memory (RAM) and the BIOS memory is typically EEPROM, which can be 'flashed' with BIOS updates.  In operation, the platform 10 loads the BIOS from the BIOS memory 29 and, in turn, loads an operating system from the hard disk 12 into RAM.  The operating system controls every aspect of the operation of the computing platform and, in the present example, is a secure operating system that provides compartments.  Additionally, in operation, the operating system loads the processes or applications that may be executed by the platform 10 into RAM 22 from hard disk 12.
The diagram in Figure 3 illustrates a network scenario wherein there are three networked computers labelled Machine 1 (300), Machine 2 (310) and Machine 3 (320).  Machine 1 is a server which runs the RPC network services rpcbind 301, ypserv 302 and rpc.mountd 303.  These RPC services use dynamically assigned port numbers 304 on a network card 305.  Machine 2 is running a secure operating system 312, which defines three compartments, designated 'File Sharing' 313, 'ifaces' 314 and 'Database' 315, which can communicate using ports 315 of a network card 314.  Machine 3 is running a Web Server 322, which uses the pre-assigned port number 80 (325) on a network card 324.  The shaded regions in the diagram represent a communications fabric or infrastructure, for example provided by a LAN, between the machines: a first shaded region 330 illustrates that Machine 1 and Machine 2 can in principle communicate with each other and a second shaded region 340 indicates that Machine 2 and Machine 3 can in principle communicate with each other.  However, for communications to take place, logical connections (either packet or streams based) have to be established.  One such logical connection, which permits communications to take place between port 81 of Machine 2 and port 80 of Machine 3, is shown by a solid arrow designated as 350. 
It is possible to control access, by an entity operating in a compartment of Machine 2, to the Web Server 322 on Machine 3, using known secure operating systems, which can control access to network services that use fixed port number assignments and compartment-specific rules based on port number (or, more specifically, NIC, destination IP address and port number).  An exemplary known rule of this kind will now be described by way of background and has the syntax:
"access, direction, protocol, port (port number),
peer port (port number), compartment",
where: access is set to grant or deny; direction dictates whether the rule applies to a client (outbound message from compartment) or to a server (inbound message to compartment); protocol can be set, for example, as TCP or UDP (or any other recognised protocol); port is a port of the machine containing the compartment; peer port is the port used by the machine containing the service (or network endpoint); and compartment is an identifier or name of a compartment which is associated with the network (or LAN) interface, which is used for the communications.  For example, an access rule for a compartment called "File Sharing" might appear as:
[prior art MAC rule]
10    compartment File_Sharing {
20        grant server tcp port 81 peer port 80 ifaces
30        deny client tcp port 81 peer port 80 ifaces
40    }
50    compartment ifaces {
60         interface lan0
70    }
This access rule has the following meaning: line 10 names the compartment as File Sharing; line 20 grants the access control right to compartment File Sharing to receive from TCP port 80 of a remote computer (designated by server), TCP-protocol inbound communications to TCP port 81, which is associated with the interface card designated lan0 (not shown), which itself is associated with the compartment called ifaces; line 30 grants the access control right to compartment File Sharing (designated by client) for outgoing TCP communications from TCP port 81, through the lan0 interface card to TCP port 80 of a remote computer; line 40 ends the definition of the File Sharing Compartment; line 50 begins a definition of a compartment called ifaces; line 60, defines the ifaces Compartment to contain the lan0 interface (such that an entity of any other compartment can only communicate via the lan0 interface if it has permissions to access the ifaces compartment, as has been granted in lines 20 and 30 to the File Sharing Compartment); and line 70 ends the definition of the ifaces Compartment.  It is known that Port 80 is the TCP port associated with HTTP, which is used for transferring web pages and, therefore, the File Sharing Compartment has, by the foregoing access control rules, been granted permission to interact with a Web Server.
In contrast with the ability to control access between the File Sharing Compartment 313 and the Web Server 322, it is not possible (using the class of rules described above) to grant access by the File Sharing Compartment 313 to the RPC services hosted by Machine 1, while at the same time denying access by the Database Compartment 315 to the RPC services on Machine 1; as the ports 305 on Machine 1 are dynamically assigned (and the respective port numbers are, therefore, labelled "?" as being unknown) and the rules cannot be applied.
However, according to certain embodiments of the present invention, as will be described, independent network service access control for each of the compartments can be achieved.  As will be described in detail herein, embodiments of the present invention depend on a new class of rule, which is designed to control access network services which use dynamically assigned port assignments.  The new rule can be represented, by way of example, as follows:
DPR    G/D    <MODULE>    <STRING>
where: DPR is the rule name, which represents "Dynamic Port Rule"; G/D is the permission GRANT or DENY; <MODULE> is the name of the network service (and a corresponding module or function, which will be described) to which the rule applies; and <STRING> is a unique identifier (which could be a number, a name or any other kind of reference) that is associated with the named network service (and the corresponding module or function).
The diagram in Figure 4 provides a high-level functional representation of a portion of an exemplary secure operating system, which has been adapted for operation according to the present embodiment.  It is emphasised that embodiments of the invention are in no way limited to the arrangement or architecture illustrated in Figure 4.  One example of a secure operating system on which certain embodiments of the invention may be practiced is HP-UX Security Containment, version 2, release 11.31, which provides MAC and can be adapted as described herein to offer network services access rules, on a per-compartment basis, to network services that use dynamically-assigned ports.  It will be appreciated, however, that certain embodiments of the invention may be implemented on other existing secure operating systems, and the principles described herein are in no way limited to application in the HP-UX product.
In the example that follows, the operating system is a compartment-based operating system offering MAC, which is implemented (in relation to network services) using compartment rules, as will be described.  The operating system supports UNIX-like commands, existing rules for controlling access to network services that have known port numbers, and the new rule for controlling access to network services that have dynamically assigned port numbers.  Again, embodiments of the invention are in no way limited to UNIX-like operating systems.  For example, the principles could be applied equally to a Microsoft(tm) Windows(tm) based operating system or, indeed, to any other kind of operating system, including bespoke or embedded operating systems or the like.
The operating system 400 in Figure 4 is shown having a Kernel Space 402, which is memory reserved for running the kernel of the operating system, and a User Space 404.  The kernel is generally responsible for managing the computing platform's resources and the communications between the hardware and software components.  The User Space 404 is a memory area where user applications execute and operate.  The User Space 404 receives input from the user (via the mouse 16 or keyboard 14 - sometimes referred to as the 'standard input') and passes it on to a System Call Interface 406.  In the present context, when the input relates to a network services request of some kind, the command is passed by the System Call Interface 406 to a Network Services Handler 408.
The Network Services Handler 408 is a software program or function in the operating system (or called by the operating system) that processes network service calls with reference to access control rules which are provided by a Security Containment Controller 410.  The Security Containment Controller 410 contains MAC rules in a Security Containment Rules function 412.  The Security Containment Rules function 412 contains the rules in general defining each of the compartments of the system.  In particular, the Security Containment Rules function 412, according to the present embodiment of the invention, includes rules defining network service access controls for compartments, as will be described below in more detail.
The Network Services Handler 408 establishes, by reference to the Security Containment Controller 410, if an entity (that is, a user or a process), which is associated with a compartment, and which has issued a network services call, has the access control rights necessary for the call to be invoked and completed.  If the entity has the rights then the Network Service Handler 408 executes the associated network services call, in a known way, and interacts with a LAN Card Controller 414 (which uses BIOS calls), to interact with a respective network services server 300 via a LAN card 416 and LAN 330.  If the entity does not have the rights, then access is denied in the traditional manner.
In relation in particular to the network services access control rules, as shown in Figure 4, the Security Containment Rules function 412 includes a table 418 containing entries 420, for each identified compartment, for each network service that has been assigned access control permissions.  In the example shown, only one table entry 420 for the "FS" Compartment is shown; and it will be appreciated that, in practice, there may be many rules for various compartments for which access controls are required.  In principle, a compartment does not need any particular rule, in which case the default position is that entities operating in the compartment are denied access to respective network services.
As shown in Figure 4, the compartment rules table 418 comprises a compartment name or ID column 420, a module name column 422 and a pointer column 424, where each row of the table (that is, each module name entry for an identified compartment) has a corresponding pointer.  In this example, the pointers 426 (in the pointer column 424) are preferably 'opaque pointers', which provides the known advantage that the pointer is generic, so that it can support any kind of network service that uses dynamic port numbers (for example, RPC services and XTERM services), although, other kinds of pointer, which are specific to each kind of network service, may be used instead.  Each of the pointers 426 points to a corresponding Access Check Module 428, which provides the MAC rule for the associated network service.  In the case of the RPC network service, for example (and as illustrated), the module 428 name is "RPC", representing the service, and the pointer 426 points to an Access Check Module 428 for the RPC service.  As already indicated, this module name is associated with a compartment called "FS" (which could be the File Sharing Compartment of Figure 3).  In this instance of the Access Check Module 428, access (for entities in the FS compartment) to the RPC service (identified by RPC Prog Number) is GRANT.
Each Access Check Module provides the MAC rules for the respective network service.  As each network service is different, each Access Check Module will comprise appropriate respective functionality and will tend to operate in a different way, typically with different requirements for input (that is, different input arguments), but having the same kind of MAC output, which will be to GRANT or DENY access to the respective network service.
In principle, it may be necessary to have a number of different instances of each kind of Access Check Module; for example, there may be plural instances of the RPC Access Check Module, since different compartments may (and likely will) have different access control requirements for the RPC service (or, indeed, any other service).  For example, the second entry 430 in the rules table relates to the "DB" compartment (which could be the Database Compartment 315 in Figure 3).  A respective pointer 432 for the DB entry 430 identifies a second RPC Access Check Module 434, which, in this instance, denies access to the identified RPC service.  Indeed, absence of a compartment rule for any particular network service would also lead to the access being denied, thereby avoiding the situation where there needs to be an Access Check Module for every combination of defined compartment and network service. 
However, while the same network service may need multiple Access Check Modules to cater for the requirements of different compartments, if two or more compartments have the same access control requirements for a given network service, then two respective entries in the compartment rules table 418 may point to the same Access Check Module.
By way of illustration only, the last entry 440 in the compartment rules table 418 is shown to relate to an arbitrary network service 'xyz', which could be any network service which uses dynamically-assigned ports, and a respective pointer 442 points to an appropriate Access Check Module 444, which denies access to the network service.
An exemplary network service MAC process will be described with reference to the flow diagram in Figure 5.  In this example, an RPC service call will be described, but, first, for background understanding purposes only, the RPC service will be described in general terms.
An exemplary remote procedure call according to RPC involves a caller process sending a call message to a server process and waiting for a reply message.  The call message contains the parameters of the procedure and the reply message contains the procedure results of running the procedure.  When the caller process receives the reply message, it continues executing.  On the server side, the RPC service is typically dormant, awaiting the arrival of a respective RPC call message.  When an RPC call message arrives, the service computes a reply that it then sends back to the requesting caller process.
In general, an RPC service may be identified at least by its RPC program number, version number, and a transport address where it may be reached.  A version number is used to differentiate between various different versions of the same service, and is mostly utilised to evolve the service over time.  The transport address, in turn, consists of a network address and a transport selector.  In the case of a service available over TCP or UDP, the network address is an IP address, and the transport selector is a TCP or UDP port number.  A caller process needs to know the RPC program number, version number, and the transport address corresponding to a service in order to utilize the service.  Of these, the RPC program number and version number may be built into the caller process as part of the service definition.  The network address component of the transport address is usually obtainable from a name service daemon, such as "named" (for example, found in HP-UX in the directory path /usr/sbin/named), or may be provided as a parameter to the caller process.  As already explained herein, for RPC services, the transport selector (that is, the TCP or UDP port) is usually determined dynamically, and varies with each invocation of the service.  Server programs allocate a transport address, and register it with a lookup service (such as rpcbind, or bind), which is associated with a fixed transport selector (that is, TCP port number 111), and resides at the same network address as the server.  Caller processes are typically able to consult the lookup service in order to obtain the server's transport address, following which the RPC service can be invoked and completed.
Now, returning to Figure 5, in a first step 500 the system receives an RPC call, for example, for the ypserv RPC service.  The RPC call is received including the RPC program number for ypserv, which is 100004.  Generally, in known systems, RPC calls are received in a machine by a known RPC service (or process), which is called rpc_call(), which expects to receive a number of arguments or parameters, including RPC program number and version number.  According to the present embodiment, when the RPC call is received by the System Call Interface 406, it is recognised as a network service call and passed to the Network Services Handler 408.  The Network Services Handler 408 incorporates a modified version of rpc_call() process.  The rpc_call() process is adapted by the inclusion of a new security containment function call, for example having the form:
"network_services_mac_access_check (
network_service_name,
rpc_info_pointer,
compartment)."
According to the present ypserv example, the network_services_mac_access_check() arguments are:
network_service_name = "RPC"
rpc_info_pointer = 100004
compartment = FS
For other services, such as XTERM, an equivalent to the rpc_call() process would be adapted to include a network_services_mac_access_check() function call (or 'hook'), although, of course, the parameters would match those required for the XTERM service rather than those for the RPC service.  The network_services_mac_access_check() function itself is part of the Security Containment Controller.
In the next step 505 in Figure 5, the network_services_mac_access_check() function searches the Security Containment Rules function 412 to identify an entry which corresponds both to the FS compartment and to the Module Name "RPC".  In step 510, if an entry does not exist, then the default response is that the access control request is denied in step 515, and the response is passed back, via the network_services_mac_access_check() function to the rpc_call() process, and the calling entity is informed in the traditional way that access is denied.  If, however, the entry exists (which it does according to Figure 4), then, in step 520, the respective opaque pointer 426 is used to identify the corresponding Access Check Module 428.  If the module does not exist, in step 525, then, again, the default response is that the access request is denied in step 515.  If the module exists (which is does, named "RPC Access Check Module" in Figure 4) then, in step 530, the module uses the rpc_info_pointer value to identify a respective access permission for the ypserv procedure.  Although not illustrated in order to reduce complexity in the diagram in Figure 4, the RPC Access Check Module 434 contains a table defining the access control rules for one or more RPC network services and logic for searching for an appropriate access control rule for the specified service (identified by the RPC Prog Number).  In step 535, if the access permission is present and is GRANT, then, in step 540, access to the service is granted, and permission is passed back via the network_services_mac_access_check() function to the rpc_call() process, which undertakes to invoke the RPC service in interactions with the target RPC server in the normal way.  If the access permission is "DENY" (or there is no access permission set for the specified RPC network service), then the access permission is denied, in step 515, the response is passed back, via the network_services_mac_access_check() function to the rpc_call() process, and the calling entity is informed in the traditional way that access is denied.
Network service access permissions are set according to the present embodiment by adding appropriate entries to the Security Containment Rules function 412, which is used by the Security Containment Controller 410, as illustrated in the diagram in Figure 4.
An example of setting network service access permissions, according to embodiments of the present invention, in the HP-UX Security Containment secure operating system, will now be described for the exemplary compartment called "FS".  The access permissions, like other compartment rules, are entered into a text file (in the HP-UX product) called database.rules.  The text file takes the following form:
compartment FS {
DPR    G    RPC    100003 {grant access to 'NFS'}
DPR    G    RPC    100004 {grant access to 'ypserv'}
DPR    G    RPC    100005 {grant access to 'mountd'}
DPR    G    RPC    100006 {grant access to 'rpcbind'}
DPR    G    XTERM    putty {grant access to 1st xterm service, 'putty'}
DPR    D    XTERM    refx {deny access to 2nd xterm service, 'refx'}
}
The above defines a compartment called 'FS' and defines MAC rules granting access to the RPC services 'NFS', 'ypserv' and 'mountd', in addition to granting access to a first XTERM service 'putty' and denying access to a second XTERM service 'refx'.
A similar text structure would be provided for every other compartment for which MAC rules are required.
According to the HP-UX Security Containment operating system, which, as has been described, can be adapted to operate according to embodiments of the present invention, compartment and respective MAC rules are typically loaded into the Security Containment Rules function 412 using a program called setrules, which is found in the system directory /usr/sbin.  The setrules program is arranged to parse database.rules and set each rule for a compartment in turn.  The setrules program is arranged to read database.rules from a system directory called /etc/cmpt, which is where the systems administrator must store database.rules.
The system administrator executes setrules using the following command line:
# /usr/sbin/setrules
The secure operating system illustrated in Figure 4 includes a functional block 450 representing the setrules program.  As already described, the program resides in a specified directory /usr/sbin/setrules, but is shown as part of the Security Containment Controller 410, as it provides an interface, which enables a systems administrator to set up compartments on the basis of a text file definition, rather than having to access and generate or modify kernel code or associated definitions.  When a systems administrator wishes to set up a compartment by defining its MAC policy as described above, they generate a text file, for example called database.rules, and store it in the /etc/cmpt directory.  They then issue a command line such as:
# /usr/sbin/setrules
to initiate the generation of the compartment.  The System Call Interface 406 receives the command input, recognises it and forwards it to a Set Access Handler 452, which in turn accesses the setrules function and loads the compartment definitions.
An exemplary process for building a MAC rule for accessing a network service which uses a dynamically assigned port number will now be described with reference to the flow diagram in Figure 6, which is based on the compartment definition described above for the FS compartment.
In a first step 600 in Figure 6, the System Call Interface 406 receives a setrules command and passes it to the Set Access Handler 452.  The Set Access Handler 452 invokes the setrules program in step 605.  The setrules program accesses the database.rules file and parses the first lines of definition text in step 610.  In this example, the first line of the definition file defines a new compartment called "FS".  In step 615, if the line is a compartment definition line then, in step 620, a new compartment entry is added to a compartment list (not shown) for the secure operating system, any subsequent MAC rules are associated with that compartment and the process returns to step 610 wherein the next line of definition text is parsed.  If, in step 615, the line is a DPR rule for a compartment, then the process continues with step 625.  In this example, only the process for the DPR rule is included, and it will be appreciated that other known and equivalent procedures would be provided for such other rule kinds.  In step 625, the process identifies (using the <MODULE> field) if the rule is an addition to an existing Access Check Module or if the rule requires the generation of a new Access Check Module.  If the rule relates to a new Access Check Module, in step 630 the process finds an appropriate RPC service template for a respective Access Check Module (where each known service for which a rule may be set has a pre-defined template, providing the framework for a specific Access Check Module) and generates a new Access Check Module (using the <MODULE> field as the identifier, the <STRING> value 100003 to fill the RPC Prog Number field and the G/D value is the permission).  In step 635, the process adds an entry to the rules table 418; the entry comprising a first field 420 containing the compartment ID, a second field 422 containing the module name and an opaque pointer (in the third field 424), which points the table entry to the Access Check Module code.  Next, in step 640, the process determines if there are any more rules in the definition.  If there are more rules to define, then the process returns to step 610 to parse the next line of the definition.  If there are no more rules to define then the process ends in step 645.
If, in step 625, it is determined that the new rule adds to an existing Access Check Module, then, in step 650, the process adds an entry to the existing Access Check Module using the <STRING> value 100003 to fill the RPC Prog Number field and the G/D value is the permission.  The process then continues with step 640.
The process in Figure 6 repeats for each rule in the definition until no new rules are found and the process ends.  The result is that the rules table is populated with references to all compartment rules that are needed for controlling access to network services by the secure operating system.
The above embodiments are to be understood as illustrative examples of the invention.  Further embodiments of the invention are envisaged.  While it has been indicated that certain embodiments of the invention may be implemented by adapting an HP-UX Security Containment secure operating system, other embodiments may be implemented by adapting other known secure operating systems such as SELinux(tm) or Trusted Solaris(tm), or, indeed, any other secure operating system that can be adapted to define compartment rules for accessing network services that use dynamically assigned ports.
It will be appreciated that embodiments of the present invention can be realised in the form of hardware, software or a combination of hardware and software.  Any such software may be stored in the form of volatile or non-volatile storage such as, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, devices or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape.  It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs that, when executed, implement embodiments of the present invention.  Accordingly, embodiments provide a program comprising code for implementing a system or method as claimed in any preceding claim and a machine readable storage storing such a program.  Still further, embodiments of the present invention may be conveyed electronically via any medium such as a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.
All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.
Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.  Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
The invention is not restricted to the details of any foregoing embodiments.  The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.  The claims should not be construed to cover merely the foregoing embodiments, but also any embodiments which fall within the scope of the claims.
Claims
1. An access control system defining one or more compartments and providing rules, which are applied to the compartment(s), to control access to network services by entities that are associated with a said compartment, the rules comprising at least a first kind of rule for controlling access to network services that use dynamically-assigned communications ports.
2. The system of claim 1, comprising a second kind of rule for controlling access to network services that use pre-assigned communications ports.
3. The system of claim 2, wherein the first kind of rule is different from the second kind of rule.
4. The system of claim 1, wherein the first kind of rule is defined independently of any communication port.
5. The system of claim 1, wherein the first kind of rule is defined with respect to a network service identifier.
6. The system of claim 1, wherein applied rules are identified in a rules table of the system.
7. The system of claim 6, wherein applied rules are defined in modules, wherein the rules table identifies each applied rule and includes an associated pointer to the respective module.
8. The system of claim 7, wherein the pointer is an opaque pointer.
9. The system of claim 1, comprising a network services handler for receiving network services calls from entities.
10. The system of claim 9, wherein the network services handler is arranged to receive a network services call, redirect the system to establish, with respect to applied access control rules, if a said calling entity has permission to access the identified network service, and process the network services call only if an applied rule grants permission to access to the network service.
11. The system of claim 9, wherein the network services handler comprises rpc_call() functionality for processing network services calls.
12. The system of claim 11, which includes a function call, which calls a function for establishing if the calling entity has rights to access the network service.
13. The system of claim 1, which applies Mandatory Access Control rules to control access to network services.
14. The system of claim 1, comprising a secure operating system.
15. The access control system according to claim 1, providing access control rules for controlling access to RPC network services.
16. An access control method comprising:
receiving a network service call from a requesting entity, which is associated with a compartment of a secure operating system, the said network service using a dynamically assigned communications port;
determining, with respect to any rules that have been applied to the compartment, whether the entity has permission to access the network service; and
processing the network service call only if an applied compartment rule grants permission to access the network service.
17. A data processing system arranged to process a network service call, comprising:
an input for receiving, from an entity that is associated with a compartment of the system, a call for a network service that uses a dynamically assigned communications port;
a store storing rules that are applied to compartments and which define associated network service access permissions; and
a process which enacts the network service call only if the store contains a said compartment rule that grants permission to access the network service.
ABSTRACT
Access Control System and Method
Certain embodiments of the invention relate to an access control system defining one or more compartments and providing rules, which are applied to the compartment(s), to control access to network services by entities that are associated with a said compartment, the rules comprising at least a first kind of rule for controlling access to network services that use dynamically-assigned communications ports.
(Figure 4)
2009009566.tif 000009
2009009566.tif 000010
2009009566.tif 000011
2009009566.tif 000012
2009009566.tif 000013
2009009566.tif 000014