JP2004529408A - 高信頼性オペレーティングシステム - Google Patents
高信頼性オペレーティングシステム Download PDFInfo
- Publication number
- JP2004529408A JP2004529408A JP2002562063A JP2002562063A JP2004529408A JP 2004529408 A JP2004529408 A JP 2004529408A JP 2002562063 A JP2002562063 A JP 2002562063A JP 2002562063 A JP2002562063 A JP 2002562063A JP 2004529408 A JP2004529408 A JP 2004529408A
- Authority
- JP
- Japan
- Prior art keywords
- operating system
- compartment
- kernel
- rules
- applications
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/468—Specific access rights for resources, e.g. using capability register
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer And Data Communications (AREA)
Abstract
アプリケーションの不正侵入によりもたらされる影響に対処する手段として、強制アクセス制御を組み込んだカーネル１００を備えたオペレーティングシステム。本オペレーティングシステムは、「コンテインメント」として知られる技法を用いて、セキュリティ侵害の発生時の損害範囲を少なくとも限度内に留める。好ましい実施形態では、本オペレーティングシステムによりサポートされる各アプリケーションには、論理的に保護されたコンピュータ処理環境すなわち「コンパートメント」をそれぞれ示すタグまたはラベルが割り当てられ、同じタグまたはラベルを有するアプリケーションは同じコンパートメントに属する。デフォルトにより、互いに通信することができるのは、同じコンパートメント中で実行されているアプリケーションのみである。アクセス制御規則により、非常に狭く、密に制御される通信経路がコンパートメント間に定義される。
Description
【技術分野】
【０００１】
本発明は、高信頼性オペレーティングシステムに関し、特に、アプリケーションの不正侵入および不正侵入されたアプリケーションの不正利用攻撃に対して高い保護性を有するオペレーティングシステムに関する。
【０００２】
近年、インターネットを介して電子的に提供されるサービスの数はますます増大している。かかるサービス、特に、成功している、ひいては収益性の高いサービスは潜在的な攻撃者の標的となり、電子サービスを提供するアプリケーションが不正侵入され、その結果として多数のインターネットセキュリティ侵害が発生していることがわかっている。
【背景技術】
【０００３】
電子サービスを提供するアプリケーションは、一般に複雑であり、１つまたは複数のバグを内包することの多い多数のコードラインを含むことから、攻撃をより受けやすくなっている。電子サービスは、インターネット上で提供される場合には、サービスの脆弱性を探ることができる多数の潜在的な攻撃者に曝されており、かかるバグによりセキュリティの侵害があったことがわかっている。
【０００４】
アプリケーションが一度不正侵入される（たとえば、バッファオーバーフロー攻撃により）と、攻撃者はそのアプリケーションを異なるいくつかの方法で不正利用攻撃して、システムのセキュリティを侵害し得る。
【０００５】
単一のマシンを使用してマルチサービス（たとえば、ＩＳＰ、ＡＳＰ、ｘＳＰサービス提供）を同時にホストする場合がますます多くなっているため、アプリケーション不正侵入攻撃から保護されたホストプラットフォームのセキュリティのみならず、攻撃を受けた場合に、攻撃を受けたアプリケーションから他のアプリケーションを適宜保護することもますます重要になってきている。
【０００６】
オペレーティングシステムレベルにてアプリケーションの不正侵入から保護する最も有効な方法の１つは、カーネル実施制御であり、これは、カーネルで実施される制御には、いずれのアプリケーションまたはユーザによってもユーザ空間から乗っ取りまたは破壊を行うことができないためである。既知の諸システムでは、当該制御は、個々のアプリケーションコードの品質に関わりなくすべてのアプリケーションに適用される。
【０００７】
アプリケーションの不正侵入およびその影響から適宜保護するためには、システムレベルにおいて２つの基本的な要件がある。第１に、アプリケーションは、可能な限り最大の程度まで攻撃から保護されなければならず、公開されるアプリケーションへのインタフェースは可能な限り狭くなければならず、またかかるインタフェースへのアクセスは十分に制御されなければならない。第２に、不正侵入されたアプリケーションがシステムに与え得る損害の大きさは、可能な限り最大まで制限されなければならない。
【０００８】
既知のシステムでは、上記２つの要件は「コンテインメント（containment、封じ込め）」という抽象的プロパティによって満たされる。アプリケーションは、不正侵入されていた場合であっても、アクセス可能な資源および可能なアクセス種別が厳密に制御されている場合には封じ込められる。コンテインメントは、外部からの攻撃および干渉からもアプリケーションを保護する。このため、コンテインメントプロパティは、攻撃者の潜在的な不正利用攻撃行動の多くを少なくとも軽減する潜在性を有する。
【０００９】
アプリケーションの不正侵入に続く最も一般的な攻撃は、以下の４つのタイプの１つに概ね分類することができる（しかし、特定の攻撃の結果はこれらのうちのいずれかまたはすべての組み合わせであり得る）。
【００１０】
１．保護システム資源への直接アクセス権限を得る特権の悪用
アプリケーションが特別な特権で実行されている（たとえば、アプリケーションが標準Ｕｎｉｘオペレーティングシステム上でｒｏｏｔとして実行されている）場合、攻撃者はその特権を、意図された方法以外の方法で使用しようと企てることがある。たとえば、攻撃者はその特権を用いて、保護動作資源へのアクセスを得たり、または同じマシンで実行されている他のアプリケーションに干渉することができる。
【００１１】
２．アプリケーション実施アクセス制御の破壊
このタイプの攻撃は、正当な資源（すなわち、アプリケーションによって公開されるものと意図される資源）へのアクセスを不正に得る。たとえば、コンテンツを提供する前にコンテンツにアクセス制御を実施するウェブサーバは、このタイプの攻撃を受けやすいアプリケーションの１つである。ウェブサーバのコンテンツへのアクセスは非制御直接アクセスであるため、ウェブサーバの制御権を得る攻撃者にとっても同様である。
【００１２】
３．誤ったセキュリティ意思決定情報の付与(supply)
通常、このタイプの攻撃は間接的な攻撃であり、不正侵入されたアプリケーションは通常、メインサービスとは対照的なサポートサービス（認証サービス等）である。この場合、不正侵入したセキュリティサービスを使用して、誤っているか、または偽作の情報を与え、それによって攻撃者がメインサービスへのアクセスを得ることが可能になる。したがって、これは、攻撃者がアプリケーションにより正当に公開されている資源に不正アクセスすることができるもう一つの方法である。
【００１３】
非保護システム資源の不正使用
攻撃者が、保護されていないが、通常はアプリケーションによって公開されない、マシンのローカル資源にアクセスする。通常、次にかかるローカル資源を使用して、さらなる攻撃を開始する。たとえば、攻撃者はホストシステムへのシェルアクセスを取得することができ、次いでそこから、マシン上またはネットワークにわたる他のアプリケーションに対して段階的な攻撃を開始することができる。
【００１４】
コンテインメントを使用する場合、保護システム資源への直接アクセスを得る特権の悪用の影響は、コンテインメントを使用しない場合よりもはるかに少ない。これは、攻撃者がアプリケーション特権を利用する場合であっても、アクセスされる恐れのある資源は、アプリケーションのコンテナ内で利用可能になっていたものに制限することができるためである。同様に、非保護資源の場合でも、コンテインメントを使用すると、アプリケーションからネットワークへのアクセスを阻止、または少なくとも非常に密に制御することができる。誤ったセキュリティ意思決定情報の付与に関しては、コンテインメントでは、サポートサービスへのアクセスを確実に正当なクライアント、すなわちアプリケーションサービスのみからにし、それによって、アプリケーションが攻撃に曝されることを制限することにより、引き起こされる潜在的な損害が少なくなる。
【００１５】
第２のタイプの攻撃、すなわちアプリケーション実施アクセス制御の破壊の軽減または防止は通常、アプリケーションの設計において、または少なくとも構成レベルにおいてなされる。しかし、コンテインメントを使用すれば、信頼性の低い大きなアプリケーション（ウェブサーバ等）から保護資源へのアクセスが、より小さくより信頼性の高いアプリケーションを経由しなければならないように構成することが可能である。
【００１６】
このため、コンテインメントをオペレーティングシステムに使用すると、アプリケーションのセキュリティが効果的に向上し、アプリケーションが不正侵入された場合に攻撃者によって引き起こされる恐れのあるあらゆる損害が制限される。図面の図１を参照して、コンテインメントプロパティを有するオペレーティングシステム上でマルチサービスホストとして機能するための例示的なアーキテクチャを示す。図示の例では、コンテインメントは、アプリケーションが相互に、またクリティカルなシステム資源から分離された状態に保たれるよう保証するために使用されている。アプリケーションは、別のアプリケーションの処理に干渉すること、またはその（おそらく機密の）データにアクセスすることができない。コンテインメントが使用されると、特定のアプリケーションが機能させる必要があるインタフェース（入力および出力）のみがオペレーティングシステムによって公開されるよう保証されるため、特定のアプリケーションに対する攻撃の範囲が制限されるとともに、アプリケーションが不正侵入されたときに生じ得る損害量が制限される。したがって、コンテインメントはホストプラットフォーム全体の保全性の維持に役立つ。
【００１７】
オペレーティングシステム内のカーネル実施コンテインメント機構は、数年前から、通常、機密（軍事）情報を受け渡し・処理するために設計されたオペレーティングシステムに利用可能であった。多くは、かかるオペレーティングシステムは「高信頼性オペレーティングシステム」と呼ばれる。
【００１８】
コンテインメントプロパティは通常、強制アクセス制御（ＭＡＣ）と特権との組み合わせを通して実現される。ＭＡＣ保護方式は、特定のアクセス制御ポリシーをファイル、プロセス、およびネットワーク接続等のシステム資源に対して実施する。このポリシーはカーネルによって実施され、ユーザまたは不正侵入されたアプリケーションによって乗っ取ることができない。
【００１９】
高信頼性オペレーティングシステムは、魅力的なコンテインメントプロパティを提供するにも関わらず、主に２つの理由により、機密情報処理システム以外ではあまり広く使用されていない。第１に、従来では、高信頼性オペレーティングシステム機構を従来のオペレーティングシステムに追加しようとすると、標準アプリケーションまたは管理ツールがサポートされなくなり、標準の方法で使用または管理することができなくなり得るという意味において、通常、土台をなすオペレーティングシステムの個性が失われることになる。このため、高信頼性オペレーティングシステムはそれぞれの標準対応品よりもはるかに複雑である。第２に、従来の高信頼性オペレーティングシステムは、通常、分離により近い、すなわち強すぎるコンテインメントの形態で動作させるため、大がかりで高価なことが多い統合努力を伴うことなく、（既存の）アプリケーションを有用かつ効果的にセキュア化する機能に関して範囲が限られていることがわかっていた。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
上記問題の克服を目的とした装置が考案され、この装置は、アプリケーションを変更することなく多数の既存のアプリケーションを効果的にセキュア化するために有効に使用することができるコンテインメントプロパティを有する高信頼性オペレーティングシステムを提供する。
【課題を解決するための手段】
【００２１】
本発明の第１の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、上記アプリケーションの少なくともいくつかにはラベルまたはタグが提供され、ラベルまたはタグはそれぞれ上記システムの論理的に保護されたコンピュータ処理環境すなわち「コンパートメント」を示し、同じラベルまたはタグを有するアプリケーションはそれぞれ同じコンパートメントに属するオペレーティングシステムが提供され、オペレーティングシステムは、上記コンパートメント間に１つまたは複数の通信経路を定義する手段と通信経路が間に定義されないコンパートメント間の通信を阻止する手段とをさらに備える。
【００２２】
本発明の第２の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、複数のアクセス制御規則をさらに備えるオペレーティングシステムが提供される。複数のアクセス制御規則は、ユーザ空間から都合良く追加することができ、オペレーティングシステムのカーネルに設けられる手段によって実施され、選択されたアプリケーション（上記オペレーティングシステムに対してローカルであるかリモートであるかに関わりなく）間の通信インタフェースのみを定義する。
【００２３】
これは、本発明の第１および第２の態様において、コンテインメントプロパティが、プロセス、ファイル、およびネットワーク資源の強制保護によって提供され、主要な概念は、システムの半ば隔離された部分であるコンパートメントに基づく。システム上のサービスおよびアプリケーションは、別個のコンパートメント内で実行される。都合のよいことに、各コンパートメント内はホストファイルシステムの限られた部分集合であり、各コンパートメントを対象とする通信インタフェースは、明確に定義され、狭く、密に制御される。各コンパートメント内のアプリケーションのみがそのコンパートメント内の資源、すなわちそのコンパートメント内の限られたファイルシステムおよび他のアプリケーションに直接アクセスする。他の資源へのアクセスは、ローカルであれリモートであれ、十分に制御された通信インタフェースを介してのみ提供される。
【００２４】
単純な強制アクセス制御、およびアプリケーションもしくはプロセスのラベリングを都合良く使用して、コンパートメントの概念を実現する。好ましい実施形態では、各プロセス（またはスレッド）にラベルが与えられ、同じラベルを有するプロセスは同じコンパートメントに属する。システムは、好ましくは、強制セキュリティチェックを行って、あるコンパートメントからのプロセスが別のコンパートメントからのプロセスに干渉することができないよう保証する手段をさらに備える。ラベルは整合するかしないかのいずれかであるため、アクセス制御は非常に簡単に行うことができる。
【００２５】
本発明の好ましい実施形態では、ファイルシステム保護もまた強制である。従来の高信頼性オペレーティングシステムとは異なり、本発明の第１の態様の好ましい実施形態は、ファイルシステムへのアクセスの直接制御にラベルを使用しない。代わりに、本発明の第１および第２の態様のファイルシステムは、好ましくは、少なくとも部分的にセクションに分割される。各セクションは、メインファイルシステムの重ならない、限られた部分集合（すなわち、ｃｈｒｏｏｔ）であり、各コンパートメントに関連する。各コンパートメントで実行されているアプリケーションのみが、ファイルシステムの関連セクションにアクセスする。本発明の第１および／または第２の態様のオペレーティングシステムには、好ましくは、ｃｈｒｏｏｔをエスケープすることができないように、本発明の第４の態様を参照して以下に述べるように、プロセスがコンパートメント内からｒｏｏｔに移行することを阻止する手段が設けられる。本システムは、ｃｈｒｏｏｔ内の選択ファイルを変更不可にする手段も含むことができる。
【００２６】
コンパートメント間、およびネットワーク資源間の柔軟であるが制御される通信経路は、狭く密に制御される通信インタフェースを通して提供され、通信インタフェースは、セキュリティ管理者等により好ましくはコンパートメント単位でユーザ空間から定義・追加が可能な１つまたは複数の規則によって統制される。かかる通信規則により、コンパートメントおよび／またはネットワーク資源の間の通信を許可する高信頼性プロキシの必要性がなくなる。
【００２７】
本発明の第１および／または第２の態様によって提供されるコンテインメントプロパティは、カーネルレベルの実施手段、ユーザレベルの実施手段、またはこれら２つの組み合わせによって実現することができる。本発明の第１および／または第２の態様の好ましい実施形態では、あるコンパートメントと他のコンパートメントまたはホストとの間のアクセス許可を指定するために使用される規則は、オペレーティングシステムのカーネル内の手段によって実施されるため、ユーザ空間介入の必要性（既存のプロキシソリューションに必要なもの等）がなくなる。カーネル実施コンパートメントアクセス制御規則により、アプリケーションを変更する必要なく、本発明の第１の態様のコンパートメント化されたオペレーティングシステムにおけるコンパートメント間の制御された柔軟な通信経路が可能になる。
【００２８】
規則の有益な形は以下である。
【００２９】
source−＞destination method m[attr][netdev n]
ただし、ｓｏｕｒｃｅ／ｄｅｓｔｉｎａｔｉｏｎは、以下のうちの１つである。
【００３０】
ＣＯＭＰＡＲＴＭＥＮＴ（名前の付いたコンパートメント）
ＨＯＳＴ（おそらく固定Ｉｐｖ４アドレス）
ＮＥＴＷＯＲＫ（おそらくＩｐｖ４サブネット）
ｍ：サポートされるカーネル機構、たとえば、ｔｃｐ（伝送制御プロトコル）、ｕｄｐ（ユーザデータグラムプロトコル）、ｍｓｇ（メッセージキュー）、ｓｈｍ（共有メモリ）等
ａｔｔｒ：メソッドｍをさらに修飾するプロパティ
ｎ：妥当な場合には、名前の付いたネットワークインタフェース、たとえばｅｔｈ０
規則の指定にワイルドカードを使用することも可能である。以下の規則例は、ＴＣＰを使用してポート８０のみですべてのホストがウェブサーバコンパートメントへアクセスすることを許可する。
【００３１】
HOST*−＞COMPARTMENT web METHOD tcp PORT80
以下の規則例はかなり似ているが、ウェブサーバコンパートメントへのアクセスを、システムの例示的な実施形態においてｅｔｈ０ネットワークインタフェースへのルートを有するホストに制限する。
【００３２】
HOST*−＞COMPARTMENT web METHOD tcp PORT80 NETDEV eth0
有益には、許可を受けたシステム管理者によって、オペレーティングシステムに規定されたアクセス制御規則の追加、削除、および／またはリスト化を行う手段が設けられることが好ましい。選択されたコンパートメント間および／または資源間で双方向通信を行うことができるようにするために、リバースＴＣＰ規則を追加する手段を設けてもよい。
【００３３】
規則は、有益なことに、カーネルレベルのデータベースに格納され、好ましくは、ユーザ空間から追加される。カーネルレベルのデータベースは、有益なことに、２つのハッシュテーブルで構成され、テーブルの一方は規則の発信元アドレス詳細に焦点をあて、他方は規則の宛先アドレス詳細に焦点をあてる。システムは、システムコール／ＩＳＲ（割り込みサービスルーチン）の処理を許可する前に、データベースをチェックして規則が適切な通信経路を定義しているか否かを判定するように構成される。カーネルレベルデータベースの好ましい構造により、セキュリティチェックを行う時に、システムは、要求される規則が発信元アドレス詳細または宛先アドレス詳細に整合すべきかどうかを知っており、よって適切なハッシュテーブルを選択することができ、規則参照のＯ（１）レートを可能にするため、カーネル実施コンパートメントアクセス制御規則を効率的に参照することができる。要求される通信経路を定義する必要な規則が見つからない場合には、システムコールは失敗することになる。
【００３４】
したがって、本発明の第３の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、上記アプリケーション間の許可された通信経路（すなわち、発信元および宛先）を定義する複数の規則が格納されたデータベースを備えるオペレーティングシステムが提供される。上記規則は、少なくとも２つの符号化テーブル、すなわち規則の発信元詳細に焦点をあてた第１のテーブルおよび規則の宛先詳細に焦点をあてた第２のテーブルの形態で格納される。本システムは、システムコールに応答して、要求される通信経路を定義する規則の存在について上記テーブルの少なくとも一方をチェックし、上記要求された通信経路が定義されている場合にのみ、上記システムコールの続行を許可する手段をさらに備える。
【００３５】
上記符号化テーブルは、好ましくは、少なくとも１つのハッシュテーブルを含む。
【００３６】
多くの場合、ゲートウェイタイプのシステム（すなわち、内部および外部両方のネットワークに接続されたデュアルインタフェースを備えたホスト）では、以下のことが望ましい：ａ）利用可能なネットワークインタフェースの部分集合のみを使用するように実行中のサーバプロセスを制限すること、ｂ）アクセス可能なリモートホストおよびアクセス不可能なリモートホストを明示的に指定すること、およびｃ）かかる制限をプロセス／サービス単位で同じゲートウェイシステムに適用させること。
【００３７】
ゲートウェイシステムは、いくつかの内部サブネットワークに物理的に接続されることがあるため、サーバプロセスがリモートソースから不正侵入された場合に、別のネットワークインタフェースを介して、潜在的に脆弱性を有するバックエンドホストへのその後の攻撃開始に使用することができないように、システム管理者が、どのサーバプロセスがどのネットワークインタフェースにアクセス許可され得るかを分類することが重要である。
【００３８】
従来では、ＩＰアドレス単位および／またはＩＰポートレベル単位でホスト間のアクセスを制限するようにファイアウォールが使用されてきた。しかし、かかるファイアウォールは、主に、異なるサーバプロセスを区別することができないという理由により、複数のサービスをホストするゲートウェイシステムに十分なきめ細かさを提供しない。加えて、異なる制限セットを指定するには、別個のファイアウォール規則のセットを有する別個のゲートウェイシステムが求められる。
【００３９】
本発明者らによる第１の同時係属中の国際出願には、上記問題の克服を目的とし、内部および外部ネットワークの両方に接続されたデュアルインタフェースを備え、プロセスおよび／またはスレッドを実行している複数のサービスをホストするゲートウェイシステムを提供する装置が定義される。このシステムは、コンパートメントを示すタグまたはスレッドを上記実行中のプロセスおよび／またはスレッドの少なくともいくつかに提供する手段を備え、同じタグまたはラベルを有するプロセス／スレッドは同じコンパートメントに属する。このシステムは、上記コンパートメントとローカルおよび／またはリモートホストもしくはネットワークとの間に特定の通信経路および／または許可されたインタフェース接続を定義する手段と、通信経路またはインタフェース接続が間に定義されている場合にのみ、コンパートメントとホストまたはネットワークとの間の通信を許可する手段とをさらに備える。
【００４０】
かくして、本発明者らによる第１の同時係属中の国際出願の発明では、アクセス制御チェックが、好ましくはゲートウェイシステムのカーネル／オペレーティングシステムに対して行われる。かかるアクセス制御チェックでは、好ましくは、どのプロセスクラスがどのサブネット／ホストにアクセス許可されているかを指定する規則テーブルを照会する。制限は、サービス（またはプロセス／スレッド）レベル単位で指定することができる。これは、バックエンドネットワークのビューが単一のゲートウェイホスト上で可変であることを意味する。したがって、たとえば、ゲートウェイが、２つの異なるバックエンドホストへのアクセスをそれぞれ要求する２種類のサービスをホストする場合、従来技術によるファイアウォールは、ゲートウェイホストがこれらバックエンドホストの両方にアクセス可能なことを指定する必要があるが、本発明者らによる第１の同時係属中の国際出願の発明では、許可された通信経路をより細かいレベルで、すなわちどのサービスがどのホストにアクセス許可されているかを指定することが可能である。これにより、サービスが当初アクセスすることが意図されていなかったホストにアクセスする危険性が大幅に低下するため、セキュリティはいくらか向上する。
【００４１】
本発明の好ましい実施形態では、アクセス制御チェックはゲートウェイシステムのカーネル／オペレーティングシステムにおいて実施されるため、ユーザ空間プロセスがこれを迂回することはできない。
【００４２】
かくして、本発明者らによる第１の同時係属中の国際出願の発明の第１の例示的な実施形態では、ゲートウェイシステムのカーネルに、プロセスがどのコンパートメントに属するかを概念的に示すタグまたはラベルを実行中の各プロセス／スレッドに添付する手段が設けられる。かかるタグは、子にフォークする親プロセスから受け継ぐことができる。したがって、スレーブウェブサーバプロセス群等、協働して作業負荷を分担する、フォークした子の群を含むサービスは、同じタグを保有し、同じ「コンパートメント」に配置される。システム管理者は、たとえば、以下の形態で規則を指定することができる。
【００４３】
Compartment X−＞Host Y[using Network Interface Z]または
Compartment X−＞Subnet Y[using Network Interface Z]
これらは、名前の付いたコンパートメントＸ中のプロセスによる、ホストあるいはサブネットＹへのアクセスを許可し、オプションとして、Ｚと名の付いたネットワークインタフェースのみを使用する場合に制限される。好ましい実施形態では、かかる規則は、ゲートウェイシステム上の安全な構成ファイルに格納され、システムスタートアップ時に、次いて開始されるサービスが実行することができるように、カーネル／オペレーティングシステムにロードされる。サービスが開始されると、それぞれのスタートアップシーケンスが、最初にどのコンパートメントに配置されるかを指定する。この実施形態では、好ましくはカーネルのプロトコルスタックにおいてセキュリティチェックをさらに行うことにより、パケットをコンパートメントＸから送信またはコンパートメントＸに引き渡す都度、規則を照会する。
【００４４】
本発明者らによる第１の同時係属中の国際出願の発明の第２の例示的な実施形態では、別個のルーティングテーブルがコンパートメント毎に提供される。上に述べた第１の実施形態と同様に、各プロセスは、親から受け継いだタグまたはラベルを保有する。特定の名前の付いたプロセスは、システム管理者によって構成された指定タグで始まる。規則を指定する代わりに、第１の例示的な実施形態を参照して上述したように、所望のルーチンテーブルエントリを挿入することにより、各コンパートメントのルーティングテーブルを構成する構成ファイルのセットが提供される（各コンパートメントに１つ）。ゲートウェイシステムはいくつかの名前の付いていないコンパートメントを含むことができるため、各コンパートメントのルーティングテーブルはデフォルトでは空である（すなわち、エントリがない）ことが好ましい。
【００４５】
整合するルートがないことは、到達を試みられているリモートホストが到達不可能であると報告されることを意味すると解釈されるため、明示的な規則の代わりにルーティングテーブルを使用することができる。整合するルートは、そのリモートホストにアクセスしようという試みが許可されることを意味する。上に述べた第１の例示的な実施形態における規則と同様に、ルーティングエントリは、ホスト単位（ＩＰアドレス）またはサブネット単位で指定することができる。第１の例示的な実施形態と同じ機能を実現するために必要なのは、かかるルーティングエントリをコンパートメント単位で指定することだけである。
【００４６】
上に述べたように、実行中のサーバプロセス／デーモンへの攻撃（たとえば、バッファオーバーフロー、スタック破壊）は、遠隔地にいる攻撃者が、サーバプロセスをホストしているシステムでｒｏｏｔ／管理者に相当するアクセスを不法に得る状況に繋がる恐れがある。かかるシステムで管理者アクセスを得ると、攻撃者は、不正侵入されたシステムに存在することがある機密の構成／パスワードファイル、非公開データベース、秘密鍵等の読み出しなど、他のセキュリティ侵害を自由に開始することができる。
【００４７】
かかる攻撃は、以下の場合に可能であり得る。
【００４８】
ａ）サーバプロセスが管理者として実行され、ソフトウェアバグにより実行時に内部に侵入される。
【００４９】
ｂ）サーバプロセスが、最初は管理者として開始されるが、ある特権動作を行うのに先立って管理者特権を再び取得する選択的機能を備えて、その動作時間の大半は管理者特権を落とすようにプログラムされた。かかる場合、サーバプロセスは（ある特定の目的のために）ｒｏｏｔに移行して戻る機能を保持するが、攻撃者は、プロセスの制御権をいったん取得すると、意図された当初の目的以外でｒｏｏｔへの移行を行うことができる。
【００５０】
ｃ）サーバプロセスが、最初は非特権ユーザとして開始されるが、まずオリジナルのサーバプロセスを破壊し、次いでそれを、上述した方法で脆弱性を有する可能性がある外部ｓｅｔｕｉｄ−ｒｏｏｔプログラムを破壊する手段として使用することによって管理者アクセスを得る。
【００５１】
従来技術によれば、こういった問題に対する１つの直接的な方策は、最初に攻撃の発生を許した特定のバッファオーバーフローバグを塞ぐ／修復することである。この方策の明らかな欠点はもちろん、純粋に受動的であり、バッファオーバーフローバグが今後さらに見つかり、不正利用攻撃される事態が防止されないことである。従来技術により提案された別の方策は、オペレーティングシステム、たとえばＵｎｉｘに存在する機能について、決して戻さないという意図をもって、ｒｏｏｔに相当するアクセスをすべて落とすというものである。これにより、実行中のプロセスが予期せずにｒｏｏｔに復帰する事態が回避されるが、プログラムが、たとえば、不注意に周辺に転がっており、ある不正入力が与えられると破られやすい外部ｓｅｔｕｉｄ−ｒｏｏｔプログラムを動作させるという事態を回避しない。これが万が一行われた場合、不正侵入された、非特権ユーザとして実行中のプロセスは、ｓｅｔｕｉｄ−ｒｏｏｔプログラムを実行し、攻撃者の制御下にさせる入力を与えるという事態を防止しない。
【００５２】
ここで、上記問題を克服することを目的とした装置を考案した。かくして、本発明の第４の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、要求に応答して、アプリケーションがｒｏｏｔに移行することが許可されているか否かを示すタグまたはラベルを上記アプリケーションの少なくともいくつかに提供する手段と、かかる要求を識別し、そのタグまたはラベルから、アプリケーションのｒｏｏｔへの移行が許可されているか否かを判定し、判定に応じて上記移行を許可または拒絶する手段とを備えるオペレーティングシステムが提供される。
【００５３】
好ましい実施形態では、上記タグまたはラベルの少なくとも１つは、そのタグまたはラベルが添付されている、または関連付けられたアプリケーションが「封印」されたもの、ひいては変更不可であることを示す。
【００５４】
かくして、本発明の第４の態様は、選択されたサーバプロセスを、管理者相当状態への状態移行に関して「封印」することにより、かかるサーバプロセスの管理者相当状態への移行を止める方法を導入する。こういったプロセスがかかる移行を行おうとすると常に、かかる目的専用のシステムルーチンを呼び出すか、「ｓｅｔｕｉｄ−ｒｏｏｔ」とマークされた外部プログラム（すなわち、呼び出した人が誰であれ、管理者として実行する機能を有するものとして、システム管理者により予めタグを付けられているプログラム）を実行するか、あるいはあらゆる他の手段により、オペレーティングシステムは、このようにマークされたプログラムを実行するシステムコールまたは試行を許可しない。
【００５５】
本発明の第４の態様によるオペレーティングシステムによってもたらされる利点としては、ｒｏｏｔに相当するアクセスに対する制限が無条件であり、実行されるサーバプロセスに、不正利用攻撃されるまだ発見されていないソフトウェアバグがいくつあるかに関わりなく、効力を失わない状態を保つことが挙げられる。不正利用攻撃される恐れのある新しいバグが発見された場合、制限は、新しいバグの性質に関わりなく、それまで他のバグの場合と同じように課された状態のままである。明らかに、これは、バグが発見されたときにそのバグを修復する必要がある場合には起こりえない。さらに、本発明の第４の態様の装置は、攻撃者が、オリジナルプロセスの代わりにｒｏｏｔとして実行する機能を有する外部プログラムの破壊を企てる外部ｓｅｔｕｉｄ−ｒｏｏｔ問題を解消している。本発明の第４の態様の装置では、オペレーティングシステムにおいてかかるあらゆる企てが追跡され、装置は、マークされたプロセスを用いてかかるｓｅｔｕｉｄ−ｒｏｏｔプログラムを実行する試みを拒絶するように構成することができる。加えて、保護プロセスの元のソースコードを変更する必要はなく、ｒｏｏｔに戻らないことを保証して、任意のバイナリを実行することができる。
【００５６】
高信頼性オペレーティングシステムは通常、入力ネットワークパケットに割り当てる必要のある機密ラベルの決定に役立つように、個々のネットワークアダプタのラベル付けを行う。ファイアウォール等他のソフトウェアシステムが、どのインタフェースを潜在的な「敵」または非敵とマークすべきかを決定するために、インタフェースラベル付け（またはカラーリングと呼ばれることもある）を実行することがある。これは、内部では高信頼性／安全であり、外部インターネットリンクに関しては低信頼性／非安全な企業ネットワークのビューに対応する（図面の図１５を参照）。
【００５７】
コンピュータシステムの動作中静的なままであるネットワークアダプタ（ＮＩＣ）の場合、ラベル付けはシステムスタートアップ中に行うことができる。しかし、ＰＰＰリンクまたはあらゆる他のネットワークデバイス抽象化（たとえば、ＶＬＡＮ、ＶＰＮ）を処理する「ソフト」アダプタ等、システム上で動的にアクティブ化することのできる類のＮＩＣがある。かかる動的アダプタの例としては、以下が挙げられる。
【００５８】
＊ＰＰＰリンク、たとえばＩＳＰへのモデム接続。通常、ＩＳＰへのＰＰＰ接続を表すソフトアダプタが作成される。
【００５９】
＊仮想ＬＡＮ（ＶＬＡＮ）−サーバは、ＶＬＡＮを使用して、私設仮想回線で動作するソフトウェアサービスをホストすることができる。かかるＶＬＡＮは動的に（たとえば、要求があり次第）セットアップすることができるため、高信頼性オペレーティングシステムまたはそれに由来するものを使用する場合、かかるサービスをホストするサーバがこういったインタフェースを正しくラベル付けることができるはずである。
【００６０】
図面の図１５に示す構成が概ね静的な性質であることは、新しいアダプタを処理する必要が殆どないことを意味する。システム管理者は、新しいアダプタをデュアルホームホスト７００に追加したい場合には、通常システムを停止し、アダプタを物理的に追加して、新しいアダプタを適宜認識するようにシステムを構成する。しかし、このプロセスは、インタフェースラベル付けを要求するシステムが上に述べた種類の動的インタフェースを有する場合には適さない。
【００６１】
ラベルがアダプタに付けられない場合、アダプタ上の入力パケットに正しいラベルが割り当てられず、問題となっているシステムのセキュリティに違反することがある。さらに、出力パケット（おそらく、ラベルが正しく割り当てられている）は、パケットを送信すべきアダプタと正しく整合しえないため、問題となっているシステムのセキュリティに違反する。
【００６２】
本発明者らによる第２の同時係属中の国際出願では、上記問題の克服を目的とし、新たにインストールされたアダプタを実質的にアクティブ化するときに、上記アダプタの属性に依存するラベルをそのアダプタに動的に割り当てる手段と、上記アダプタが非アクティブ化されるときに上記ラベルを除去する手段とを備えるオペレーティングシステムを提供する装置が定義される。
【００６３】
かくして、オペレーティングシステムに新たにインストールされたアダプタが初めてアクティブ化されると、入力パケットの受け取りに先立ってラベルが確実に割り当てられ、それによってラベルの付いていないパケットが作成されないこと、またネットワークプロトコルスタックに渡されないことが保証される。動的アダプタは、第２の同時係属中の国際出願の発明のオペレーティングシステムにおいて作成されるため、かかるラベルシステムの新しい機能分野が、たとえば、ルータ、モバイル機器として開かれる。さらに、アダプタに割り当てられるラベルは、新たにアクティブ化されたアダプタの実行時プロパティの関数であり得る。たとえば、各種ＩＳＰへの様々なＰＰＰ接続を区別することが望ましい場合がある。これは、ラベルをアダプタ名に割り当てる（たとえば、アダプタ「ｐｐｐ０」にラベルＬ０を割り当てる）ことによって行うことはできない。これは、アダプタ名が動的に作成され、アダプタの実際のプロパティが可変であるためである。アダプタに適切なラベルを選ぶことにより、あらゆるセキュリティチェックがラベル関数に適切に基づくことを保証することができる。これは、アダプタに付けられるラベルは、システムにすでに存在するその他のラベルに関して正しくなければならないという意味において、プロセス、ネットワーク接続、ファイル、パイプ等他のシステムオブジェクトにもラベルを付ける高信頼性オペレーティングシステム（特に、本発明の第１および第２の態様を参照して定義したもの）に関して特に重要である。
【００６４】
カーネル／オペレーティングシステムは通常、新しいアダプタがアクティブ化されるときに呼び出されるソフトウェアルーチンを有する。第２の同時係属中の国際出願の発明の例示的な実施形態では、かかるルーチンは、たとえば、規則セットまたは構成テーブルを照会することにより、新たに形成されたアダプタの属性に応じてラベルを割り当てるようにも変更される。同様に、アダプタが非アクティブ化されるときに呼び出されるルーチンもあり、これはそれまで割り当てられていたラベルを除去するように変更される。
【００６５】
本発明の第１および第２の態様を再び参照して、属するコンパートメントを示すタグで各プロセスおよびネットワークインタフェースを増補するオペレーティングシステムが定義される。例示的な実施形態では、カーネルに設けられる手段が、（任意の標準Ｕｎｉｘプロセス間通信機構を使用することで、Ｌｉｎｕｘオペレーティングシステムにおいて）あるプロセスが別のプロセスと通信したいときは常に規則ベースを照会する。整合する規則が規則ベースにある場合にのみ、通信が成功する。好ましい実施形態では、規則ベースはカーネルに存在するが、上述のように、より実際的には、管理プログラムにより好ましくはユーザ空間において初期化され、動的に維持され、照会されることが望ましい。
【００６６】
したがって、本発明の第５の態様によれば、システムオブジェクト間の許可された通信経路を定義する１つまたは複数の規則からなる規則ベースを格納する手段を含むカーネルと、かかる規則の追加、削除、および／またはリスト化を行うユーザ操作可能手段とを備えるオペレーティングシステムが提供される。
【００６７】
したがって、本発明の第５の態様のオペレーティングシステムでは、ＴＣＰおよびＵＤＰパケットを介してのアクセス制御のみならず、オペレーティングシステムに存在する他の形態のプロセス（Ｌｉｎｕｘシステムでは、生ＩＰパケット、ＳｙｓＶメッセージ、ＳｙｓＶ共有メモリ、およびＳｙｓＶセマフォが挙げられる）間通信のアクセス制御も実行することが可能である。
【００６８】
本発明の第５の態様の例示的な一実施形態では、ユーザ空間プログラムが、規則ベース中のエントリを変更およびリスト化するために、カーネルを対象にしたデータを送受信可能である必要がある。好ましい実施形態では、これは、２つのエントリポイントを提供するカーネルデバイスドライバをオペレーティングシステムに包含することによって実施される。第１のエントリポイントは、「ｉｏｃｔｌ」システムコールのためのものである（ｉｏｃｔｌは従来、小量のデータまたはコマンドをデバイスに送信するために使用される）。第１のエントリポイントは、３つの演算に使用するよう構成される。第１に、完成した規則を指定し、規則ベースに追加するために使用することができる。第２に、同じデータを使用してその規則を削除することができる。第３に、最適化として、その「参照」により規則を削除することができ、本発明の例示的な一実施形態では、参照は、カーネルによって維持される６４ビットタグである。
【００６９】
第２のエントリポイントは、「／ｐｒｏｃ」エントリのためのものである。ユーザ空間プログラムがこのエントリを開くと、カーネルによって生成された規則のリストを読み出すことができる。この第２のエントリポイントの理由は、規則リストを読み出すには、ｉｏｃｔｌコマンドを介してよりも効率的な機構であり、また、カーネルモジュールの特定の「ｉｏｃｔｌ」コマンドを認識し処理するために、特に書く必要のない他のユーザプロセスがより容易に読み出し可能なためである。
【発明を実施するための最良の形態】
【００７０】
要約すれば、従来の高信頼性オペレーティングシステム手法と同様に、コンテインメントプロパティが、プロセス、ファイル、およびネットワーク資源をカーネルレベルで強制保護することにより、本発明の例示的な一実施形態におけるオペレーティングシステムにおいて実現される。しかし、本発明のオペレーティングシステムに使用される強制制御は、従来の高信頼性オペレーティングシステムに見られるものとはいくらか異なり、したがって、従来の高信頼性オペレーティングシステムに関連するアプリケーション統合および管理問題のいくらかを少なくとも軽減するよう意図される。
【００７１】
本発明による高信頼性オペレーティングシステムの鍵となる概念は「コンパートメント」であり、システム上の各種サービスおよびアプリケーションは別個のコンパートメント内で実行される。比較的簡単な強制アクセス制御およびプロセスラベリングを用いて、コンパートメントの概念を築く。以下の本発明による例示的な実施形態の高信頼性オペレーティングシステムでは、システム内の各プロセスにはラベルが割り振られ、同じラベルを有するプロセスは同じコンパートメントに属する。カーネルレベルの強制チェックを実施して、あるコンパートメントのプロセスが別のコンパートメントのプロセスに干渉することができないように保証する。強制アクセス制御は、ラベルは整合するかしないかのいずれか一方であるという意味において比較的簡単である。さらに、いくつかの既知の高信頼性オペレーティングシステムでのようなラベルの階層順序付けはシステム内に存在しない。
【００７２】
従来の高信頼性オペレーティングシステムとは異なり、本発明では、メインファイルシステムへのアクセスの直接制御にラベルは使用されない。代わりに、ファイルシステム保護は、メインファイルシステムの異なるセクションに各コンパートメントを関連付けることによってなされる。ファイルシステムのかかるセクションはそれぞれ、メインファイルシステムのｃｈｒｏｏｔであり、ファイルシステムのセクションにアクセスすることができるのは、そのセクションに関連するコンパートメント内で実行中のプロセスだけである。重要なことは、カーネル制御を介して、プロセスがコンパートメント内からｒｏｏｔに移行する機能が取り除かれるため、ｃｈｒｏｏｔをエスケープすることはできない。本発明の例示的な一実施形態は、ｃｈｒｏｏｔ内の少なくとも選択されたファイルを変更不可にする機能も提供する。
【００７３】
コンパートメント間およびネットワーク資源間の柔軟性のある通信経路は、ＴＣＰ／ＵＤＰに加えて大半のＩＰＣ機構に対する狭い、カーネルレベルで制御されるインタフェースを介して設けられる。これら通信インタフェースへのアクセスは、セキュリティ管理者により「コンパートメント単位」で指定される規則によって統制される。したがって、従来の高信頼性オペレーティングシステムとは異なり、コンパートメントとネットワーク資源の間の通信を許可するために、特権を用いて強制アクセス制御を無効とするか、またはユーザレベルの高信頼性プロキシの使用にたよる必要がない。
【００７４】
したがって、本発明はコンテインメントを提供するが、アプリケーションの統合を比較的簡便にするに足る柔軟性も有し、それによって高信頼性オペレーティングシステムの配備および実行に伴う管理オーバヘッドおよび不便さを軽減する高信頼性オペレーティングシステムを提供する。
【００７５】
ここで、本発明の特定の例示的な一実施形態のアーキテクチャおよび実施について述べる。以下の説明では、本発明が完全に理解されるように、多くの特定の詳細が述べられる。しかし、本発明はこういった特定の詳細に制限されることなく実施可能なことが当業者には認められよう。他の場合では、本発明を不必要に曖昧にすることを避けるために、既知の方法および構造についての詳細な説明は省く。
【００７６】
以下の説明では、ＨＴＴＰサーバ等、ユーザレベルのサービスのコンテインメントをサポートするようにベースＬｉｎｕｘカーネルを変更することによって実現される高信頼性Ｌｉｎｕｘオペレーティングシステムについて詳細に述べる。しかし、本発明の原理は、他のタイプのオペレーティングシステムにも適用することができ、同じもしくは同様の効果を上げることができることは当業者により認められよう。
【００７７】
本発明の例示的な一実施形態による高信頼性オペレーティングシステムを実現するようにＬｉｎｕｘオペレーティングシステムに加える変更は、以下のように概ね分類することができる。
【００７８】
１．以下のエリアにおけるカーネルの変更
＊ＴＣＰ／ＩＰネットワーキング
＊ルーティングテーブルおよびルーティングキャッシュ
＊システムＶ ＩＰＣ−メッセージキュー、共有メモリ、およびセマフォ
＊プロセスおよびスレッド
＊ＵＩＤハンドリング
２．以下の形態のカーネル構成インタフェース
＊動的ロード可能カーネルモジュール
＊これらモジュールと通信するためのコマンドラインユーティリティ
３．個々のコンパートメントを管理／構成するユーザレベルのスクリプト
＊コンパートメントを開始／停止するスクリプト
図面の図２を参照して、ベースＬｉｎｕｘカーネルに対する主要な変更エリアを含み、構成可能ｃｈｒｏｏｔ ｊａｉｌにおいてＣＧＩバイナリを実行可能なウェブサーバを実施するユーザ空間に一連のコンパートメントを追加した、本発明の例示的な一実施形態による高信頼性Ｌｉｎｕｘホストオペレーティングシステムのアーキテクチャを示す。
【００７９】
かくして、図２を参照すると、ベースＬｉｎｕｘカーネル１００は一般に、ＴＣＰ／ＩＰネットワーキング手段１０２と、Ｕｎｉｘドメインソケット１０４と、Ｓｙｓ Ｖ ＩＰＣ手段１０６と、他のサブシステム１０８とを備える。高信頼性Ｌｉｎｕｘオペレーティングシステムは、セキュリティモジュール１１２と、装置構成モジュール１１４と、規則データベース１１６と、カーネルモジュール１１８との形態のカーネル拡張１１０をさらに備える。図示のように、Ｌｉｎｕｘカーネルサブシステム１０２、１０４、１０６、１０８の少なくともいくつかは、カーネルレベルセキュリティモジュール１１２にコールアウトするように変更されている。セキュリティモジュール１１２は、アクセス制御判定を行い、コンパートメントの概念を実施し、それによってコンテインメントを提供する責任を有する。
【００８０】
セキュリティモジュール１１２はさらに、判定を行うときに規則データベース１１６を照会する。規則データベース１１６は、コンパートメントへまたコンパートメントから、狭く十分に制御されたインタフェースを提供するための、コンパートメント間の許容可能な通信経路についての情報を含む（図面の図１２も参照のこと）。
【００８１】
図面の図２は、カーネル拡張１１０が一連のｉｏｃｔｌコマンドを介してユーザ空間１２０からどのように管理されるかも示している。かかるｉｏｃｔｌコマンドは２つの形態をとる：規則テーブルを操作する形態、および特定のコンパートメント中のプロセスを実行し、ネットワークインタフェースを構成する形態である。
【００８２】
図２に示すウェブサーバ等のユーザ空間サービスは、プラットフォーム上で変更されずに実行されるが、セキュリティ拡張へのコマンドラインインタフェースを介してコンパートメントラベルが関連付けられている。そしてセキュリティモジュール１１２は、付けられたコンパートメントラベルに基づいて、強制アクセス制御をユーザ空間サービスに適用する責任を有する。このため、ユーザ空間サービスを変更する必要なく、こういったサービスを封じ込めることが可能なことが認められよう。
【００８３】
図面の図２を参照して述べるシステムアーキテクチャの３つの主な構成要素は、ａ）通信規則およびプロセスコンパートメントラベル等、セキュリティ拡張の根本的な態様を構成および管理するために必要なコマンドラインユーティリティ、ｂ）この機能をカーネル内で実施するロード可能モジュール、およびｃ）この機能を利用するために行われたカーネル変更である。ここで、これら３つの主な構成要素について以下により詳細に述べる。
【００８４】
ａ）コマンドラインユーティリティ
「ＣＡＣＣ」は、ｃａｃカーネルロード可能モジュール（図示せず）によって提供される／ｄｅｖ／ｃａｃｃおよび／ｐｒｏｃ／ｃａｃｃインタフェースを介して規則の追加、削除、およびリスト化を行うためのコマンドラインユーティリティである。規則は、コマンドラインに入力しても、またはテキストファイルから読み出してもよい。
【００８５】
本発明の例示的な本実施形態では、規則のフォーマットは以下である。
【００８６】
＜rule＞::=＜source＞[＜port＞]−＞＜destination＞[＜port＞]＜method list＞＜netdev＞
ただし、
【数１】
【００８７】
＜comp_name＞==コンパートメントの有効な名前
＜host_name＞==既知のホスト名またはＩＰアドレス
＜ip_addr＞==a.b.c.d形態のＩＰアドレス
＜netmask＞== a.b.c.d形態の有効ネットマスク
＜bits＞==ネットマスクにおける最左端ビットの数字、０〜３１
＜method_list＞==カンマで区切られたメソッドのリスト（例示的な本実施形態において、サポートされるメソッドは、ＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、およびＡＬＬである。
【００８８】
規則を追加するには、ユーザは「ｃａｃｃ−ａ＜ｆｉｌｅｎａｍｅ＞」を入力する（＜ｆｉｌｅｎａｍｅ＞が上記フォーマットの規則を含むファイルである場合、テキストファイルから規則を読み出す）か、または「ｃａｃｃ−ａ ｒｕｌｅ」を入力する（規則をコマンドラインに入力する）ことができる。
【００８９】
規則を削除するには、ユーザは、「ｃａｃｃ−ｄ＜ｆｉｌｅｎａｍｅ＞」、またはｃａｃｃ−ｄ ｒｕｌｅ、もしくはｃａｃｃ−ｄ ｒｅｆ（この形では、単に、コマンドｃａｃｃ−ｌを使用して規則をリスト化することによって出力される参照番号によって規則を削除することができ、コマンドｃａｃｃ−ｌは、標準形式で規則を出力またはリスト化し、規則参照は各規則の終わりに注釈として出力される）を入力することができる。
【００９０】
デフォルトにより、「ｃａｃｃ」はカレント作業ディレクトリにおいてコンパートメントマッピングファイル「ｃｍａｐ．ｔｘｔ」およびメソッドマッピングファイル「ｍｍａｐ．ｔｘｔ」を見つけるものと期待される。しかしこれは、本発明の例示的な本実施形態では、ＵＮＩＸ環境変数ＣＡＣＣ＿ＣＭＡＰおよびＣＡＣＣ＿ＭＭＡＰを実際にファイルが常駐するところにセットすることによって無効とされる可能性がある。
【００９１】
ｃａｃｃによって捕捉されたあらゆる構文エラーまたは意味エラーは、エラーレポートをもたらし、コマンドが即時終了し、規則が追加または削除されないことになる。テキストファイルが規則の入力に使用されている場合には、エラーのあるラインのライン番号がエラーメッセージに提供される。
【００９２】
本発明の例示的な本実施形態によって提供される別のコマンドラインユーティリティは、「ｌｃｕ」として知られており、ＬＮＳカーネルモジュール（図示せず）へのインタフェースを提供する。ｌｃｕの最も重要な機能は、各種管理スクリプトに、所与のコンパートメント中のプロセスを生成する機能およびインタフェースのコンパートメント数をセットする機能を提供することである。以下は使用例である。
【００９３】
１．'lcu setdev eth0 0xFFFF0000'
ｅｔｈ０ネットワークインタフェースのコンパートメント番号を０ｘＦＦＦＦ００００にセットする
２．'lcu setprc 0x2-cap_mknod bash'
コンパートメント０ｘ２に切り換え、ｃａｐ＿ｍｋｎｏｄ機能を解除し、ｂａｓｈを呼び出す
ｂ）カーネルモジュール
本発明の例示的な本実施形態は、カスタムｉｏｃｔｌ（ ）の実施に、規則の挿入／削除およびネットワークインタフェースのラベル付け等他の機能を可能にする２つのカーネルモジュールを使用する。しかし、２つのモジュールをカスタムシステムコールに併合し、かつ／またはカスタムシステムコールで置き換えてもよいものと考えられる。本発明の本実施形態では、２つのカーネルモジュールの名前はｌｎｓおよびｃａｃである。
【００９４】
ｌｎｓモジュールは、カスタムｉｏｃｔｌ（ ）を介して各種インタフェースを実施し、以下を可能にする。
【００９５】
１．呼び出しプロセスがコンパートメントを切り換えること、
２．個々のネットワークインタフェースにコンパートメント番号を割り当てること。
【００９６】
コンパートメント番号を使用してのプロセスリスト化、およびカーネルレベルのセキュリティチェックに対するアクティビティのログ化等のユーティリティ関数。
【００９７】
このモジュールの主なクライアントは、上述したｌｃｕコマンドラインユーティリティである。
【００９８】
ｃａｃモジュールは、インタフェースを実施して、カスタムｉｏｃｔｌ（ ）を介してカーネルにおいて規則を追加／削除する。これは、より上位レベルの簡略化された規則を、カーネル参照ルーチンがより理解し易い原始的な形に翻訳する。このモジュールは、ｃａｃｃおよびｃｇｉｃａｃｃユーザレベルユーティリティと呼ばれ、カーネル内の規則を操作する。
【００９９】
ｃ）カーネル変更
本発明の例示的な本実施形態では、各種データ型に付けられるタグを導入し、このようにタグ付けされたデータ型に対してもアクセス制御チェックをさらに行うように、標準Ｌｉｎｕｘカーネルソースに変更が加えられている。タグ付けされた各データ型は追加として、コンパートメント番号を保持するために用いられるｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバ（図面の図３に示す）を含む。タグ付けされたデータ型は、他のセキュリティ属性も保持するように拡張可能なものと考えられる。一般に、このデータメンバの追加は通常、共通のエントリで始まる２つまたはそれよりも多くの名前の異なる構造体にポインタを向ける慣行に関連して発生する問題を回避するように、データ構造体の最後の最後で行われる。
【０１００】
個々のカーネル資源をタグ付けする最終的な効果は、生成／消費するプロセスおよびデータが相互に分離されたコンパートメント化システムの実施が非常に簡単なことである。かかる分離は、多くの隠れチャネルが存在する（プロセスについての以下の考察を参照）という意味において、厳密な分離を意図しない。分離は単に、論理的に異なるプロセス群の間の明確な形のコンフリクトおよび／または相互作用を回避するものと意図される。
【０１０１】
本発明の例示的な本実施形態では、カーネルにおいて保護されているサブシステムにイエス／ノーセキュリティチェックを実施する単一関数ｃｎｅｔ＿ｃｈｋ＿ａｔｔｒ（ ）が存在する。この関数への呼び出しは、カーネルソースにおいて、要求されたコンパートメント化動作を実施するに相応しいポイントで行われる。この関数は、考慮するサブシステムに基づき、そのときに照会されているオペレーションがあるサブシステムに応じてわずかに異なるデフォルトまたは規則規定を実施することができる。たとえば、大半のサブシステムは単純なパーテーション化を実施し、まったく同じコンパートメント番号を有するオブジェクト／資源にしか肯定の値が返されない。しかし、特定の場合では、非特権コンパートメント０および／またはワイルドカードコンパートメント−１Ｌの使用を用いることができ、たとえば、コンパートメント０を分類されていない資源／サービスのデフォルト「サンドボックス」として使用し、ワイルドカードコンパートメントを、シャットダウン前にサブシステム上のすべてのプロセスをリスト化するなど、管理目的に使用することができる。
【０１０２】
図面の図４を参照して、標準ＬｉｎｕｘＩＰネットワーキングについてまず説明する。各プロセスまたはスレッドは、カーネル中のｔａｓｋ＿ｓｔｒｕｃｔ変数で表される。プロセスは、ＴＣＰ／ＵＤＰを介して、ネットワーク通信のためのＡＦ＿ＩＮＥＴドメインにソケットを作成する。これらは、これもまたカーネル中のｓｔｒｕｃｔソケットおよびｓｔｒｕｃｔ ｓｏｃｋ変数の対で表される。
【０１０３】
ｓｔｒｕｃｔ ｓｏｃｋデータ型は、とりわけ、ｓｔｒｕｃｔ ｓｋ＿ｂｕｆｆで表される入力パケットのキューを含む。これはまた、パケット伝送用の予め割り当てられたｓｋ＿ｂｕｆｆのキューも保持する。各ｓｋ＿ｂｕｆｆは、ＩＰスタックの上下に移行するＩＰパケットおよび／またはフラグメントを表す。ｓｔｒｕｃｔ ｓｏｃｋから（または、より具体的には、内部の予め割り当てられた送信キューから）発せられ、伝送のために下方に移行するか、あるいはネットワークドライバから発せられ、ネットワークインタフェースを表すｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅから始まるスタックの底から上方に移行する。下方に移行する場合には、ｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅで効果的に終わる。上方に移行する場合には、通常、待機中のｓｔｒｕｃｔ ｓｏｃｋ（実際、その保留キュー）に送られる。
【０１０４】
ｓｔｒｕｃｔ ｓｏｃｋ変数は、ｓｏｃｋｅｔ（ ）コールによって本質的に間接的に作成され（実際には、実行中のプロセスまでトレースすることができないカーネル自体内のスタックの各種部分が所有するプロトコル単位のプライベートソケットがある）、通常、所有するユーザプロセス、すなわちｔａｓｋ＿ｓｔｒｕｃｔまでトレースすることができる。ｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅ変数は、ループバックインタフェースを含む、システム上の各構成インタフェースに存在する。ローカルホストおよびループバック通信は、速度のためにスタックを横切る高速パスを介して移行するようには見えず、代わりに、リモートホスト通信に予想されるようにスタックの上下に移行する。スタック中の各種ポイントにおいて、パケットインタセプトの目的で、登録されたネットフィルタモジュールにコールすることができる。
【０１０５】
追加のｃｓｅｃｉｎｆｏデータメンバを、ＬｉｎｕｘＩＰネットワーキングにおいて最も一般に使用されるデータ型に追加することにより、カーネル生成応答を含め、システム上で実行中のすべてのプロセスについて、個々のＩＰパケットの所有権、ひいては読み出し／書き込みデータフローのトレースが可能になる。
【０１０６】
したがって、本発明の例示的な本実施形態を容易にするように、標準ＬｉｎｕｘＩＰネットワーキングに使用される少なくとも主要なネットワーキングデータ型を変更した。実際には、本発明の本実施形態を実現するために変更されたデータ構造体の大半は、ネットワーキングに関連するものであり、ネットワーキングスタックおよびソケットサポートルーチンに存在する。タグ付けされたネットワークデータ構造体は、区分けされたＩＰスタックの実施に役立つ。本発明の例示的な本実施形態では、ｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏを包含するように以下のデータ構造体を変更した。
【０１０７】
１．struct task_struct−プロセス（およびスレッド）
２．struct socket−抽象ソケット表現
３．struct sock−ドメイン固有ソケット
４．struct sk_buff−ソケット間のＩＰパケットまたはメッセージ
５．struct net_device−ネットワークインタフェース、たとえばｅｔｈ０ ｌｏ等
セットアップ中、主要なデータ型がタグ付けされると、これらデータ型が新たに初期化された変数をカーネルに導入するように使用されたポイントについて、ＩＰスタック全体がチェックされた。いったん、かかるポイントが識別されると、ｃｓｅｃｉｎｆｏ構造体の継承が確実に実行されるようにコードが挿入された。ｃｓｅｃｉｎｆｏ構造体がＩＰネットワーキングスタックを通して伝播する様式について、より詳細に次に述べる。
【０１０８】
ｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバには、名前の付いた２つのソース、すなわちプロセス単位のｔａｓｋ＿ｓｔｒｕｃｔおよびインタフェース単位のｎｅｔ＿ｄｅｖｉｃｅがある。各プロセスは、特権ｉｏｃｔｌ（ ）により明示的に変更されない限り、親からｃｓｅｃｉｎｆｏを継承する。本発明の例示的な本実施形態では、ｉｎｉｔ−ｐｒｏｃｅｓｓにコンパートメント番号０が割り当てられる。そのため、システムスタートアップ中にｉｎｉｔにより生成されるあらゆるプロセスは、明示的に別にセットされる場合を除き、このコンパートメント番号を継承する。システムスタートアップ中、ｉｎｉｔ−ｓｃｒｉｐｔが通常呼び出されて、定義された各ネットワークインタフェースにコンパートメント番号をセットする。図面の図５は、最も一般的な場合に、ｃｓｅｃｉｎｆｏデータメンバがどのように伝播するかを示している。
【０１０９】
他のデータ構造体はすべて、それぞれのｃｓｅｃｉｎｆｏ構造体をｔａｓｋ＿ｓｔｒｕｃｔから、あるいはｎｅｔ＿ｄｅｖｉｃｅから継承する。たとえば、プロセスがソケットを作成する場合、呼び出しプロセスからカレントｃｓｅｃｉｎｆｏを継承するｓｔｒｕｃｔ ｓｏｃｋｅｔおよび／またはｓｔｒｕｃｔ ｓｏｃｋが作成され得る。ｗｒｉｔｅ（ ）をソケットに呼び出すことによって続けて生成されるパケットは、それぞれのｃｓｅｃｉｎｆｏを発信元ソケットから継承するｓｋ＿ｂｕｆｆを生成する。
【０１１０】
入力ＩＰパケットには、到着したネットワークインタフェースのコンパートメント番号がスタンプされるため、スタックを上方に移行するｓｋ＿ｂｕｆｆは、それぞれのｃｓｅｃｉｎｆｏ構造体を発信元ｎｅｔ＿ｄｅｖｉｃｅから継承する。ソケットに送られる前に、各ｓｋ＿ｂｕｆｆのｃｓｅｃｉｎｆｏ構造体が、期待されるソケットのｃｓｅｃｉｎｆｏ構造体と照らし合わせてチェックされる。
【０１１１】
非リモートネットワーキングの場合、すなわち接続が、以下の形態の規則によって許可される複数のネットワークインタフェースのいずれか１つを通してコンパートメントＸとＹの間が接続される場合には、特別な注意を払わなければならないことは認められよう。
【０１１２】
COMPARTMENT X−＞COMPARTMENT Y METHOD tcp
セキュリティチェックはＩＰネットワーキングには二度、すなわち出力に対して一度、および入力に対して一度行われるため、システムが代わりにこれら規則の存在を探すことを阻止する手段を提供する必要がある。
【０１１３】
COMPARTMENT X−＞HOST a.b.c.d METHOD tcp（出力の場合）
HOST a.b.c.d−＞COMPARTMENT Y METHOD tcp（入力の場合）
これは有効であるが、発信元および宛先のコンパートメントを直接指定する規則に優先しては使用されない場合がある。これを考慮に入れるために、本発明の例示的な本実施形態では、ループバックデバイスに送られるパケットは、それぞれ元のコンパートメント番号を保持し、最終的な送信に単に「反映」させる。この場合、セキュリティチェックは引き渡しに対して行われ、伝送に対しては行われないことに留意する。入力ローカルパケットをロープバックインタフェース上で受け取ると、システムはセットアップされ、パケットのコンパートメント番号がネットワークインタフェースのコンパートメント番号で上書きされず、引き渡しに対する最終的なチェックのためにスタックの上方に移行させる。いったん上方に移行すると、システムは、
HOST a.b.c.d−＞COMPARTMENT Y METHOD tcpの代わりに、
COMPARTMENT X−＞COMPARTMENT Y tcp
の形態の規則をチェックする。これは、ネットワークインタフェース（本発明の例示的な本実施形態におけるネットワークインタフェースは、一般規則として、０ｘＦＦＦＦ００００よりも上の範囲のコンパートメント番号が割り当てられるため、実行中のサービスに割り当てられるコンパートメント番号と区別することができる）に通常割り当てられる形態ではないコンパートメント番号がｓｋ＿ｂｕｆｆに存在するためである。
【０１１４】
規則は一方向性のものであるため、ＴＣＰレイヤは、ｃｏｎｎｅｃｔ（ ）あるいはａｃｃｅｐｔ（ ）の結果としてＴＣＰ接続がセットアップされると、逆データフローを扱う規則を動的に挿入する必要がある。これは、本発明の例示的な本実施形態では自動的に行われ、ＴＣＰ接続が閉じられると、規則は削除される。ｓｔｒｕｃｔ ｓｏｃｋの形態で完全にセットアップされたものとは対照的に、ｓｔｒｕｃｔ ｔｃｐ＿ｏｐｅｎｒｅｑが作成され保留中の接続要求の状態を表す場合には特別な処理が行われる。作成されたリバース規則の参照は、保留中要求とともに格納され、接続要求がタイムアウトするか、ある他の理由により失敗した場合にも削除される。
【０１１５】
この例は、コンパートメント２からリモートホスト１０．１．１．１に接続が行われる場合である。かかる動作を許す元の規則は、以下のようなものであり得る。
【０１１６】
COMPARTMENT 2−＞NET 10.1.1.0/255.255.255.0 METHOD tcp
その結果、リバース規則はこのようなものである（abc/xyzが使用される特定のポート番号）。
【０１１７】
HOST 10.1.1.1 PORT abc−＞COMPARTMENT 2PORT xyz METHOD tcp
コンパートメント単位のルーティングテーブルをサポートするために、各ルーティングテーブルエントリにｃｓｅｃｉｎｆｏ構造体がタグ付けされる。本発明の例示的な実施形態における、変更された各種データ構造体は以下である。
【０１１８】
１．struct rt_key
２．struct rtable
３．struct fib_rule
４．struct fib_node
ルートコマンドを使用してルートを挿入すると、ユーザプロセスの呼び出しコンテキストから受け継いだｃｓｅｃｉｎｆｏ構造体を有するルーティングテーブルエントリが挿入される。すなわち、ユーザがコンパートメントＮ中のシェルからルートコマンドを呼び出すと、追加されるルートに、コンパートメント番号としてＮがタグ付けされる。ルーティングテーブル情報を見ようという試み（通常、／ｐｒｏｃ／ｎｅｔ／ｒｏｕｔｅおよび／ｐｒｏｃ／ｎｅｔ／ｒｔ＿ｃａｃｈｅを調べることにより）は、呼び出しユーザプロセスのｃｓｅｃｉｎｆｏ構造体の値に基づく。
【０１１９】
ｓｋ＿ｂｕｆｆがとるべき入出力ルートの判定に使用される主なルーチンは、ｉｐ＿ｒｏｕｔｅ＿ｏｕｔｐｕｔ（ ）およびｉｐ＿ｒｏｕｔｅ＿ｉｎｐｕｔ（ ）である。本発明の例示的な本実施形態では、これらのルーチンが、あらゆるルーティングテーブル参照の土台であるｃｓｅｃｉｎｆｏ構造体へのポインタからなる追加の引数を含むように拡張されている。追加されるこの引数は、入力あるいは出力のためにルーティングされているパケットのどちらか一方のｓｋ＿ｂｕｆｆから与えられる。
【０１２０】
カーネルに挿入されたルーティングエントリは、特別な状態を有し、ワイルドカードコンパートメント番号（−１Ｌ）が挿入される。コンパートメント単位ルーティングの状況では、すべてのコンパートメントがこういったエントリを共有することができる。かかる機構の主な目的は、入力パケットをスタックに適宜ルーティング可能にすることである。セキュリティチェックはいずれも、ｓｋ＿ｂｕｆｆがソケット（またはｓｋ＿ｂｕｆｆキュー）で送られる直前に、より上位のレベルで行われる。
【０１２１】
最終的な効果は、各コンパートメントが、デフォルトでは空のルーティングテーブルをそれぞれ個々に有するように見えることである。あらゆるコンパートメントは、システム全体のネットワークインタフェースを共用する。本発明の例示的な本実施形態では、個々のコンパートメントを、利用可能なネットワークインタフェースの限られた部分集合に制限することが可能である。これは、各ネットワークインタフェースが概念的にそれぞれのコンパートメントにある（それぞれのルーティングテーブルとともに）ためである。実際、ＩＣＭＰエコー要求に応答して、個々の各インタフェースは、オプションとして、ルーティングテーブルエントリをタグ付けして、プロトコル単位のＩＣＭＰソケットを出力パケットにルーティング可能にするように構成することができる。
【０１２２】
他のサブシステム
＊ＵＮＩＸドメインソケット−各ＵＮＩＸドメインソケットもまた、ｃｓｅｃｉｎｆｏ構造体がタグ付けされる。これらもｓｋ＿ｂｕｆｆを使用して、接続されたソケット間を移行するメッセージ／データを表すため、上述したＡＦ＿ＩＮＥＴドメインが使用する機構の多くも同様に適合する。加えて、セキュリティチェックもまた、ピアに接続する試みがある都度行われる。
【０１２３】
＊システムＶ ＩＰＣ−上に列挙した各ＩＰＣ機構は、同様にｃｓｅｃｉｎｆｏ構造体がタグ付けされた専用カーネル構造体を使用して実施される。これら構造体へのメッセージのリスト化、追加または除去を行おうとする試みは、個々のｓｋ＿ｂｕｆｆと同じセキュリティチェックの対象となる。セキュリティチェックは、使用される機構の厳密なタイプに依存する。
【０１２４】
＊プロセス／スレッド−個々のプロセス、すなわちｔａｓｋ＿ｓｔｒｕｃｔにはｃｓｅｃｉｎｆｏ構造体がタグ付けられるため、大半のプロセス関連演算は、プロセスのコンパートメント番号の値に基づくことになる。特に、プロセスリスト化（／ｐｒｏｃインタフェースを介して）は、コンパートメント単位のプロセスリスト化の効果を上げるように制御される。信号送出は、コンパートメントが切り換えられ、そのために１ビット隠れチャネルを構成している場合もある親プロセスへの信号送出に関して考慮すべき問題があるため、いくらか複雑である。
【０１２５】
システムデフォルト
プロトコル単位のソケット−ＬｉｎｕｘＩＰスタックは、特別なプライベートプロトコル毎ソケットを使用して、ＩＣＭＰ応答等デフォルトの各種ネットワーキングの振る舞いを実施する。これらプロトコル毎のソケットは、どのようなユーザレベルソケットにも限定されず、通常、ワイルドカードコンパートメント番号で初期化され、ネットワーキング関数が通常通り振る舞えるようにする。
【０１２６】
コンパートメント０の非特権デフォルトとしての使用−規定は、コンパートメント０による他のコンパートメントおよびネットワーク資源へのアクセスを許可する規則をいずれも決して挿入しないというものである。このように、初期化されたオブジェクト、または適宜説明されていないオブジェクトのデフォルトの振る舞いは、賢明で限定的なデフォルトに分類される。
【０１２７】
デフォルトカーネルスレッド−各種カーネルスレッド、たとえば、数例を挙げればｋｓｗａｐｄ、ｋｆｌｕｓｈｄ、およびｋｕｐｄａｔｅがデフォルトで現れ得る。これらスレッドにもｔａｓｋ＿ｓｔｒｕｃｔ毎にｃｓｅｃｉｎｆｏ構造体が割り当てられ、それぞれのコンパートメント番号は、それぞれの相対的な非特権状態を反映してデフォルトで０である。
【０１２８】
ｒｏｏｔＩＤの奪取に対抗してのコンパートメント封印−個々のコンパートメントは、オプションとして、そのコンパートメント中のプロセスがｓｅｔｕｉｄ（０）および友人（friends）の呼び出しが成功しないように、またいかなるＳＵＩＤ−ｒｏｏｔバイナリも実行されないように「封印」と登録することができる。これは通常、一般に悪意のあるコードの実行につながるバッファオーバーフロー攻撃を受けやすい場合がある外部アクセス可能なサービスに使用される。かかるサービスが最初に擬似ユーザ（非ｒｏｏｔ）として実行されるように制限され、また中で実行するコンパートメントが封印されている場合、バッファオーバーフロー攻撃および／または外部命令の実行によりｒｏｏｔアイデンティティを奪取する試みはいずれも失敗する。なお、ｒｏｏｔとして実行中の既存プロセスは、いずれも実行し続ける。
【０１２９】
上に述べたカーネル変更は、保護されたコンパートメント中の個々のユーザレベルサービスのホスティングのサポートに役立つ。これに加えて、本発明の例示的な本実施形態においてサービスを追加または除去する際に使用されるレイアウト、ロケーション、および規定についてこれより述べる。
【０１３０】
個々のサービスには一般にそれぞれコンパートメントが割り当てられる。しかし、エンドユーザがサービスとして認めるものは、実際には結局いくつかのコンパートメントを使用することになる場合がある。例は、それぞれ個々のコンパートメントにおいてＣＧＩバイナリを実行する高信頼性ゲートウェイエージェントをホストする別のコンパートメントに対する狭いインタフェースを備えた外部アクセス可能なウェブサーバをホストするコンパートメントの使用である。この場合、少なくとも３つのコンパートメントが必要である。
【０１３１】
＊ウェブサーバプロセス用のコンパートメント
＊ＣＧＩバイナリを実行する高信頼性ゲートウェイエージェント用のコンパートメント
＊高信頼性ゲートウェイはそれぞれの構成コンパートメントにおいてＣＧＩバイナリをフォーク／実行するため、ＣＧＩバイナリの適宜分類に必要な数のコンパートメント
あらゆるコンパートメントは名前を有し、／ｃｏｍｐｔの下でｃｈｒｏｏｔ可能な環境として常駐する。本発明の例示的な実施形態において使用する例は、以下を含む。
【表１】
【０１３２】
加えて、以下のサブディレクトリも存在する。
【０１３３】
１．/compt/etc/cac/bin−コンパートメント管理用の各種スクリプトおよびコマンドラインユーティリティ
２．/compt/etc/cac/rules−システム上の登録されたあらゆるコンパートメントの規則を含むファイル
３．/compt/etc/cac/encoding−ｃａｃｃユーティリティ、たとえばコンパートメント名マッピングの構成ファイル
コンパートメントの総称的な開始／停止をサポートするために、各コンパートメントは少数の基本的な要件を満たす必要がある。
【０１３４】
１．コンパートメントロケーション／ｃｏｍｐｔ／＜ｎａｍｅ＞下でｃｈｒｏｏｔ可能であること。
【０１３５】
２．コンパートメントの開始／停止に／ｃｏｍｐｔ／＜ｎａｍｅ＞／ｓｔａｒｔｕｐおよび／ｃｏｍｐｔ／＜ｎａｍｅ＞／ｓｈｕｔｄｏｗｎを提供すること。
【０１３６】
３．スタートアップおよびシャットダウンスクリプトが、規則挿入、ルーティングテーブル作成、ファイルシステム搭載（たとえば、／ｐｒｏｃ）、および他のサービス毎の初期化ステップに対する責任を有すること。
【０１３７】
一般に、コンパートメントを外部から見えるようにすべき場合、そのコンパートメント中のプロセスは、デフォルトによりｒｏｏｔとして実行すべきではなく、コンパートメントは初期化後に封印すべきである。統合／移植されているレガシーアプリケーションの性質により、これが可能ではない場合もあり、その場合には、プロセスがｃｈｒｏｏｔ−ｊａｉｌ、たとえばｃａｐ＿ｍｋｎｏｄをエスケープしないように、可能な限り多くの機能を除去することが望ましい。
【０１３８】
各種管理スクリプトは各構成コンパートメントのファイルシステムにアクセスする必要があり、またこれら管理スクリプトは、管理ウェブサーバのＣＧＩインタフェースを介して呼び出されることから、これらスクリプトは正常なコンパートメントとして、すなわち／ｃｏｍｐｔ／＜ｎａｍｅ＞下に常駐することができないと言える。
【０１３９】
本発明の例示的な本実施形態では、使用される手法は、あらゆる構成コンパートメントの管理スクリプトのｃｈｒｏｏｔ可能な環境を封じ込めるが、その環境が確実にホストファイルシステムの限られた部分集合であるようにするというものである。自然な選択としては、管理スクリプトのｃｈｒｏｏｔ−ｊａｉｌにｒｏｏｔ ａｔ／ｃｏｍｐｔを持たせる。結果得られる構造を図面の図１１に模式的に示す。
【０１４０】
コンパートメントは、／ｃｏｍｐディレクトリ下のｃｈｒｏｏｔ化環境として存在するため、アプリケーションの統合に必要なのは、確実にｃｈｒｏｏｔ化環境で働くようにするために使用される普通の技法である。一般的な技法では、インストールされたソフトウェアの最小ＲＰＭデータベースを含む、最小実行中のコンパートメントのｃｐｉｏ−ａｒｃｈｉｖｅを用意する。所望のアプリケーションをこのトップにインストールすることが普通であり、ＲＰＭの形態のアプリケーションの場合、以下のステップを行うことができる。
【０１４１】
root@tlinux# chroot/compt/app1
root@tlinux# rpm-install＜PRM-package-filename＞
root@tlinux# [必要に応じて構成ファイル、たとえばｈｔｔｐｄ．ｃｏｎｆを変更]
root@tlinux# [スタートアップ／シャットダウンスクリプトを／ｃｏｍｐｔ／ａｐｐ１に作成]
後の少数のステップは、ＲＰＭインストール段階に統合することができる。ディスクスペースの削減は、検査、すなわちｒｐｍコマンドを介して使用されていないパッケージを選択的にアンインストールすることによって実現することができる。必要であれば、コンパートメントの／ｄｅｖディレクトリ中にエントリをさらに作成することができるが、通常、／ｄｅｖは殆どの場合、実質的にありのままである。さらなる自動化は、ウェブベースのインタフェースを上記プロセスに提供して、インストールするアプリケーションの各タイプに必要なパラメータをすべて与えることによって実現することができる。かかるアプリケーションのコンパートメントアウェアバリアントをインストールする必要がある場合を除いて、コンパイルされたバイナリを変更する必要は一般にない。
【０１４２】
本発明の一態様の特定の実施形態について詳細に上述した。しかし、多種多様な異なる技法を、本発明によって提供されるコンテインメントの一般的な概念の実施態様に使用することができる。オペレーティングシステムの書き換えは、可能な限り多くのユーザレベルアプリケーションを再使用可能である必要があるため、明らかに望ましくない。このため介在技法（interposition technique）があり、そのうちのいくつかを以下に列挙する。介在技法は、主にユーザレベルで動作しているもの、あるいはカーネルベースで動作しているものに分類することができる。
【０１４３】
ユーザレベルの技法
以下に、３つの一般的なユーザレベルの技法または機構について概説する。
【０１４４】
１．ｓｔｒａｃｅ（ ）機構
この機構は、システムカーネルに構築された機能を使用して、選択されたプロセスの各システムコールをトレースする。この機構を使用すると、各システムコールおよびその引数を識別することができ、システムコールは通常、規定されたセキュリティポリシーに従って続行許可されるか（引数が変更されることがある）、あるいは失敗する。
【０１４５】
この機構は、多くのアプリケーションに適しているが、いくつかの欠点を有する。これら欠点の１つは、トレースされているプロセスＰが、ｆｏｒｋ（ ）システムコールから戻る前に実行がスケジューリングされた子Ｑをフォークする可能性がある「子の暴走（runaway child）」問題の場合に明らかになる。ｓｔｒａｃｅ（ ）は、プロセスＩＤ（ＰＩＤ）を使用してプロセスに添付することによって働き、ＱのＰＩＤは、Ｑが実際に実行をスケジューリングされる前にＰ（ひいてはトレーサ）に必ずしも戻されるわけではないため、トレーサを添付することができるようになる前に、Ｑが任意の長さのコードの実行を許可されてしまう危険性がある。
【０１４６】
この問題に対する１つの方策は、まだトレースされていないプロセスについてカーネル中のあらゆるシステムコールをチェックし、トレーサが最終的に追いつくことができるように、たとえば、まだトレースされていないプロセスを強制的に「スリープさせる」ことにより、その場所に留めることである。しかし、この方策では、追加のカーネルコンポーネントが必要である。
【０１４７】
２．システムコールラッピング
この機構の別の欠点は、トレースされたシステムコールへの引数が変更されることがある競合状況が存在する場合に発生する。これが発生する期間は、トレーサが引数のセットを検査するときから、実際にシステムコールの続行を許可するときまでである。トレースされたプロセスと同じアドレス空間を共有するスレッドは、この間隔中にメモリにおける引数を変更することができる。
【０１４８】
この機構を使用すると、トレースする必要のあるプロセスに対してリンクされた、システムコールへのラッパを含む動的リンク共有ライブラリを用いてシステムコールをラップすることができる。こういったラッパは、予め定義されたセキュリティポリシーに従って判定を行うモジュールへのコールアウトを含むことができる。
【０１４９】
この機構に関連する１つの欠点は、プロセスが使用するものと想定されるシステムコールが未解決の外部参照ではなく、動的ローダによりリンクすることができない場合に容易に破壊される可能性があることである。また、レジスタのセットアップが通常のシステムコールのように正しい状態で、プロセスがソフト割り込み自体を実行する場合、システムコールにラッパを迂回させることも可能である。この場合、カーネルは、ラッパに渡すことなくコールを処理する。加えて、場合によっては、ＬＤ＿ＰＲＥＬＯＡＤ環境変数への依存もまた、許容できない弱いリンクであることもある。
【０１５０】
３．ユーザレベルの認証サーバ
このカテゴリは、カーネルへのプライベートチャネルを介して与えられるデータに対して作用するユーザ空間における認証サーバを含む。この手法は、多くの場合に非常に効果的であるが、いくつかの欠点を有する。すなわち、Ｉ）チェック中の各システムコールが少なくとも２つのコンテキスト切り換えを受け、この方策が比較的低速になること、ｉｉ）割り込みルーチンが、スリープしないという要件によりユーザ空間カーネルにブリッジすることがより難しいこと、およびｉｉｉ）カーネルレベルのコンポーネントが通常、強制トレースを実施する必要があること、である。
【０１５１】
上に概説したユーザレベル手法の欠点にも関わらず、本発明の一態様による高信頼性オペレーティングシステムを実施するユーザレベル技法は、開発および維持が比較的容易であるという利点を有するが、状況によっては、システム全体の強制制御の実施には不十分なことがある。
【０１５２】
最終的に、本発明の目的は、実行中のアプリケーションを封じ込めることであり、これは好ましくは、セキュリティ管理者により直接許可されていないエージェントが自由裁量ベースで無効とすることができない一連の強制アクセス制御によって実施される。実行中の第三者アプリケーションにトランスペアレントなコンテインメントの実施は、カーネルレベルのアクセス制御によって実現することができる。考えられるエントリポイントを調べ、互いの中および互いに対するカーネルサブシステムの相互作用を分離することにより、カーネルおよびその資源のビューを実行中のアプリケーションに関してセグメント化することが可能になる。
【０１５３】
かかるセグメント化方式は、カーネル自体内での実施により強制的な性質のものであり、コンテインメント方式を明らかに承知して、それを利用するように書き換えられた場合を除き、実行中のアプリケーションによって無効とされる可能性がある自由裁量的な側面がない。
【０１５４】
本発明を実施するカーネルレベルの手法の３つの例を以下に概説し、図面の図６に示す。第１の手法は主に、カーネルおよびその内部データ構造へのパッチに基づく。第２の手法は、いずれのカーネルパッチもまったく必要としないという点においてまったく異なり、代わりに、選択されたシステムコールを置き換え、おそらく実行時のカーネルのイメージを変更することによって動作する動的ロード可能カーネルモジュールである。これら手法は両方とも、通常、カーネルへのプライベートチャネルを介して動作するユーザレベルの構成ユーティリティを必要とする。第３の手法は、第１の手法によって提供される絶対制御と、第２の手法によって提供されるカーネルソース変更からの独立とを折衷したものである。
【０１５５】
１．コンテインメントをサポートするようにするソースレベルでのカーネル変更（Ｖ１）
この手法は、標準オペレーティングシステム（この場合、Ｌｉｎｕｘ）のカーネルソースへの一連のパッチとして実施される。規則テーブルの維持に必要なロジックをホストし、また、カーネルとユーザ空間構成ユーティリティとの間のインタフェースとしても動作する動的ロード可能カーネルモジュールもある。カーネルモジュールは、初期にブートシーケンスに挿入され、定義された規則がない状態で限定セキュリティモデルを即座に実施する。これに先立って、カーネルは、すべてのプロセスが、機能可能であるが、本質的に大半の目的に役立たないデフォルトコンパートメント０で生成される状態で、適切にブートできるように設計された限定セキュリティモデルを実施する。カーネルモジュールがロードされると、カーネルは内蔵モデルからモジュールにおけるモデルに切り替わる。コンテインメントは、カーネル資源をタグ付けし、タグの値および規定されているかもしれないあらゆる規則に応じてこれら資源へのアクセスを分割することによって実現される。
【０１５６】
したがって、保護が必要な各カーネル資源は、資源が属するコンパートメントを示すタグで拡張される（上に述べたように）。コンパートメントは、カーネル内の単一ワードサイズの値によって表されるが、ユーザレベル構成ユーティリティはより記述的なストリング名を使用する。かかる資源の例としては、以下を記述するデータ構造体が挙げられる。
【０１５７】
＊個々のプロセス
＊共有メモリセグメント
＊セマフォ、メッセージキュー
＊ソケット、ネットワークパケット、ネットワークインタフェース、およびルーティングテーブル照会
本発明の例示的な実施形態によるこのコンテインメント手法をサポートするように変更されたデータ構造体の完全なリストを本明細書に添付した付録７．１に示す。上で説明したように、タグの割り当ては主に継承を通して行われ、ｉｎｉｔ−プロセスはまずコンパートメント０に割り当てられる。プロセスによって作成されるあらゆるカーネルオブジェクトは、実行中プロセスのカレントラベルを継承する。カーネルの適切なポイントで、アクセス制御チェックが、別のコンパートメントの資源へのアクセスが許可されているコンパートメントを示す規則テーブルを照会する動的ロード可能セキュリティモジュールへのフックの使用を通して行われる。これは、実行中アプリケーションにトランスペアレントに行われる。
【０１５８】
各セキュリティチェックでは、規則テーブルを照会する。上に述べたように、各規則は以下の形態を有する。
【０１５９】
source−＞destination method m[attr][netdev n]
ただし、ｓｏｕｒｃｅ／ｄｅｓｔｉｎａｔｉｏｎは、以下のうちの１つである。
【０１６０】
ＣＯＭＰＡＲＴＭＥＮＴ（名前の付いたコンパートメント）
ＨＯＳＴ（固定ＩＰｖ４アドレス）
ＮＥＴＷＯＲＫ（ＩＰｖ４サブネット）
ｍ：サポートされるカーネル機構。たとえば、ｔｃｐ、ｕｄｐ、ｍｓｇ（メッセージキュー）、ｓｈｍ（共有メモリ）等
ａｔｔｒ：メソッドｍをさらに修飾する属性
ｎ：妥当な場合には、名前の付いたネットワークインタフェース、たとえばｅｔｈ０
「ＷＥＢ」と名前の付いたコンパートメント中のプロセスが、たとえば、ｓｈｍａｔ／ｓｈｍｄｔ（ ）を使用して、「ＣＧＩ」と名前の付いたコンパートメントの共有メモリセグメントへアクセスするのを許可するような規則の例は、以下のようなものである。
【０１６１】
COMPARTMENT:WEB−＞COMPARTMENT:CGI METHOD shm
特定の暗黙の規則も存在し、コンパートメント内で実行されるある通信を許可する、たとえば、プロセスによる、同じコンパートメントに常駐するプロセスのプロセス識別子の検査を許可することができる。これにより、そうでなければ構成されていないコンパートメント内の機能を必要最小限にすることができる。例外はコンパートメント０であり、これは相対的に非特権であり、より多くの制限が課される。コンパートメント０は通常、カーネルレベルスレッド（スワッパ等）をホストするために使用される。
【０１６２】
コンパートメント間アクセスの実行を明示的に許可する規則がない場合、かかる試みはすべて失敗する。規則の最終的な効果は、別のコンパートメントの資源へのアクセスが明示的に許可されているものを除き、個々のコンパートメントにわたって強制セグメント化を実施することである。
【０１６３】
規則は方向的な性質のものであり、ＴＣＰソケット接続の接続／受け入れの振る舞いに合致する影響を有する。許される入力ＨＴＴＰ接続の指定に使用される以下の形式の規則を考える。
【０１６４】
HOST*−＞COMPARTMENT X METHOD TCP PORT 80
この規則は、ポート８０上の入力ＴＣＰ接続のみが許可され、出力接続は許可されないことを指定する（図７参照）。規則の方向性により、出力接続の実行を許可することなく、入力接続を正しく確立するために、パケットの逆流を行うことが可能である。
【０１６５】
上に述べた手法にはいくつかの利点がある。たとえば、サポートされる各サブシステムに対して完全なる制御を提供するとともに、サポートされていないもの、たとえば、ハードウェア駆動のカード間転送をコンパイルアウトする機能を提供する。さらに、この手法は、ｐｓ、ｎｅｔｓｔａｔ、ｒｏｕｔｅ、ｉｐｃｓ等のユーザ空間コマンドを変更する必要なく、比較的包括的な名前空間区分けを提供する。プロセスが現在入っているコンパートメントに応じて、可視の識別子のリストが規則に何が指定されているかに従って変更される。名前空間の例としては、プロセステーブル、ｖｉａ／ｐｒｏｃ、ＳｙｓＶ ＩＰＣ資源識別子、アクティブで閉じられたリスニング中のソケット（すべてのドメイン）、およびルーティングテーブルエントリが挙げられる。
【０１６６】
この手法の別の利点は、カーネルおよびその実行中プロセスに関しての同期状態である。スカラータグが各種カーネル資源に添付されることを鑑みて、完全な生存期間にわたる追跡を行う必要がなく、これは、カーネル変数が作成／消費される場所を深く理解する必要があまりないため、パッチを最新に保つという問題を考えた際に大きな利点である。さらに、セキュリティタグの継承は、＃ｉｆｄｅｆｓおよびクローンルーチンを使用することにより明示的に指定する必要がある場合とは異なり、普通のＣ割り当て演算子（＝）またはｍｅｍｃｐｙ（ ）を通して自動的に行われるため、行う必要のあるソース変更はより少ない。
【０１６７】
加えて、アクティブ化されるときに、カーネル資源を再帰的に列挙する必要がない。これは、かかる計算がカーネル開始時に行われるためである。さらに、この手法は、行われるソース変更の数が比較的少ないため、比較的高速なパフォーマンス（最適の約１〜２％）を提供する。システムの使用意図に応じて、内部ハッシュテーブルは、挿入された規則が各ハッシュバケット内で平均して１レベル深さである（これにより、規則参照ルーチンの振る舞いがＯ（１）のオーダになる）ように構成することができる。
【０１６８】
しかし、多くの利点に関わらず、この手法では、ソース変更をカーネルに対して行う必要があり、また、新しいカーネル改訂が入手可能になったときにパッチをアップデートする必要がある。さらに、構造サイズが異なる可能性があるため、モジュールとして配布されるプロプラエタリデバイスドライバは使用不可である。
【０１６９】
２．動的ロード可能カーネルモジュールを介してのシステムコール置換（Ｖ２）
この手法は、動的ロード可能カーネルモジュールの形態でコンテインメントを実施することを含み、上に概説したソースレベルカーネル変更手法の機能を、カーネルソースを変更する必要なく再現することを意図した手法を表す。
【０１７０】
この手法では、モジュールは、選択されたシステムコールをｓｙｓ＿ｃａｌｌ＿ｔａｂｌｅ［］アレイを上書きすることによって置換し、また、それ自体をｎｅｔｆｉｌｔｅｒモジュールとして登録して、入力／出力ネットワークパケットをインタセプトする。モジュールは、システム上の各実行中プロセスが要求する資源を反映し、インタセプトされたシステムコールの適切な時点でアップデートされるプロセスＩＤ（ＰＩＤ）駆動内部状態テーブルを保持する。これらテーブルは、所望の実施態様に応じてプロセス単位あるいは資源単位でセキュリティ属性も含むことができる。
【０１７１】
この手法の規則形式およびシンタックスは実質的に、上に概説したソースレベルカーネル変更手法に関して述べたようなものであり、同様に振る舞う。セグメント化は、システムコールレイヤにおける名前空間の区分けを通して行われる。元のシステムコールを介してのカーネル資源へのアクセスは、実際にシステムコールを行う前に行われるセキュリティチェックを条件としている。
【０１７２】
すべてのシステムコールの置換は、この手法におけるシステムコールの取り扱い方の条件的な性質を反映した独特なｐｒｅ／ａｃｔｕａｌ／ｐｏｓｔ形態を有する。
【０１７３】
したがって、この手法には、カーネル変更が必要ないという利点があるが、カーネル内部の知識が要求される。さらに、セキュリティモジュールが一時的にディセーブルされている間にシステムを実行する機能により、バグの分類がより容易になる。
【０１７４】
この手法と併せて考慮すべきいくつかの欠点および／または問題もある。第１に、実行中のプロセスに関して真に同期する状態を保つことは、主に包括的なカーネルイベント通知機構の欠如に起因する様々な理由から困難である。たとえば、ＳＩＧＳＥＧＶ、ＳＩＧＢＵＳ等によりプロセスが異常に終了する状況を捕捉する正式な機構はない。この問題に提案されている１つの方策は、ｄｏ＿ｅｘｉｔ（ ）に対してわずかなソースコード変更を行い、かかる場合を捕捉するコールバックを提供することを含む。例示的な一実施形態では、カーネルレベル刈り取り（reaper）スレッドを使用して、グローバルタスクリストを監視し、死んだＰＩＤに対してガーベッジコレクション（ごみ収集）を行うことができる。これにより、不安定な短い期間が導入されるが、これは、ＰＩＤのサイクルが上向きであること、および刈り取りスレッドの単一サイクル内で以前使用されたＰＩＤが再度割り当てられる可能性が比較的低いことによっていくらか相殺される。
【０１７５】
上に述べた子の暴走問題に関して、ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅは、おそらくは子が実行するようにスケジューリングされた後まで、子のＰＩＤを戻さない。モジュール実施によりＰＩＤ駆動状態テーブルが作成される場合、これは、子に対する状態エントリが作成される前に、子がシステムコールを呼び出す可能性があることを意味する。子プロセスに添付する必要性があるためにフォークされた子を適宜辿ることができないｓｔｒａｃｅコマンド（上述）にも同じ問題がある。この問題に対して考えられる１つの方策は、必須条件チェックですべてのシステムコールをインタセプトすることであるが、この方策は比較的遅く、状況によっては効果がない。
【０１７６】
考えられる別の方策は比較的複雑であり、本明細書に添付した付録７．２に示される。
【０１７７】
１．ｆｏｒｋ（ ）−親のスタック上のリターンアドレスが、スタックをユーザ空間に書き込むことによって実際のｆｏｒｋ（ ）システムコールを呼び出す前に変更される。これは、変更されたリターンアドレスを継承する子に引き継がれる。変更されたリターンアドレスは元の値よりも５バイト前のポイントにセットされ、これによりｆｏｒｋ（ ）システムコールが子によって最初のアクションとして再び呼び出される。次いで、システムはこれをインタセプトし、必要な状態エントリを作成する。親は、ｆｏｒｋ（ ）から戻る直前に、保存されているリターンアドレスを回復させ、通常通り続行する。（５バイトはまさにＩＡ−３２のｆａｒ ｃａｌｌの形態の命令の長さであることに留意する。他のバリアントは、ＬＤ＿ＰＲＥＬＯＡＤおよび所望の５バイト形態を有するシステムコールラッパを使用してラップすることができる）
２．ｃｌｏｎｅ（ ）−スタックのセットアップが異なるため、フォークされた子（上述したように）がクローン化された子を取り扱うには不適切な場合に用いられるメソッド。代わりに提案されている方策は、以下である。
【０１７８】
ａ．ユーザプロセスの代わりにｂｒｋ（ ）を呼び出し、小さな２５６バイトの塊のメモリを割り当てる。
【０１７９】
ｂ．用意された実行可能コードの塊を新たに割り当てられたこのメモリにコピーする。このコードは、クローン化された子を通常通り処理する前に、指定されたシステムコールを呼び出すであろう。
【０１８０】
ｃ．ｃｌｏｎｅ（ ）への呼び出しにおいて与えられる元のルーチンの代わりに、この新たに用意されたコードの塊を実行するように、ユーザプロセスのスタックを変更する。
【０１８１】
ｄ．ユーザプロセスによって与えられたルーチンへの元のポインタをクローンに保存する。
【０１８２】
クローン化された子が最初に実行されるとき、ポインタを、実行すると想定されていた元のルーチンに戻すシステムコールを行う、用意されたコードの塊を実行する。子はこのポイントでトラップされ、これに対して状態エントリが作成される。次いで、クローン化された子が通常通り元のルーチンを実行する（本明細書に添付した付録７．４を参照）。
【０１８３】
両方の場合において、子はカーネルモジュールに下がって呼び出すように強制され、そこで子をトラップすることができる。
【０１８４】
考えられる別の方策は、子が作成される都度、コールバックを提供するように、カーネルにおけるｒｅｔ＿ｆｒｏｍ＿ｆｏｒｋ（ ）ルーチンを変更することである。代替としては、ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅを実施するｄｏ＿ｆｏｒｋ（ ）カーネル関数を変更することができる。
【０１８５】
ｃｌｏｓｅ−ｏｎ−ｅｘｅｃ振る舞いの追跡もまた、この実施態様では、各プロセス構造体内のファイルシステム関連構造体を熟知していなければ難しい。
【０１８６】
この手法と併せて考慮すべき別の問題は、カーネル資源の事後列挙が、ブートシーケンスが進むにつれて累進的に難しくなることから、可能な限り早くカーネル資源の監視を開始するために、通常、モジュールがブートシーケンスのかなり初期にロードされることである。この手法においてシステムコール引数の有効性をチェックするプロセスが、元のシステムコールではなくカーネルモジュールにシフトされることにも留意されたい。したがって、元のカーネルは変更されないため、この手法ではオーバヘッドがさらにもたらされる。同様に、実質的に複製された状態情報をカーネルから離れて維持することにより、メモリ使用およびプロセッササイクルに関してオーバヘッドが追加される。
【０１８７】
さらに別の欠点は、コンパートメント毎のルーティングおよびこれに依存する機構、すなわち仮想化ＡＲＰキャッシュ、ならびにルートを使用してバックエンドネットワークアクセスをセグメント化する機能が失われることである。これは、タグ付きデータ構造体なしでルーティングコードが変更されずに実行されるためである。最後に、すべての構成を満足させる単一バイナリモジュールを提供することは、不可能でないとしても非常に困難であると考えられる。構造体内のデータメンバのサイズおよびレイアウトは、その特定のカーネルビルドにおける構成オプションに依存する。たとえば、ｎｅｔｆｉｌｔｅｒのコンパイルを指定すると、あるネットワーキング関連データ構造体のサイズおよびレイアウトが変更される。
【０１８８】
動的ロード可能カーネルモジュールの配備と併せて考慮すべきいくつかの問題がある。特定のカーネルデータ構造体のサイズは、構築時に決定される実際の構成オプションに依存する、すなわちデータメンバの数は、カーネルにおいてコンパイルするように選択された機能が何であるかに応じて可変であるため、モジュールをカーネルに整合させる必要性が極めて重要である。したがって、モジュールは既知のカーネルに対して構築することができ、この場合、ソースおよび構成オプション（構成ファイルに表される）を容易に入手可能であり、あるいはインストール時に構築することができ、この場合、モジュールへのソースはインストール場所まで運ぶ必要がある。
【０１８９】
３．カーネルベースの変更をサポートするハイブリッドシステムコール置換
図面の図８を参照して、上に述べた変更カーネルベースの手法（Ｖ１）とシステムコール置換手法（Ｖ２）の特徴のいくつかを組み合わせたハイブリッドコンテインメントオペレーティングシステムの構築に利用可能なオプションのいくつかを模式的に示す。
【０１９０】
実行中のカーネルに関しての状態維持について、Ｖ１手法は、適切な通知機構が欠如していること、およびガーベッジコレクション（ごみ収集）が必要なことから歩調がわずかにずれたままであるＶ２と比較して、カーネルの実際の動作とはるかに密接に歩調を揃えている。Ｖ１での状態情報は、カーネルに関して厳密に同期し、Ｖ２は非同期である。同期性は、内部状態テーブルが、通常、同期プリミティブの取得によってバウンディングされる同じコードセクション内の実際のカーネル状態の変更に伴ってロックステップでアップデートされるか否かによって決まる。同期の必要性を図面の図９に示し、図中、組み込まれたソースから生じるカーネル状態の変更は、介在レイヤにおける複製状態に反映する必要がある。
【０１９１】
再び図面の図８を参照すると、Ｖ１およびＶ２の手法を併せた相対的な利点は、開発者が、略同期状態を実現するためにカーネルソースを変更したいと望む強度に応じて、Ｖ１手法が代表する同期状態の位置と、Ｖ２手法によって提供される非同期状態の位置との間で可変的に決められる。図８は、Ｖ２手法を変更することで、カーネルソースコード変更という相対的にわずかな犠牲で大きな利点が得られる３つのポイントを示す。
【０１９２】
１．ｄｏ＿ｅｘｉｔ（ ）−ｄｏ＿ｅｘｉｔ（ ）カーネル関数を５ライン変更すると、コールバックを提供して、プロセスの異常終了によるグローバルタスクリストの変更を捕捉することが可能になる。かかる変更は、プロセス終了がどのように処理されたかについて知る必要はないが、制御パスがどこにあるかを理解する必要がある。
【０１９３】
２．ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅ−ｄｏ＿ｆｏｌｋカーネル関数をさらに５ライン変更すると、実行するようにスケジューリング可能になる前に子のＰＩＤを適宜通知することが可能になる。代替は、ｒｅｔ＿ｆｒｏｍ＿ｆｏｒｋ（ ）を変更することであるが、これはアーキテクチャ依存である。これらオプションのいずれでも、プロセスセットアップの知識は必要なく、ＰＩＤ作成の性質およびＰＩＤ関連構造体を取り巻くロックを認識している必要があるだけである。
【０１９４】
３．割り込み、ＴＣＰタイマ等−このカテゴリは、ハード／ソフトＩＲＱ、ｔａｓｋｌｅｔ、内部タイマ、またはユーザプロセスにトレース不可能なあらゆる実行コンテキストのいずれかの結果としてカーネルにおいて非同期に実行されるすべての動作を網羅する。例は、閉じられたが、まだ完全に消失していないソケットを維持するために使用されるＴＣＰ時間待ちハッシュバケットである。ハッシュテーブルは、パブリックにエクスポートされず、ハッシュテーブルの変更は、コールバック用に正式なＡＰＩがないため追跡することができない。パケット単位で計算を行う必要がある（これは、Ｖ１手法の主要な利点であり、ここからいくつかの特徴が導出される）場合、このカテゴリのカーネルソースへの変更が必要である。しかし、これら（比較的広範な）変更を実行するためには、サブシステムの内部作業について熟知している必要がある。
【０１９５】
本発明の最も重要な用途の１つは、任意のＣＧＩバイナリの制限実行をサポートし、非ＨＴＴＰ関連処理（たとえば、Ｊａｖａサーブレット）がいずれも別個のコンパートメントに区分けされ、それぞれの動作に必要な最低限の規則をそれぞれ有する安全なウェブサーバプラットフォームの提供である。これは、以下の一般的なシナリオよりも具体的な構成である。
【０１９６】
１．ＤＮＳ、Ｓｅｎｄｍａｉｌ等の様々なサービスをホストする安全なゲートウェイシステム。かかるシステムにおけるコンテインメントまたはコンパートメント化を用いて、サービス間の競合の可能性を低減し、また、サービス単位でバックエンドホストの可視性を制御することができる。
【０１９７】
２．中間アプリケーションサーバを含む積層バックエンドに対するフロントエンド（通常ＨＴＴＰ）のクラスタ化。かかるシステムにおけるコンパートメント化は、外部クライアントから直接アクセス可能なコードを可能な限り多く取り除くといった望ましい効果を有する。
【０１９８】
要約すれば、本発明の背後にある基本原理は、あらゆる外部アクセス可能コードのサイズおよび複雑性を最小まで低減することであり、これによって実際のセキュリティ侵害が発生する可能性がある範囲を制限する。可能な限り狭いインタフェースが、可能な限り具体的な規則を使用することにより、かつ／または規則の方向性を利用することにより、個々のコンパートメントにグループ化された各種機能コンポーネントの間に指定される。
【０１９９】
これより、図面の図２を参照して、選ばれた手法であるＶ１に基づいて構成されたウェブサーバプラットフォームを示す。上に述べたように、各ウェブサーバは、それぞれのコンパートメントに置かれる。ＭＣＧＡデーモンは、ＣＧＩ実行要求を取り扱い、それぞれのコンパートメントに置かれる。同様に、管理目的のコンパートメントもさらにある。ユーザレベルコマンドラインユーティリティを利用して、規則の追加／削除、およびプロセスラベルのセットによりカーネルを構成する管理ＣＧＩユーティリティも示される。これらユーティリティは、特権デバイスドライバインタフェースを介して動作する。カーネルでは、各サブシステムが、規則および初期にセットされた構成情報にのっとって動作するカスタムセキュリティモジュールへのコールアウトを含む。システムコールを行うユーザプロセスは最終的に、各サブシステムに存在するセキュリティチェックを受け、対応するデータが処理され、適宜タグ付けされる。
【０２００】
以下の説明は、本発明をどのように使用して、Ｊａｖａサーブレットの取り扱いまたはＪＳＰファイルの扱いを、各自のコンパートメント内でそれぞれ実行中の２つの別個のインスタンスＪａｋａｒｔａ／Ｔｏｍｃａｔに委譲するように構成された、外部を向いたＡｐａｃｈｅウェブサーバを含むセットアップをコンパートメント化することができるかについての説明を意図するものである。デフォルトにより、各コンパートメントは、その他のコンパートメントに干渉しないように、ｃｈｒｏｏｔ化されたファイルシステムを使用する。
【０２０１】
図面の図１０は、１つのコンパートメント（ウェブ）に常駐するＡｐａｃｈｅプロセスを模式的に示す。このコンパートメントは、以下の規則を用いて外部からアクセス可能である。
【０２０２】
HOST*−＞COMPARTMENT WEB METHOD TCP PORT 80 NETDEV eth0
規則中のＮＥＴＤＥＶコンポーネントの存在により、Ａｐａｃｈｅが使用可能なネットワークインタフェースが指定される。これは、デュアル／マルチホームゲートウェイシステム上の外部インタフェースのみを使用するようにＡｐａｃｈｅを制限する際に有用である。これは、不正侵入されたＡｐａｃｈｅのインスタンスが、内部を向いたネットワークインタフェースを通してバックエンドネットワークに対する攻撃の開始に使用されることの回避を意図する。ウェブコンパートメントでは、以下の形態をとる２つの規則を介して、Ｊａｋａｒｔａ／Ｔｏｍｃａｔの２つの別個のインスタンス（ＴＯＭＣＡＴ１およびＴＯＭＣＡＴ２）との通信が許可されている。
【０２０３】
COMPARTMENT:WEB−＞COMPARTMENT:TOMCAT1 METHOD TCP PORT 8007
COMPARTMENT:WEB−＞COMPARTMENT TOMCAT2 METHOD TCP PORT 8008
ＴＯＭＣＡＴ１中のサーブレットは、次の規則を使用して、サーバ１と呼ばれるバックエンドホストにアクセス許可されている。
【０２０４】
COMPARTMENT:TOMCAT1−＞HOST:SERVER1 METHOD TCP …
しかし、ＴＯＭＣＡＴ２は、いずれのバックエンドホストにもアクセス許可されていない。これは、任意の追加規則がないことに反映されている。カーネルは、ＴＯＭＣＡＴ２からのかかる試行をいずれも拒絶するであろう。これにより、どのサービスがホストされているかに応じてバックエンドネットワークのビューを選択的に変更し、また、バックエンドホストの可視性をコンパートメント単位で制限することが可能になる。
【０２０５】
上記４つの規則だけがこの例示的な構成に必要なものであることはまったく価値がない。任意の他の規則がない場合、ＪａｖａＶＭで実行中のサーブレットは、出力接続を開始することができず、特に、インタフェースｅｔｈ１上の内部バックエンドネットワークに対する攻撃の開始に使用することはできない。加えて、他のコンパートメント（たとえば、共有メモリセグメント、ＵＮＩＸドメインソケット等）から資源にアクセスすることができない場合があり、また、リモートホストが直接到達できない場合がある。この場合、ＡｐａｃｈｅおよびＪａｋａｒｔａ／Ｔｏｍｃａｔの振る舞いに対して、それぞれソースを再コンパイルまたは変更することなく、強制制限が課されている。
【０２０６】
これより、アプリケーション統合の例について、ＯｐｅｎＭａｉｌ６．０を参照して述べる。Ｌｉｎｕｘ版ＯｐｅｎＭａｉｌ６．０は、いくつかの未指定フォーマットの大きな１６０Ｍｂ＋アーカイブおよびインストールスクリプトｏｍｉｎｓｔａｌｌからなる。ＯｐｅｎＭａｉｌをインストールするためには、割り当てられた必要最小限度の内部コンパートメントにｃｈｒｏｏｔ化を行うことがまず必要である。
【０２０７】
root@tlinux# chroot/compt/omailin
root@tlinux# ominstall
root@tlinux# [ＯｐｅｎＭａｉｌが自然にインストールされるのを待つ]
root@tlinux# [必要であれば、さらなる構成、たとえばｍａｉｌｎｏｄｅセットアップを行う]
ＯｐｅｎＭａｉｌ６．０は、これもまたインストールする必要があるウェブベースのインタフェースであるため、別の必要最小限度のコンパートメントが割り当てられ（ｏｍａｉｌｏｕｔ）、ＡｐａｃｈｅＨＴＴＰサーバがＨＴＴＰクエリの処理のためにインストールされる。
【０２０８】
root@tlinux# chroot/compt/omailout
root@tlinux# rpm―install＜apache-RPM-filoename＞
root@tlinux# ＯｐｅｎＭａｉｌのインストール命令に必要なＣＧＩ要求を扱うようにＡｐａｃｈｅのｈｔｔｐｄ．ｃｏｎｆを構成］
この時点で、ＡｐａｃｈｅＨＴＴＰサーバがアクセスできるように、ＯｐｅｎＭａｉｌ６．０に付属のＣＧＩバイナリをインストールする必要もある。これは、２つの方法のうちの一方によって行うことができる。
【０２０９】
＊ＯｐｅｎＭａｉｌをｏｍａｉｌｏｕｔに再びインストールし、不必要な部分、たとえばサーバプロセスを除去する、または
＊ＯｐｅｎＭａｉｌ ＣＧＩバイナリをｏｍａｉｌｉｎからコピーし、許可およびディレクトリ構造体を保持するように取り計らう。
【０２１０】
いずれの場合でも、ＣＧＩバイナリは通常、Ａｐａｃｈｅウェブサーバのｃｇｉ−ｂｉｎディレクトリに置かれる。ディスクスペースが問題ではない場合には、前者の手法がより強力であり、うまくいく。後者の方法は、厳密にどのバイナリを外部に向けられたｏｍａｉｌｏｕｔコンパートメントに配置するかを確実にする必要がある場合に使用することができる。最後に、両方のコンパートメントを開始することができる。
【０２１１】
root@tlinux# comp_start omailout omailin
異なる発信元コンパートメント番号を有するＩＰフラグメントを受け取る場合もあり得る。かかる場合、システムは、フラグメントの再アセンブリが、コンパートメント番号の異なるフラグメントを続行するのを許可しない手段を備えることができる。
【０２１２】
他の様々なネットワークプロトコル、たとえばＩＰＸ／ＳＰＸ等へのサポートも含むことができる。
【０２１３】
ｃｈｒｏｏｔ−ｊａｉｌよりも包括的なファイルシステム保護方法を使用し得るものと考えられる。
【０２１４】
図面の図１３を参照して、本発明の第１の同時係属中の国際出願の発明の例示的な実施形態の動作を模式的に示す。ゲートウェイシステム６００（内部および外部ネットワークの両方に接続された）を示す。ゲートウェイシステム６００は、複数のタイプのサービス：サービス０、サービス１、・・・、サービスＮをホストしており、各サービスは指定されたあるバックエンドホスト、すなわちホスト０、ホスト１、・・・、ホストＸ、ホストＮに接続され、その機能、たとえばバックエンドデータベースからの記録検索を行う。多くのバックエンドホストが、随時内部ネットワークに存在してよい（すべてのバックエンドホストが同じサービスセットによりアクセス可能であるわけではないよう意図される）。これらサーバプロセスが不正侵入されても、不正侵入されたサーバプロセスを使用して、サービスによる使用を当初意図されていない他のバックエンドホストをプロービングすることはできないはずである。本発明の第１の同時係属中の国際出願の発明の態様は、同じネットワーク上のホストの可視性を制限することにより、攻撃者が与え得る損害を制限するよう意図される。
【０２１５】
図１３では、サービス０およびサービス１のみが、ネットワークインタフェースｅｔｈ０を通してネットワークサブネット１にアクセス許可されている。したがって、ホスト０／ホスト１がサブネット１であるため、ホスト０／ホスト１にアクセスする試みは成功するが、ｅｔｈ１を介してサブネット２にアクセスする試みは失敗する。さらに、サービスＮは、ｅｔｈ１上のホストＸのみへのアクセスが許可されている。このため、ホストＮがホストＸと同じサブネット上にあってもサービスＮによるホストＮへのアクセス試行はいずれも失敗し、また、サービスＮによるサブネット１上のあらゆるホストへのアクセス試行は失敗する。
【０２１６】
制限は、（規則またはルーティングテーブルにより）サブネットまたは特定のホストによって指定することができ、同様に、特定のサブネットによっても限定することができる。
【０２１７】
図面の図１４を参照して、本発明の第４の態様の例示的な実施形態によるオペレーティングシステムの動作を模式的に示す。本発明のこの態様の例示的な実施形態の主な好ましい特徴は、以下である。
【０２１８】
１．ｒｏｏｔへの移行が可能なエリアにおけるオペレーティングシステムのソースコードに対する変更。フックがこれらポイントに追加され、フックにより、実行時に、遷移の実行を許可あるいは拒絶する関数をコールアウトする。
【０２１９】
２．各実行中プロセスにタグをマークするという、オペレーティングシステムのソースコードに対する変更。上に述べたように、生成されるプロセスは、それぞれのタグをそれぞれの親プロセスから継承する。特別な特権プログラムが、それ自体のタグとは異なるタグを有する外部プログラムを起動することができる（異なるタグを有するプロセスでシステムを埋めるための手段）
３．構成ユーティリティが、特定のタグに関連するいずれのプロセスに「封印」とマークすべきかを実行時にオペレーティングシステムに対して指定することができるようにする機構
４．上記構成ユーティリティに渡すべきデータを記述する構成ファイル
したがって、本発明は、ファイルまたはプログラムにアクセスするときにアクセスされないパスベースの規則仕様を使用して、機能が主にカーネルレベルで提供される高信頼性オペレーティングシステム、特にＬｉｎｕｘベースの高信頼性オペレーティングシステムを提供する。これは、ディスクに格納されているプログラムまたはファイルではなく実行中のプロセスにおいてあらゆる管理特権を推論することによって実現される。かかる特権は、アクティブ化されると管理タグまたはラベルの継承により付与されるため、組み込まれたセキュリティ属性のためにストリームまたはパケットを後に復号化する必要はない。これは、ストリームまたはパケットがそれぞれのセキュリティ属性に従って異なるパスに沿って再ルーティングされないためである。
【０２２０】
Ｌｉｎｕｘの機能には、ユーザ空間における高信頼性アプリケーションを必要とすることなくアクセス可能であり、実行中プログラムのセキュリティレベルのアップグレード、ダウングレード、もしくは変更は必要ない。
【０２２１】
本発明の実施形態について例としてのみ上述したが、特許請求の範囲に規定される本発明の範囲から逸脱することなく、変更および変形を上記実施形態に行うことができることが当業者には明白であろう。
【図面の簡単な説明】
【０２２２】
【図１】コンテインメントプロパティを有するオペレーティングシステム上でマルチサービスホストとして機能するための例示的なアーキテクチャの模式図である。
【図２】本発明の例示的な実施形態による高信頼性Ｌｉｎｕｘホストオペレーティングシステムのアーキテクチャの模式図である。
【図３】図２に示すオペレーティングシステムにおいて使用される例示的な変更データ型を示す。
【図４】ＬｉｎｕｘＩＰネットワーキングにおける主なネットワーキングデータ型を示す。
【図５】ＩＰネットワーキングのｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバの伝搬を示す。
【図６】コンテインメントをＬｉｎｕｘカーネルに構築する例示的な３つの手法を模式的に示す。
【図７】規則：ＨＯＳＴ＊−＞ＣＯＭＰＡＲＴＭＥＮＴｘＭＥＴＨＯＤ ＴＣＰ ＰＯＲＴ８０の影響を模式的に示す。
【図８】ハイブリッドコンテインメントプロトタイプオペレーティングシステムの構築に利用可能な多様なオプションを模式的に示す。
【図９】複製したカーネル状態を同期して更新することの望ましさを模式的に示す。
【図１０】Ａｐａｃｈｅおよび２つのＴｏｍｃａｔ Ｊａｖａ Ｖｍの例示的な構成を模式的に示す。
【図１１】図２に示す高信頼性Ｌｉｎｕｘにおけるｃｈｒｏｏｔ化された層状の環境を模式的に示す。
【図１２】カーネル強制コンパートメントアクセス制御規則の効率的な参照プロセスを模式的に示す。
【図１３】本発明の一態様による高信頼性ゲートウェイシステムの例示的な実施形態を模式的に示す。
【図１４】本発明の一態様の例示的な実施形態によるオペレーティングシステムの動作を模式的に示す。
【図１５】従来技術によるオペレーティングシステムの例示的な実施形態を模式的に示す。
【０００１】
本発明は、高信頼性オペレーティングシステムに関し、特に、アプリケーションの不正侵入および不正侵入されたアプリケーションの不正利用攻撃に対して高い保護性を有するオペレーティングシステムに関する。
【０００２】
近年、インターネットを介して電子的に提供されるサービスの数はますます増大している。かかるサービス、特に、成功している、ひいては収益性の高いサービスは潜在的な攻撃者の標的となり、電子サービスを提供するアプリケーションが不正侵入され、その結果として多数のインターネットセキュリティ侵害が発生していることがわかっている。
【背景技術】
【０００３】
電子サービスを提供するアプリケーションは、一般に複雑であり、１つまたは複数のバグを内包することの多い多数のコードラインを含むことから、攻撃をより受けやすくなっている。電子サービスは、インターネット上で提供される場合には、サービスの脆弱性を探ることができる多数の潜在的な攻撃者に曝されており、かかるバグによりセキュリティの侵害があったことがわかっている。
【０００４】
アプリケーションが一度不正侵入される（たとえば、バッファオーバーフロー攻撃により）と、攻撃者はそのアプリケーションを異なるいくつかの方法で不正利用攻撃して、システムのセキュリティを侵害し得る。
【０００５】
単一のマシンを使用してマルチサービス（たとえば、ＩＳＰ、ＡＳＰ、ｘＳＰサービス提供）を同時にホストする場合がますます多くなっているため、アプリケーション不正侵入攻撃から保護されたホストプラットフォームのセキュリティのみならず、攻撃を受けた場合に、攻撃を受けたアプリケーションから他のアプリケーションを適宜保護することもますます重要になってきている。
【０００６】
オペレーティングシステムレベルにてアプリケーションの不正侵入から保護する最も有効な方法の１つは、カーネル実施制御であり、これは、カーネルで実施される制御には、いずれのアプリケーションまたはユーザによってもユーザ空間から乗っ取りまたは破壊を行うことができないためである。既知の諸システムでは、当該制御は、個々のアプリケーションコードの品質に関わりなくすべてのアプリケーションに適用される。
【０００７】
アプリケーションの不正侵入およびその影響から適宜保護するためには、システムレベルにおいて２つの基本的な要件がある。第１に、アプリケーションは、可能な限り最大の程度まで攻撃から保護されなければならず、公開されるアプリケーションへのインタフェースは可能な限り狭くなければならず、またかかるインタフェースへのアクセスは十分に制御されなければならない。第２に、不正侵入されたアプリケーションがシステムに与え得る損害の大きさは、可能な限り最大まで制限されなければならない。
【０００８】
既知のシステムでは、上記２つの要件は「コンテインメント（containment、封じ込め）」という抽象的プロパティによって満たされる。アプリケーションは、不正侵入されていた場合であっても、アクセス可能な資源および可能なアクセス種別が厳密に制御されている場合には封じ込められる。コンテインメントは、外部からの攻撃および干渉からもアプリケーションを保護する。このため、コンテインメントプロパティは、攻撃者の潜在的な不正利用攻撃行動の多くを少なくとも軽減する潜在性を有する。
【０００９】
アプリケーションの不正侵入に続く最も一般的な攻撃は、以下の４つのタイプの１つに概ね分類することができる（しかし、特定の攻撃の結果はこれらのうちのいずれかまたはすべての組み合わせであり得る）。
【００１０】
１．保護システム資源への直接アクセス権限を得る特権の悪用
アプリケーションが特別な特権で実行されている（たとえば、アプリケーションが標準Ｕｎｉｘオペレーティングシステム上でｒｏｏｔとして実行されている）場合、攻撃者はその特権を、意図された方法以外の方法で使用しようと企てることがある。たとえば、攻撃者はその特権を用いて、保護動作資源へのアクセスを得たり、または同じマシンで実行されている他のアプリケーションに干渉することができる。
【００１１】
２．アプリケーション実施アクセス制御の破壊
このタイプの攻撃は、正当な資源（すなわち、アプリケーションによって公開されるものと意図される資源）へのアクセスを不正に得る。たとえば、コンテンツを提供する前にコンテンツにアクセス制御を実施するウェブサーバは、このタイプの攻撃を受けやすいアプリケーションの１つである。ウェブサーバのコンテンツへのアクセスは非制御直接アクセスであるため、ウェブサーバの制御権を得る攻撃者にとっても同様である。
【００１２】
３．誤ったセキュリティ意思決定情報の付与(supply)
通常、このタイプの攻撃は間接的な攻撃であり、不正侵入されたアプリケーションは通常、メインサービスとは対照的なサポートサービス（認証サービス等）である。この場合、不正侵入したセキュリティサービスを使用して、誤っているか、または偽作の情報を与え、それによって攻撃者がメインサービスへのアクセスを得ることが可能になる。したがって、これは、攻撃者がアプリケーションにより正当に公開されている資源に不正アクセスすることができるもう一つの方法である。
【００１３】
非保護システム資源の不正使用
攻撃者が、保護されていないが、通常はアプリケーションによって公開されない、マシンのローカル資源にアクセスする。通常、次にかかるローカル資源を使用して、さらなる攻撃を開始する。たとえば、攻撃者はホストシステムへのシェルアクセスを取得することができ、次いでそこから、マシン上またはネットワークにわたる他のアプリケーションに対して段階的な攻撃を開始することができる。
【００１４】
コンテインメントを使用する場合、保護システム資源への直接アクセスを得る特権の悪用の影響は、コンテインメントを使用しない場合よりもはるかに少ない。これは、攻撃者がアプリケーション特権を利用する場合であっても、アクセスされる恐れのある資源は、アプリケーションのコンテナ内で利用可能になっていたものに制限することができるためである。同様に、非保護資源の場合でも、コンテインメントを使用すると、アプリケーションからネットワークへのアクセスを阻止、または少なくとも非常に密に制御することができる。誤ったセキュリティ意思決定情報の付与に関しては、コンテインメントでは、サポートサービスへのアクセスを確実に正当なクライアント、すなわちアプリケーションサービスのみからにし、それによって、アプリケーションが攻撃に曝されることを制限することにより、引き起こされる潜在的な損害が少なくなる。
【００１５】
第２のタイプの攻撃、すなわちアプリケーション実施アクセス制御の破壊の軽減または防止は通常、アプリケーションの設計において、または少なくとも構成レベルにおいてなされる。しかし、コンテインメントを使用すれば、信頼性の低い大きなアプリケーション（ウェブサーバ等）から保護資源へのアクセスが、より小さくより信頼性の高いアプリケーションを経由しなければならないように構成することが可能である。
【００１６】
このため、コンテインメントをオペレーティングシステムに使用すると、アプリケーションのセキュリティが効果的に向上し、アプリケーションが不正侵入された場合に攻撃者によって引き起こされる恐れのあるあらゆる損害が制限される。図面の図１を参照して、コンテインメントプロパティを有するオペレーティングシステム上でマルチサービスホストとして機能するための例示的なアーキテクチャを示す。図示の例では、コンテインメントは、アプリケーションが相互に、またクリティカルなシステム資源から分離された状態に保たれるよう保証するために使用されている。アプリケーションは、別のアプリケーションの処理に干渉すること、またはその（おそらく機密の）データにアクセスすることができない。コンテインメントが使用されると、特定のアプリケーションが機能させる必要があるインタフェース（入力および出力）のみがオペレーティングシステムによって公開されるよう保証されるため、特定のアプリケーションに対する攻撃の範囲が制限されるとともに、アプリケーションが不正侵入されたときに生じ得る損害量が制限される。したがって、コンテインメントはホストプラットフォーム全体の保全性の維持に役立つ。
【００１７】
オペレーティングシステム内のカーネル実施コンテインメント機構は、数年前から、通常、機密（軍事）情報を受け渡し・処理するために設計されたオペレーティングシステムに利用可能であった。多くは、かかるオペレーティングシステムは「高信頼性オペレーティングシステム」と呼ばれる。
【００１８】
コンテインメントプロパティは通常、強制アクセス制御（ＭＡＣ）と特権との組み合わせを通して実現される。ＭＡＣ保護方式は、特定のアクセス制御ポリシーをファイル、プロセス、およびネットワーク接続等のシステム資源に対して実施する。このポリシーはカーネルによって実施され、ユーザまたは不正侵入されたアプリケーションによって乗っ取ることができない。
【００１９】
高信頼性オペレーティングシステムは、魅力的なコンテインメントプロパティを提供するにも関わらず、主に２つの理由により、機密情報処理システム以外ではあまり広く使用されていない。第１に、従来では、高信頼性オペレーティングシステム機構を従来のオペレーティングシステムに追加しようとすると、標準アプリケーションまたは管理ツールがサポートされなくなり、標準の方法で使用または管理することができなくなり得るという意味において、通常、土台をなすオペレーティングシステムの個性が失われることになる。このため、高信頼性オペレーティングシステムはそれぞれの標準対応品よりもはるかに複雑である。第２に、従来の高信頼性オペレーティングシステムは、通常、分離により近い、すなわち強すぎるコンテインメントの形態で動作させるため、大がかりで高価なことが多い統合努力を伴うことなく、（既存の）アプリケーションを有用かつ効果的にセキュア化する機能に関して範囲が限られていることがわかっていた。
【発明の開示】
【発明が解決しようとする課題】
【００２０】
上記問題の克服を目的とした装置が考案され、この装置は、アプリケーションを変更することなく多数の既存のアプリケーションを効果的にセキュア化するために有効に使用することができるコンテインメントプロパティを有する高信頼性オペレーティングシステムを提供する。
【課題を解決するための手段】
【００２１】
本発明の第１の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、上記アプリケーションの少なくともいくつかにはラベルまたはタグが提供され、ラベルまたはタグはそれぞれ上記システムの論理的に保護されたコンピュータ処理環境すなわち「コンパートメント」を示し、同じラベルまたはタグを有するアプリケーションはそれぞれ同じコンパートメントに属するオペレーティングシステムが提供され、オペレーティングシステムは、上記コンパートメント間に１つまたは複数の通信経路を定義する手段と通信経路が間に定義されないコンパートメント間の通信を阻止する手段とをさらに備える。
【００２２】
本発明の第２の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、複数のアクセス制御規則をさらに備えるオペレーティングシステムが提供される。複数のアクセス制御規則は、ユーザ空間から都合良く追加することができ、オペレーティングシステムのカーネルに設けられる手段によって実施され、選択されたアプリケーション（上記オペレーティングシステムに対してローカルであるかリモートであるかに関わりなく）間の通信インタフェースのみを定義する。
【００２３】
これは、本発明の第１および第２の態様において、コンテインメントプロパティが、プロセス、ファイル、およびネットワーク資源の強制保護によって提供され、主要な概念は、システムの半ば隔離された部分であるコンパートメントに基づく。システム上のサービスおよびアプリケーションは、別個のコンパートメント内で実行される。都合のよいことに、各コンパートメント内はホストファイルシステムの限られた部分集合であり、各コンパートメントを対象とする通信インタフェースは、明確に定義され、狭く、密に制御される。各コンパートメント内のアプリケーションのみがそのコンパートメント内の資源、すなわちそのコンパートメント内の限られたファイルシステムおよび他のアプリケーションに直接アクセスする。他の資源へのアクセスは、ローカルであれリモートであれ、十分に制御された通信インタフェースを介してのみ提供される。
【００２４】
単純な強制アクセス制御、およびアプリケーションもしくはプロセスのラベリングを都合良く使用して、コンパートメントの概念を実現する。好ましい実施形態では、各プロセス（またはスレッド）にラベルが与えられ、同じラベルを有するプロセスは同じコンパートメントに属する。システムは、好ましくは、強制セキュリティチェックを行って、あるコンパートメントからのプロセスが別のコンパートメントからのプロセスに干渉することができないよう保証する手段をさらに備える。ラベルは整合するかしないかのいずれかであるため、アクセス制御は非常に簡単に行うことができる。
【００２５】
本発明の好ましい実施形態では、ファイルシステム保護もまた強制である。従来の高信頼性オペレーティングシステムとは異なり、本発明の第１の態様の好ましい実施形態は、ファイルシステムへのアクセスの直接制御にラベルを使用しない。代わりに、本発明の第１および第２の態様のファイルシステムは、好ましくは、少なくとも部分的にセクションに分割される。各セクションは、メインファイルシステムの重ならない、限られた部分集合（すなわち、ｃｈｒｏｏｔ）であり、各コンパートメントに関連する。各コンパートメントで実行されているアプリケーションのみが、ファイルシステムの関連セクションにアクセスする。本発明の第１および／または第２の態様のオペレーティングシステムには、好ましくは、ｃｈｒｏｏｔをエスケープすることができないように、本発明の第４の態様を参照して以下に述べるように、プロセスがコンパートメント内からｒｏｏｔに移行することを阻止する手段が設けられる。本システムは、ｃｈｒｏｏｔ内の選択ファイルを変更不可にする手段も含むことができる。
【００２６】
コンパートメント間、およびネットワーク資源間の柔軟であるが制御される通信経路は、狭く密に制御される通信インタフェースを通して提供され、通信インタフェースは、セキュリティ管理者等により好ましくはコンパートメント単位でユーザ空間から定義・追加が可能な１つまたは複数の規則によって統制される。かかる通信規則により、コンパートメントおよび／またはネットワーク資源の間の通信を許可する高信頼性プロキシの必要性がなくなる。
【００２７】
本発明の第１および／または第２の態様によって提供されるコンテインメントプロパティは、カーネルレベルの実施手段、ユーザレベルの実施手段、またはこれら２つの組み合わせによって実現することができる。本発明の第１および／または第２の態様の好ましい実施形態では、あるコンパートメントと他のコンパートメントまたはホストとの間のアクセス許可を指定するために使用される規則は、オペレーティングシステムのカーネル内の手段によって実施されるため、ユーザ空間介入の必要性（既存のプロキシソリューションに必要なもの等）がなくなる。カーネル実施コンパートメントアクセス制御規則により、アプリケーションを変更する必要なく、本発明の第１の態様のコンパートメント化されたオペレーティングシステムにおけるコンパートメント間の制御された柔軟な通信経路が可能になる。
【００２８】
規則の有益な形は以下である。
【００２９】
source−＞destination method m[attr][netdev n]
ただし、ｓｏｕｒｃｅ／ｄｅｓｔｉｎａｔｉｏｎは、以下のうちの１つである。
【００３０】
ＣＯＭＰＡＲＴＭＥＮＴ（名前の付いたコンパートメント）
ＨＯＳＴ（おそらく固定Ｉｐｖ４アドレス）
ＮＥＴＷＯＲＫ（おそらくＩｐｖ４サブネット）
ｍ：サポートされるカーネル機構、たとえば、ｔｃｐ（伝送制御プロトコル）、ｕｄｐ（ユーザデータグラムプロトコル）、ｍｓｇ（メッセージキュー）、ｓｈｍ（共有メモリ）等
ａｔｔｒ：メソッドｍをさらに修飾するプロパティ
ｎ：妥当な場合には、名前の付いたネットワークインタフェース、たとえばｅｔｈ０
規則の指定にワイルドカードを使用することも可能である。以下の規則例は、ＴＣＰを使用してポート８０のみですべてのホストがウェブサーバコンパートメントへアクセスすることを許可する。
【００３１】
HOST*−＞COMPARTMENT web METHOD tcp PORT80
以下の規則例はかなり似ているが、ウェブサーバコンパートメントへのアクセスを、システムの例示的な実施形態においてｅｔｈ０ネットワークインタフェースへのルートを有するホストに制限する。
【００３２】
HOST*−＞COMPARTMENT web METHOD tcp PORT80 NETDEV eth0
有益には、許可を受けたシステム管理者によって、オペレーティングシステムに規定されたアクセス制御規則の追加、削除、および／またはリスト化を行う手段が設けられることが好ましい。選択されたコンパートメント間および／または資源間で双方向通信を行うことができるようにするために、リバースＴＣＰ規則を追加する手段を設けてもよい。
【００３３】
規則は、有益なことに、カーネルレベルのデータベースに格納され、好ましくは、ユーザ空間から追加される。カーネルレベルのデータベースは、有益なことに、２つのハッシュテーブルで構成され、テーブルの一方は規則の発信元アドレス詳細に焦点をあて、他方は規則の宛先アドレス詳細に焦点をあてる。システムは、システムコール／ＩＳＲ（割り込みサービスルーチン）の処理を許可する前に、データベースをチェックして規則が適切な通信経路を定義しているか否かを判定するように構成される。カーネルレベルデータベースの好ましい構造により、セキュリティチェックを行う時に、システムは、要求される規則が発信元アドレス詳細または宛先アドレス詳細に整合すべきかどうかを知っており、よって適切なハッシュテーブルを選択することができ、規則参照のＯ（１）レートを可能にするため、カーネル実施コンパートメントアクセス制御規則を効率的に参照することができる。要求される通信経路を定義する必要な規則が見つからない場合には、システムコールは失敗することになる。
【００３４】
したがって、本発明の第３の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、上記アプリケーション間の許可された通信経路（すなわち、発信元および宛先）を定義する複数の規則が格納されたデータベースを備えるオペレーティングシステムが提供される。上記規則は、少なくとも２つの符号化テーブル、すなわち規則の発信元詳細に焦点をあてた第１のテーブルおよび規則の宛先詳細に焦点をあてた第２のテーブルの形態で格納される。本システムは、システムコールに応答して、要求される通信経路を定義する規則の存在について上記テーブルの少なくとも一方をチェックし、上記要求された通信経路が定義されている場合にのみ、上記システムコールの続行を許可する手段をさらに備える。
【００３５】
上記符号化テーブルは、好ましくは、少なくとも１つのハッシュテーブルを含む。
【００３６】
多くの場合、ゲートウェイタイプのシステム（すなわち、内部および外部両方のネットワークに接続されたデュアルインタフェースを備えたホスト）では、以下のことが望ましい：ａ）利用可能なネットワークインタフェースの部分集合のみを使用するように実行中のサーバプロセスを制限すること、ｂ）アクセス可能なリモートホストおよびアクセス不可能なリモートホストを明示的に指定すること、およびｃ）かかる制限をプロセス／サービス単位で同じゲートウェイシステムに適用させること。
【００３７】
ゲートウェイシステムは、いくつかの内部サブネットワークに物理的に接続されることがあるため、サーバプロセスがリモートソースから不正侵入された場合に、別のネットワークインタフェースを介して、潜在的に脆弱性を有するバックエンドホストへのその後の攻撃開始に使用することができないように、システム管理者が、どのサーバプロセスがどのネットワークインタフェースにアクセス許可され得るかを分類することが重要である。
【００３８】
従来では、ＩＰアドレス単位および／またはＩＰポートレベル単位でホスト間のアクセスを制限するようにファイアウォールが使用されてきた。しかし、かかるファイアウォールは、主に、異なるサーバプロセスを区別することができないという理由により、複数のサービスをホストするゲートウェイシステムに十分なきめ細かさを提供しない。加えて、異なる制限セットを指定するには、別個のファイアウォール規則のセットを有する別個のゲートウェイシステムが求められる。
【００３９】
本発明者らによる第１の同時係属中の国際出願には、上記問題の克服を目的とし、内部および外部ネットワークの両方に接続されたデュアルインタフェースを備え、プロセスおよび／またはスレッドを実行している複数のサービスをホストするゲートウェイシステムを提供する装置が定義される。このシステムは、コンパートメントを示すタグまたはスレッドを上記実行中のプロセスおよび／またはスレッドの少なくともいくつかに提供する手段を備え、同じタグまたはラベルを有するプロセス／スレッドは同じコンパートメントに属する。このシステムは、上記コンパートメントとローカルおよび／またはリモートホストもしくはネットワークとの間に特定の通信経路および／または許可されたインタフェース接続を定義する手段と、通信経路またはインタフェース接続が間に定義されている場合にのみ、コンパートメントとホストまたはネットワークとの間の通信を許可する手段とをさらに備える。
【００４０】
かくして、本発明者らによる第１の同時係属中の国際出願の発明では、アクセス制御チェックが、好ましくはゲートウェイシステムのカーネル／オペレーティングシステムに対して行われる。かかるアクセス制御チェックでは、好ましくは、どのプロセスクラスがどのサブネット／ホストにアクセス許可されているかを指定する規則テーブルを照会する。制限は、サービス（またはプロセス／スレッド）レベル単位で指定することができる。これは、バックエンドネットワークのビューが単一のゲートウェイホスト上で可変であることを意味する。したがって、たとえば、ゲートウェイが、２つの異なるバックエンドホストへのアクセスをそれぞれ要求する２種類のサービスをホストする場合、従来技術によるファイアウォールは、ゲートウェイホストがこれらバックエンドホストの両方にアクセス可能なことを指定する必要があるが、本発明者らによる第１の同時係属中の国際出願の発明では、許可された通信経路をより細かいレベルで、すなわちどのサービスがどのホストにアクセス許可されているかを指定することが可能である。これにより、サービスが当初アクセスすることが意図されていなかったホストにアクセスする危険性が大幅に低下するため、セキュリティはいくらか向上する。
【００４１】
本発明の好ましい実施形態では、アクセス制御チェックはゲートウェイシステムのカーネル／オペレーティングシステムにおいて実施されるため、ユーザ空間プロセスがこれを迂回することはできない。
【００４２】
かくして、本発明者らによる第１の同時係属中の国際出願の発明の第１の例示的な実施形態では、ゲートウェイシステムのカーネルに、プロセスがどのコンパートメントに属するかを概念的に示すタグまたはラベルを実行中の各プロセス／スレッドに添付する手段が設けられる。かかるタグは、子にフォークする親プロセスから受け継ぐことができる。したがって、スレーブウェブサーバプロセス群等、協働して作業負荷を分担する、フォークした子の群を含むサービスは、同じタグを保有し、同じ「コンパートメント」に配置される。システム管理者は、たとえば、以下の形態で規則を指定することができる。
【００４３】
Compartment X−＞Host Y[using Network Interface Z]または
Compartment X−＞Subnet Y[using Network Interface Z]
これらは、名前の付いたコンパートメントＸ中のプロセスによる、ホストあるいはサブネットＹへのアクセスを許可し、オプションとして、Ｚと名の付いたネットワークインタフェースのみを使用する場合に制限される。好ましい実施形態では、かかる規則は、ゲートウェイシステム上の安全な構成ファイルに格納され、システムスタートアップ時に、次いて開始されるサービスが実行することができるように、カーネル／オペレーティングシステムにロードされる。サービスが開始されると、それぞれのスタートアップシーケンスが、最初にどのコンパートメントに配置されるかを指定する。この実施形態では、好ましくはカーネルのプロトコルスタックにおいてセキュリティチェックをさらに行うことにより、パケットをコンパートメントＸから送信またはコンパートメントＸに引き渡す都度、規則を照会する。
【００４４】
本発明者らによる第１の同時係属中の国際出願の発明の第２の例示的な実施形態では、別個のルーティングテーブルがコンパートメント毎に提供される。上に述べた第１の実施形態と同様に、各プロセスは、親から受け継いだタグまたはラベルを保有する。特定の名前の付いたプロセスは、システム管理者によって構成された指定タグで始まる。規則を指定する代わりに、第１の例示的な実施形態を参照して上述したように、所望のルーチンテーブルエントリを挿入することにより、各コンパートメントのルーティングテーブルを構成する構成ファイルのセットが提供される（各コンパートメントに１つ）。ゲートウェイシステムはいくつかの名前の付いていないコンパートメントを含むことができるため、各コンパートメントのルーティングテーブルはデフォルトでは空である（すなわち、エントリがない）ことが好ましい。
【００４５】
整合するルートがないことは、到達を試みられているリモートホストが到達不可能であると報告されることを意味すると解釈されるため、明示的な規則の代わりにルーティングテーブルを使用することができる。整合するルートは、そのリモートホストにアクセスしようという試みが許可されることを意味する。上に述べた第１の例示的な実施形態における規則と同様に、ルーティングエントリは、ホスト単位（ＩＰアドレス）またはサブネット単位で指定することができる。第１の例示的な実施形態と同じ機能を実現するために必要なのは、かかるルーティングエントリをコンパートメント単位で指定することだけである。
【００４６】
上に述べたように、実行中のサーバプロセス／デーモンへの攻撃（たとえば、バッファオーバーフロー、スタック破壊）は、遠隔地にいる攻撃者が、サーバプロセスをホストしているシステムでｒｏｏｔ／管理者に相当するアクセスを不法に得る状況に繋がる恐れがある。かかるシステムで管理者アクセスを得ると、攻撃者は、不正侵入されたシステムに存在することがある機密の構成／パスワードファイル、非公開データベース、秘密鍵等の読み出しなど、他のセキュリティ侵害を自由に開始することができる。
【００４７】
かかる攻撃は、以下の場合に可能であり得る。
【００４８】
ａ）サーバプロセスが管理者として実行され、ソフトウェアバグにより実行時に内部に侵入される。
【００４９】
ｂ）サーバプロセスが、最初は管理者として開始されるが、ある特権動作を行うのに先立って管理者特権を再び取得する選択的機能を備えて、その動作時間の大半は管理者特権を落とすようにプログラムされた。かかる場合、サーバプロセスは（ある特定の目的のために）ｒｏｏｔに移行して戻る機能を保持するが、攻撃者は、プロセスの制御権をいったん取得すると、意図された当初の目的以外でｒｏｏｔへの移行を行うことができる。
【００５０】
ｃ）サーバプロセスが、最初は非特権ユーザとして開始されるが、まずオリジナルのサーバプロセスを破壊し、次いでそれを、上述した方法で脆弱性を有する可能性がある外部ｓｅｔｕｉｄ−ｒｏｏｔプログラムを破壊する手段として使用することによって管理者アクセスを得る。
【００５１】
従来技術によれば、こういった問題に対する１つの直接的な方策は、最初に攻撃の発生を許した特定のバッファオーバーフローバグを塞ぐ／修復することである。この方策の明らかな欠点はもちろん、純粋に受動的であり、バッファオーバーフローバグが今後さらに見つかり、不正利用攻撃される事態が防止されないことである。従来技術により提案された別の方策は、オペレーティングシステム、たとえばＵｎｉｘに存在する機能について、決して戻さないという意図をもって、ｒｏｏｔに相当するアクセスをすべて落とすというものである。これにより、実行中のプロセスが予期せずにｒｏｏｔに復帰する事態が回避されるが、プログラムが、たとえば、不注意に周辺に転がっており、ある不正入力が与えられると破られやすい外部ｓｅｔｕｉｄ−ｒｏｏｔプログラムを動作させるという事態を回避しない。これが万が一行われた場合、不正侵入された、非特権ユーザとして実行中のプロセスは、ｓｅｔｕｉｄ−ｒｏｏｔプログラムを実行し、攻撃者の制御下にさせる入力を与えるという事態を防止しない。
【００５２】
ここで、上記問題を克服することを目的とした装置を考案した。かくして、本発明の第４の態様によれば、複数のアプリケーションをサポートするオペレーティングシステムであって、要求に応答して、アプリケーションがｒｏｏｔに移行することが許可されているか否かを示すタグまたはラベルを上記アプリケーションの少なくともいくつかに提供する手段と、かかる要求を識別し、そのタグまたはラベルから、アプリケーションのｒｏｏｔへの移行が許可されているか否かを判定し、判定に応じて上記移行を許可または拒絶する手段とを備えるオペレーティングシステムが提供される。
【００５３】
好ましい実施形態では、上記タグまたはラベルの少なくとも１つは、そのタグまたはラベルが添付されている、または関連付けられたアプリケーションが「封印」されたもの、ひいては変更不可であることを示す。
【００５４】
かくして、本発明の第４の態様は、選択されたサーバプロセスを、管理者相当状態への状態移行に関して「封印」することにより、かかるサーバプロセスの管理者相当状態への移行を止める方法を導入する。こういったプロセスがかかる移行を行おうとすると常に、かかる目的専用のシステムルーチンを呼び出すか、「ｓｅｔｕｉｄ−ｒｏｏｔ」とマークされた外部プログラム（すなわち、呼び出した人が誰であれ、管理者として実行する機能を有するものとして、システム管理者により予めタグを付けられているプログラム）を実行するか、あるいはあらゆる他の手段により、オペレーティングシステムは、このようにマークされたプログラムを実行するシステムコールまたは試行を許可しない。
【００５５】
本発明の第４の態様によるオペレーティングシステムによってもたらされる利点としては、ｒｏｏｔに相当するアクセスに対する制限が無条件であり、実行されるサーバプロセスに、不正利用攻撃されるまだ発見されていないソフトウェアバグがいくつあるかに関わりなく、効力を失わない状態を保つことが挙げられる。不正利用攻撃される恐れのある新しいバグが発見された場合、制限は、新しいバグの性質に関わりなく、それまで他のバグの場合と同じように課された状態のままである。明らかに、これは、バグが発見されたときにそのバグを修復する必要がある場合には起こりえない。さらに、本発明の第４の態様の装置は、攻撃者が、オリジナルプロセスの代わりにｒｏｏｔとして実行する機能を有する外部プログラムの破壊を企てる外部ｓｅｔｕｉｄ−ｒｏｏｔ問題を解消している。本発明の第４の態様の装置では、オペレーティングシステムにおいてかかるあらゆる企てが追跡され、装置は、マークされたプロセスを用いてかかるｓｅｔｕｉｄ−ｒｏｏｔプログラムを実行する試みを拒絶するように構成することができる。加えて、保護プロセスの元のソースコードを変更する必要はなく、ｒｏｏｔに戻らないことを保証して、任意のバイナリを実行することができる。
【００５６】
高信頼性オペレーティングシステムは通常、入力ネットワークパケットに割り当てる必要のある機密ラベルの決定に役立つように、個々のネットワークアダプタのラベル付けを行う。ファイアウォール等他のソフトウェアシステムが、どのインタフェースを潜在的な「敵」または非敵とマークすべきかを決定するために、インタフェースラベル付け（またはカラーリングと呼ばれることもある）を実行することがある。これは、内部では高信頼性／安全であり、外部インターネットリンクに関しては低信頼性／非安全な企業ネットワークのビューに対応する（図面の図１５を参照）。
【００５７】
コンピュータシステムの動作中静的なままであるネットワークアダプタ（ＮＩＣ）の場合、ラベル付けはシステムスタートアップ中に行うことができる。しかし、ＰＰＰリンクまたはあらゆる他のネットワークデバイス抽象化（たとえば、ＶＬＡＮ、ＶＰＮ）を処理する「ソフト」アダプタ等、システム上で動的にアクティブ化することのできる類のＮＩＣがある。かかる動的アダプタの例としては、以下が挙げられる。
【００５８】
＊ＰＰＰリンク、たとえばＩＳＰへのモデム接続。通常、ＩＳＰへのＰＰＰ接続を表すソフトアダプタが作成される。
【００５９】
＊仮想ＬＡＮ（ＶＬＡＮ）−サーバは、ＶＬＡＮを使用して、私設仮想回線で動作するソフトウェアサービスをホストすることができる。かかるＶＬＡＮは動的に（たとえば、要求があり次第）セットアップすることができるため、高信頼性オペレーティングシステムまたはそれに由来するものを使用する場合、かかるサービスをホストするサーバがこういったインタフェースを正しくラベル付けることができるはずである。
【００６０】
図面の図１５に示す構成が概ね静的な性質であることは、新しいアダプタを処理する必要が殆どないことを意味する。システム管理者は、新しいアダプタをデュアルホームホスト７００に追加したい場合には、通常システムを停止し、アダプタを物理的に追加して、新しいアダプタを適宜認識するようにシステムを構成する。しかし、このプロセスは、インタフェースラベル付けを要求するシステムが上に述べた種類の動的インタフェースを有する場合には適さない。
【００６１】
ラベルがアダプタに付けられない場合、アダプタ上の入力パケットに正しいラベルが割り当てられず、問題となっているシステムのセキュリティに違反することがある。さらに、出力パケット（おそらく、ラベルが正しく割り当てられている）は、パケットを送信すべきアダプタと正しく整合しえないため、問題となっているシステムのセキュリティに違反する。
【００６２】
本発明者らによる第２の同時係属中の国際出願では、上記問題の克服を目的とし、新たにインストールされたアダプタを実質的にアクティブ化するときに、上記アダプタの属性に依存するラベルをそのアダプタに動的に割り当てる手段と、上記アダプタが非アクティブ化されるときに上記ラベルを除去する手段とを備えるオペレーティングシステムを提供する装置が定義される。
【００６３】
かくして、オペレーティングシステムに新たにインストールされたアダプタが初めてアクティブ化されると、入力パケットの受け取りに先立ってラベルが確実に割り当てられ、それによってラベルの付いていないパケットが作成されないこと、またネットワークプロトコルスタックに渡されないことが保証される。動的アダプタは、第２の同時係属中の国際出願の発明のオペレーティングシステムにおいて作成されるため、かかるラベルシステムの新しい機能分野が、たとえば、ルータ、モバイル機器として開かれる。さらに、アダプタに割り当てられるラベルは、新たにアクティブ化されたアダプタの実行時プロパティの関数であり得る。たとえば、各種ＩＳＰへの様々なＰＰＰ接続を区別することが望ましい場合がある。これは、ラベルをアダプタ名に割り当てる（たとえば、アダプタ「ｐｐｐ０」にラベルＬ０を割り当てる）ことによって行うことはできない。これは、アダプタ名が動的に作成され、アダプタの実際のプロパティが可変であるためである。アダプタに適切なラベルを選ぶことにより、あらゆるセキュリティチェックがラベル関数に適切に基づくことを保証することができる。これは、アダプタに付けられるラベルは、システムにすでに存在するその他のラベルに関して正しくなければならないという意味において、プロセス、ネットワーク接続、ファイル、パイプ等他のシステムオブジェクトにもラベルを付ける高信頼性オペレーティングシステム（特に、本発明の第１および第２の態様を参照して定義したもの）に関して特に重要である。
【００６４】
カーネル／オペレーティングシステムは通常、新しいアダプタがアクティブ化されるときに呼び出されるソフトウェアルーチンを有する。第２の同時係属中の国際出願の発明の例示的な実施形態では、かかるルーチンは、たとえば、規則セットまたは構成テーブルを照会することにより、新たに形成されたアダプタの属性に応じてラベルを割り当てるようにも変更される。同様に、アダプタが非アクティブ化されるときに呼び出されるルーチンもあり、これはそれまで割り当てられていたラベルを除去するように変更される。
【００６５】
本発明の第１および第２の態様を再び参照して、属するコンパートメントを示すタグで各プロセスおよびネットワークインタフェースを増補するオペレーティングシステムが定義される。例示的な実施形態では、カーネルに設けられる手段が、（任意の標準Ｕｎｉｘプロセス間通信機構を使用することで、Ｌｉｎｕｘオペレーティングシステムにおいて）あるプロセスが別のプロセスと通信したいときは常に規則ベースを照会する。整合する規則が規則ベースにある場合にのみ、通信が成功する。好ましい実施形態では、規則ベースはカーネルに存在するが、上述のように、より実際的には、管理プログラムにより好ましくはユーザ空間において初期化され、動的に維持され、照会されることが望ましい。
【００６６】
したがって、本発明の第５の態様によれば、システムオブジェクト間の許可された通信経路を定義する１つまたは複数の規則からなる規則ベースを格納する手段を含むカーネルと、かかる規則の追加、削除、および／またはリスト化を行うユーザ操作可能手段とを備えるオペレーティングシステムが提供される。
【００６７】
したがって、本発明の第５の態様のオペレーティングシステムでは、ＴＣＰおよびＵＤＰパケットを介してのアクセス制御のみならず、オペレーティングシステムに存在する他の形態のプロセス（Ｌｉｎｕｘシステムでは、生ＩＰパケット、ＳｙｓＶメッセージ、ＳｙｓＶ共有メモリ、およびＳｙｓＶセマフォが挙げられる）間通信のアクセス制御も実行することが可能である。
【００６８】
本発明の第５の態様の例示的な一実施形態では、ユーザ空間プログラムが、規則ベース中のエントリを変更およびリスト化するために、カーネルを対象にしたデータを送受信可能である必要がある。好ましい実施形態では、これは、２つのエントリポイントを提供するカーネルデバイスドライバをオペレーティングシステムに包含することによって実施される。第１のエントリポイントは、「ｉｏｃｔｌ」システムコールのためのものである（ｉｏｃｔｌは従来、小量のデータまたはコマンドをデバイスに送信するために使用される）。第１のエントリポイントは、３つの演算に使用するよう構成される。第１に、完成した規則を指定し、規則ベースに追加するために使用することができる。第２に、同じデータを使用してその規則を削除することができる。第３に、最適化として、その「参照」により規則を削除することができ、本発明の例示的な一実施形態では、参照は、カーネルによって維持される６４ビットタグである。
【００６９】
第２のエントリポイントは、「／ｐｒｏｃ」エントリのためのものである。ユーザ空間プログラムがこのエントリを開くと、カーネルによって生成された規則のリストを読み出すことができる。この第２のエントリポイントの理由は、規則リストを読み出すには、ｉｏｃｔｌコマンドを介してよりも効率的な機構であり、また、カーネルモジュールの特定の「ｉｏｃｔｌ」コマンドを認識し処理するために、特に書く必要のない他のユーザプロセスがより容易に読み出し可能なためである。
【発明を実施するための最良の形態】
【００７０】
要約すれば、従来の高信頼性オペレーティングシステム手法と同様に、コンテインメントプロパティが、プロセス、ファイル、およびネットワーク資源をカーネルレベルで強制保護することにより、本発明の例示的な一実施形態におけるオペレーティングシステムにおいて実現される。しかし、本発明のオペレーティングシステムに使用される強制制御は、従来の高信頼性オペレーティングシステムに見られるものとはいくらか異なり、したがって、従来の高信頼性オペレーティングシステムに関連するアプリケーション統合および管理問題のいくらかを少なくとも軽減するよう意図される。
【００７１】
本発明による高信頼性オペレーティングシステムの鍵となる概念は「コンパートメント」であり、システム上の各種サービスおよびアプリケーションは別個のコンパートメント内で実行される。比較的簡単な強制アクセス制御およびプロセスラベリングを用いて、コンパートメントの概念を築く。以下の本発明による例示的な実施形態の高信頼性オペレーティングシステムでは、システム内の各プロセスにはラベルが割り振られ、同じラベルを有するプロセスは同じコンパートメントに属する。カーネルレベルの強制チェックを実施して、あるコンパートメントのプロセスが別のコンパートメントのプロセスに干渉することができないように保証する。強制アクセス制御は、ラベルは整合するかしないかのいずれか一方であるという意味において比較的簡単である。さらに、いくつかの既知の高信頼性オペレーティングシステムでのようなラベルの階層順序付けはシステム内に存在しない。
【００７２】
従来の高信頼性オペレーティングシステムとは異なり、本発明では、メインファイルシステムへのアクセスの直接制御にラベルは使用されない。代わりに、ファイルシステム保護は、メインファイルシステムの異なるセクションに各コンパートメントを関連付けることによってなされる。ファイルシステムのかかるセクションはそれぞれ、メインファイルシステムのｃｈｒｏｏｔであり、ファイルシステムのセクションにアクセスすることができるのは、そのセクションに関連するコンパートメント内で実行中のプロセスだけである。重要なことは、カーネル制御を介して、プロセスがコンパートメント内からｒｏｏｔに移行する機能が取り除かれるため、ｃｈｒｏｏｔをエスケープすることはできない。本発明の例示的な一実施形態は、ｃｈｒｏｏｔ内の少なくとも選択されたファイルを変更不可にする機能も提供する。
【００７３】
コンパートメント間およびネットワーク資源間の柔軟性のある通信経路は、ＴＣＰ／ＵＤＰに加えて大半のＩＰＣ機構に対する狭い、カーネルレベルで制御されるインタフェースを介して設けられる。これら通信インタフェースへのアクセスは、セキュリティ管理者により「コンパートメント単位」で指定される規則によって統制される。したがって、従来の高信頼性オペレーティングシステムとは異なり、コンパートメントとネットワーク資源の間の通信を許可するために、特権を用いて強制アクセス制御を無効とするか、またはユーザレベルの高信頼性プロキシの使用にたよる必要がない。
【００７４】
したがって、本発明はコンテインメントを提供するが、アプリケーションの統合を比較的簡便にするに足る柔軟性も有し、それによって高信頼性オペレーティングシステムの配備および実行に伴う管理オーバヘッドおよび不便さを軽減する高信頼性オペレーティングシステムを提供する。
【００７５】
ここで、本発明の特定の例示的な一実施形態のアーキテクチャおよび実施について述べる。以下の説明では、本発明が完全に理解されるように、多くの特定の詳細が述べられる。しかし、本発明はこういった特定の詳細に制限されることなく実施可能なことが当業者には認められよう。他の場合では、本発明を不必要に曖昧にすることを避けるために、既知の方法および構造についての詳細な説明は省く。
【００７６】
以下の説明では、ＨＴＴＰサーバ等、ユーザレベルのサービスのコンテインメントをサポートするようにベースＬｉｎｕｘカーネルを変更することによって実現される高信頼性Ｌｉｎｕｘオペレーティングシステムについて詳細に述べる。しかし、本発明の原理は、他のタイプのオペレーティングシステムにも適用することができ、同じもしくは同様の効果を上げることができることは当業者により認められよう。
【００７７】
本発明の例示的な一実施形態による高信頼性オペレーティングシステムを実現するようにＬｉｎｕｘオペレーティングシステムに加える変更は、以下のように概ね分類することができる。
【００７８】
１．以下のエリアにおけるカーネルの変更
＊ＴＣＰ／ＩＰネットワーキング
＊ルーティングテーブルおよびルーティングキャッシュ
＊システムＶ ＩＰＣ−メッセージキュー、共有メモリ、およびセマフォ
＊プロセスおよびスレッド
＊ＵＩＤハンドリング
２．以下の形態のカーネル構成インタフェース
＊動的ロード可能カーネルモジュール
＊これらモジュールと通信するためのコマンドラインユーティリティ
３．個々のコンパートメントを管理／構成するユーザレベルのスクリプト
＊コンパートメントを開始／停止するスクリプト
図面の図２を参照して、ベースＬｉｎｕｘカーネルに対する主要な変更エリアを含み、構成可能ｃｈｒｏｏｔ ｊａｉｌにおいてＣＧＩバイナリを実行可能なウェブサーバを実施するユーザ空間に一連のコンパートメントを追加した、本発明の例示的な一実施形態による高信頼性Ｌｉｎｕｘホストオペレーティングシステムのアーキテクチャを示す。
【００７９】
かくして、図２を参照すると、ベースＬｉｎｕｘカーネル１００は一般に、ＴＣＰ／ＩＰネットワーキング手段１０２と、Ｕｎｉｘドメインソケット１０４と、Ｓｙｓ Ｖ ＩＰＣ手段１０６と、他のサブシステム１０８とを備える。高信頼性Ｌｉｎｕｘオペレーティングシステムは、セキュリティモジュール１１２と、装置構成モジュール１１４と、規則データベース１１６と、カーネルモジュール１１８との形態のカーネル拡張１１０をさらに備える。図示のように、Ｌｉｎｕｘカーネルサブシステム１０２、１０４、１０６、１０８の少なくともいくつかは、カーネルレベルセキュリティモジュール１１２にコールアウトするように変更されている。セキュリティモジュール１１２は、アクセス制御判定を行い、コンパートメントの概念を実施し、それによってコンテインメントを提供する責任を有する。
【００８０】
セキュリティモジュール１１２はさらに、判定を行うときに規則データベース１１６を照会する。規則データベース１１６は、コンパートメントへまたコンパートメントから、狭く十分に制御されたインタフェースを提供するための、コンパートメント間の許容可能な通信経路についての情報を含む（図面の図１２も参照のこと）。
【００８１】
図面の図２は、カーネル拡張１１０が一連のｉｏｃｔｌコマンドを介してユーザ空間１２０からどのように管理されるかも示している。かかるｉｏｃｔｌコマンドは２つの形態をとる：規則テーブルを操作する形態、および特定のコンパートメント中のプロセスを実行し、ネットワークインタフェースを構成する形態である。
【００８２】
図２に示すウェブサーバ等のユーザ空間サービスは、プラットフォーム上で変更されずに実行されるが、セキュリティ拡張へのコマンドラインインタフェースを介してコンパートメントラベルが関連付けられている。そしてセキュリティモジュール１１２は、付けられたコンパートメントラベルに基づいて、強制アクセス制御をユーザ空間サービスに適用する責任を有する。このため、ユーザ空間サービスを変更する必要なく、こういったサービスを封じ込めることが可能なことが認められよう。
【００８３】
図面の図２を参照して述べるシステムアーキテクチャの３つの主な構成要素は、ａ）通信規則およびプロセスコンパートメントラベル等、セキュリティ拡張の根本的な態様を構成および管理するために必要なコマンドラインユーティリティ、ｂ）この機能をカーネル内で実施するロード可能モジュール、およびｃ）この機能を利用するために行われたカーネル変更である。ここで、これら３つの主な構成要素について以下により詳細に述べる。
【００８４】
ａ）コマンドラインユーティリティ
「ＣＡＣＣ」は、ｃａｃカーネルロード可能モジュール（図示せず）によって提供される／ｄｅｖ／ｃａｃｃおよび／ｐｒｏｃ／ｃａｃｃインタフェースを介して規則の追加、削除、およびリスト化を行うためのコマンドラインユーティリティである。規則は、コマンドラインに入力しても、またはテキストファイルから読み出してもよい。
【００８５】
本発明の例示的な本実施形態では、規則のフォーマットは以下である。
【００８６】
＜rule＞::=＜source＞[＜port＞]−＞＜destination＞[＜port＞]＜method list＞＜netdev＞
ただし、
【数１】
＜comp_name＞==コンパートメントの有効な名前
＜host_name＞==既知のホスト名またはＩＰアドレス
＜ip_addr＞==a.b.c.d形態のＩＰアドレス
＜netmask＞== a.b.c.d形態の有効ネットマスク
＜bits＞==ネットマスクにおける最左端ビットの数字、０〜３１
＜method_list＞==カンマで区切られたメソッドのリスト（例示的な本実施形態において、サポートされるメソッドは、ＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、およびＡＬＬである。
【００８８】
規則を追加するには、ユーザは「ｃａｃｃ−ａ＜ｆｉｌｅｎａｍｅ＞」を入力する（＜ｆｉｌｅｎａｍｅ＞が上記フォーマットの規則を含むファイルである場合、テキストファイルから規則を読み出す）か、または「ｃａｃｃ−ａ ｒｕｌｅ」を入力する（規則をコマンドラインに入力する）ことができる。
【００８９】
規則を削除するには、ユーザは、「ｃａｃｃ−ｄ＜ｆｉｌｅｎａｍｅ＞」、またはｃａｃｃ−ｄ ｒｕｌｅ、もしくはｃａｃｃ−ｄ ｒｅｆ（この形では、単に、コマンドｃａｃｃ−ｌを使用して規則をリスト化することによって出力される参照番号によって規則を削除することができ、コマンドｃａｃｃ−ｌは、標準形式で規則を出力またはリスト化し、規則参照は各規則の終わりに注釈として出力される）を入力することができる。
【００９０】
デフォルトにより、「ｃａｃｃ」はカレント作業ディレクトリにおいてコンパートメントマッピングファイル「ｃｍａｐ．ｔｘｔ」およびメソッドマッピングファイル「ｍｍａｐ．ｔｘｔ」を見つけるものと期待される。しかしこれは、本発明の例示的な本実施形態では、ＵＮＩＸ環境変数ＣＡＣＣ＿ＣＭＡＰおよびＣＡＣＣ＿ＭＭＡＰを実際にファイルが常駐するところにセットすることによって無効とされる可能性がある。
【００９１】
ｃａｃｃによって捕捉されたあらゆる構文エラーまたは意味エラーは、エラーレポートをもたらし、コマンドが即時終了し、規則が追加または削除されないことになる。テキストファイルが規則の入力に使用されている場合には、エラーのあるラインのライン番号がエラーメッセージに提供される。
【００９２】
本発明の例示的な本実施形態によって提供される別のコマンドラインユーティリティは、「ｌｃｕ」として知られており、ＬＮＳカーネルモジュール（図示せず）へのインタフェースを提供する。ｌｃｕの最も重要な機能は、各種管理スクリプトに、所与のコンパートメント中のプロセスを生成する機能およびインタフェースのコンパートメント数をセットする機能を提供することである。以下は使用例である。
【００９３】
１．'lcu setdev eth0 0xFFFF0000'
ｅｔｈ０ネットワークインタフェースのコンパートメント番号を０ｘＦＦＦＦ００００にセットする
２．'lcu setprc 0x2-cap_mknod bash'
コンパートメント０ｘ２に切り換え、ｃａｐ＿ｍｋｎｏｄ機能を解除し、ｂａｓｈを呼び出す
ｂ）カーネルモジュール
本発明の例示的な本実施形態は、カスタムｉｏｃｔｌ（ ）の実施に、規則の挿入／削除およびネットワークインタフェースのラベル付け等他の機能を可能にする２つのカーネルモジュールを使用する。しかし、２つのモジュールをカスタムシステムコールに併合し、かつ／またはカスタムシステムコールで置き換えてもよいものと考えられる。本発明の本実施形態では、２つのカーネルモジュールの名前はｌｎｓおよびｃａｃである。
【００９４】
ｌｎｓモジュールは、カスタムｉｏｃｔｌ（ ）を介して各種インタフェースを実施し、以下を可能にする。
【００９５】
１．呼び出しプロセスがコンパートメントを切り換えること、
２．個々のネットワークインタフェースにコンパートメント番号を割り当てること。
【００９６】
コンパートメント番号を使用してのプロセスリスト化、およびカーネルレベルのセキュリティチェックに対するアクティビティのログ化等のユーティリティ関数。
【００９７】
このモジュールの主なクライアントは、上述したｌｃｕコマンドラインユーティリティである。
【００９８】
ｃａｃモジュールは、インタフェースを実施して、カスタムｉｏｃｔｌ（ ）を介してカーネルにおいて規則を追加／削除する。これは、より上位レベルの簡略化された規則を、カーネル参照ルーチンがより理解し易い原始的な形に翻訳する。このモジュールは、ｃａｃｃおよびｃｇｉｃａｃｃユーザレベルユーティリティと呼ばれ、カーネル内の規則を操作する。
【００９９】
ｃ）カーネル変更
本発明の例示的な本実施形態では、各種データ型に付けられるタグを導入し、このようにタグ付けされたデータ型に対してもアクセス制御チェックをさらに行うように、標準Ｌｉｎｕｘカーネルソースに変更が加えられている。タグ付けされた各データ型は追加として、コンパートメント番号を保持するために用いられるｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバ（図面の図３に示す）を含む。タグ付けされたデータ型は、他のセキュリティ属性も保持するように拡張可能なものと考えられる。一般に、このデータメンバの追加は通常、共通のエントリで始まる２つまたはそれよりも多くの名前の異なる構造体にポインタを向ける慣行に関連して発生する問題を回避するように、データ構造体の最後の最後で行われる。
【０１００】
個々のカーネル資源をタグ付けする最終的な効果は、生成／消費するプロセスおよびデータが相互に分離されたコンパートメント化システムの実施が非常に簡単なことである。かかる分離は、多くの隠れチャネルが存在する（プロセスについての以下の考察を参照）という意味において、厳密な分離を意図しない。分離は単に、論理的に異なるプロセス群の間の明確な形のコンフリクトおよび／または相互作用を回避するものと意図される。
【０１０１】
本発明の例示的な本実施形態では、カーネルにおいて保護されているサブシステムにイエス／ノーセキュリティチェックを実施する単一関数ｃｎｅｔ＿ｃｈｋ＿ａｔｔｒ（ ）が存在する。この関数への呼び出しは、カーネルソースにおいて、要求されたコンパートメント化動作を実施するに相応しいポイントで行われる。この関数は、考慮するサブシステムに基づき、そのときに照会されているオペレーションがあるサブシステムに応じてわずかに異なるデフォルトまたは規則規定を実施することができる。たとえば、大半のサブシステムは単純なパーテーション化を実施し、まったく同じコンパートメント番号を有するオブジェクト／資源にしか肯定の値が返されない。しかし、特定の場合では、非特権コンパートメント０および／またはワイルドカードコンパートメント−１Ｌの使用を用いることができ、たとえば、コンパートメント０を分類されていない資源／サービスのデフォルト「サンドボックス」として使用し、ワイルドカードコンパートメントを、シャットダウン前にサブシステム上のすべてのプロセスをリスト化するなど、管理目的に使用することができる。
【０１０２】
図面の図４を参照して、標準ＬｉｎｕｘＩＰネットワーキングについてまず説明する。各プロセスまたはスレッドは、カーネル中のｔａｓｋ＿ｓｔｒｕｃｔ変数で表される。プロセスは、ＴＣＰ／ＵＤＰを介して、ネットワーク通信のためのＡＦ＿ＩＮＥＴドメインにソケットを作成する。これらは、これもまたカーネル中のｓｔｒｕｃｔソケットおよびｓｔｒｕｃｔ ｓｏｃｋ変数の対で表される。
【０１０３】
ｓｔｒｕｃｔ ｓｏｃｋデータ型は、とりわけ、ｓｔｒｕｃｔ ｓｋ＿ｂｕｆｆで表される入力パケットのキューを含む。これはまた、パケット伝送用の予め割り当てられたｓｋ＿ｂｕｆｆのキューも保持する。各ｓｋ＿ｂｕｆｆは、ＩＰスタックの上下に移行するＩＰパケットおよび／またはフラグメントを表す。ｓｔｒｕｃｔ ｓｏｃｋから（または、より具体的には、内部の予め割り当てられた送信キューから）発せられ、伝送のために下方に移行するか、あるいはネットワークドライバから発せられ、ネットワークインタフェースを表すｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅから始まるスタックの底から上方に移行する。下方に移行する場合には、ｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅで効果的に終わる。上方に移行する場合には、通常、待機中のｓｔｒｕｃｔ ｓｏｃｋ（実際、その保留キュー）に送られる。
【０１０４】
ｓｔｒｕｃｔ ｓｏｃｋ変数は、ｓｏｃｋｅｔ（ ）コールによって本質的に間接的に作成され（実際には、実行中のプロセスまでトレースすることができないカーネル自体内のスタックの各種部分が所有するプロトコル単位のプライベートソケットがある）、通常、所有するユーザプロセス、すなわちｔａｓｋ＿ｓｔｒｕｃｔまでトレースすることができる。ｓｔｒｕｃｔ ｎｅｔ＿ｄｅｖｉｃｅ変数は、ループバックインタフェースを含む、システム上の各構成インタフェースに存在する。ローカルホストおよびループバック通信は、速度のためにスタックを横切る高速パスを介して移行するようには見えず、代わりに、リモートホスト通信に予想されるようにスタックの上下に移行する。スタック中の各種ポイントにおいて、パケットインタセプトの目的で、登録されたネットフィルタモジュールにコールすることができる。
【０１０５】
追加のｃｓｅｃｉｎｆｏデータメンバを、ＬｉｎｕｘＩＰネットワーキングにおいて最も一般に使用されるデータ型に追加することにより、カーネル生成応答を含め、システム上で実行中のすべてのプロセスについて、個々のＩＰパケットの所有権、ひいては読み出し／書き込みデータフローのトレースが可能になる。
【０１０６】
したがって、本発明の例示的な本実施形態を容易にするように、標準ＬｉｎｕｘＩＰネットワーキングに使用される少なくとも主要なネットワーキングデータ型を変更した。実際には、本発明の本実施形態を実現するために変更されたデータ構造体の大半は、ネットワーキングに関連するものであり、ネットワーキングスタックおよびソケットサポートルーチンに存在する。タグ付けされたネットワークデータ構造体は、区分けされたＩＰスタックの実施に役立つ。本発明の例示的な本実施形態では、ｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏを包含するように以下のデータ構造体を変更した。
【０１０７】
１．struct task_struct−プロセス（およびスレッド）
２．struct socket−抽象ソケット表現
３．struct sock−ドメイン固有ソケット
４．struct sk_buff−ソケット間のＩＰパケットまたはメッセージ
５．struct net_device−ネットワークインタフェース、たとえばｅｔｈ０ ｌｏ等
セットアップ中、主要なデータ型がタグ付けされると、これらデータ型が新たに初期化された変数をカーネルに導入するように使用されたポイントについて、ＩＰスタック全体がチェックされた。いったん、かかるポイントが識別されると、ｃｓｅｃｉｎｆｏ構造体の継承が確実に実行されるようにコードが挿入された。ｃｓｅｃｉｎｆｏ構造体がＩＰネットワーキングスタックを通して伝播する様式について、より詳細に次に述べる。
【０１０８】
ｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバには、名前の付いた２つのソース、すなわちプロセス単位のｔａｓｋ＿ｓｔｒｕｃｔおよびインタフェース単位のｎｅｔ＿ｄｅｖｉｃｅがある。各プロセスは、特権ｉｏｃｔｌ（ ）により明示的に変更されない限り、親からｃｓｅｃｉｎｆｏを継承する。本発明の例示的な本実施形態では、ｉｎｉｔ−ｐｒｏｃｅｓｓにコンパートメント番号０が割り当てられる。そのため、システムスタートアップ中にｉｎｉｔにより生成されるあらゆるプロセスは、明示的に別にセットされる場合を除き、このコンパートメント番号を継承する。システムスタートアップ中、ｉｎｉｔ−ｓｃｒｉｐｔが通常呼び出されて、定義された各ネットワークインタフェースにコンパートメント番号をセットする。図面の図５は、最も一般的な場合に、ｃｓｅｃｉｎｆｏデータメンバがどのように伝播するかを示している。
【０１０９】
他のデータ構造体はすべて、それぞれのｃｓｅｃｉｎｆｏ構造体をｔａｓｋ＿ｓｔｒｕｃｔから、あるいはｎｅｔ＿ｄｅｖｉｃｅから継承する。たとえば、プロセスがソケットを作成する場合、呼び出しプロセスからカレントｃｓｅｃｉｎｆｏを継承するｓｔｒｕｃｔ ｓｏｃｋｅｔおよび／またはｓｔｒｕｃｔ ｓｏｃｋが作成され得る。ｗｒｉｔｅ（ ）をソケットに呼び出すことによって続けて生成されるパケットは、それぞれのｃｓｅｃｉｎｆｏを発信元ソケットから継承するｓｋ＿ｂｕｆｆを生成する。
【０１１０】
入力ＩＰパケットには、到着したネットワークインタフェースのコンパートメント番号がスタンプされるため、スタックを上方に移行するｓｋ＿ｂｕｆｆは、それぞれのｃｓｅｃｉｎｆｏ構造体を発信元ｎｅｔ＿ｄｅｖｉｃｅから継承する。ソケットに送られる前に、各ｓｋ＿ｂｕｆｆのｃｓｅｃｉｎｆｏ構造体が、期待されるソケットのｃｓｅｃｉｎｆｏ構造体と照らし合わせてチェックされる。
【０１１１】
非リモートネットワーキングの場合、すなわち接続が、以下の形態の規則によって許可される複数のネットワークインタフェースのいずれか１つを通してコンパートメントＸとＹの間が接続される場合には、特別な注意を払わなければならないことは認められよう。
【０１１２】
COMPARTMENT X−＞COMPARTMENT Y METHOD tcp
セキュリティチェックはＩＰネットワーキングには二度、すなわち出力に対して一度、および入力に対して一度行われるため、システムが代わりにこれら規則の存在を探すことを阻止する手段を提供する必要がある。
【０１１３】
COMPARTMENT X−＞HOST a.b.c.d METHOD tcp（出力の場合）
HOST a.b.c.d−＞COMPARTMENT Y METHOD tcp（入力の場合）
これは有効であるが、発信元および宛先のコンパートメントを直接指定する規則に優先しては使用されない場合がある。これを考慮に入れるために、本発明の例示的な本実施形態では、ループバックデバイスに送られるパケットは、それぞれ元のコンパートメント番号を保持し、最終的な送信に単に「反映」させる。この場合、セキュリティチェックは引き渡しに対して行われ、伝送に対しては行われないことに留意する。入力ローカルパケットをロープバックインタフェース上で受け取ると、システムはセットアップされ、パケットのコンパートメント番号がネットワークインタフェースのコンパートメント番号で上書きされず、引き渡しに対する最終的なチェックのためにスタックの上方に移行させる。いったん上方に移行すると、システムは、
HOST a.b.c.d−＞COMPARTMENT Y METHOD tcpの代わりに、
COMPARTMENT X−＞COMPARTMENT Y tcp
の形態の規則をチェックする。これは、ネットワークインタフェース（本発明の例示的な本実施形態におけるネットワークインタフェースは、一般規則として、０ｘＦＦＦＦ００００よりも上の範囲のコンパートメント番号が割り当てられるため、実行中のサービスに割り当てられるコンパートメント番号と区別することができる）に通常割り当てられる形態ではないコンパートメント番号がｓｋ＿ｂｕｆｆに存在するためである。
【０１１４】
規則は一方向性のものであるため、ＴＣＰレイヤは、ｃｏｎｎｅｃｔ（ ）あるいはａｃｃｅｐｔ（ ）の結果としてＴＣＰ接続がセットアップされると、逆データフローを扱う規則を動的に挿入する必要がある。これは、本発明の例示的な本実施形態では自動的に行われ、ＴＣＰ接続が閉じられると、規則は削除される。ｓｔｒｕｃｔ ｓｏｃｋの形態で完全にセットアップされたものとは対照的に、ｓｔｒｕｃｔ ｔｃｐ＿ｏｐｅｎｒｅｑが作成され保留中の接続要求の状態を表す場合には特別な処理が行われる。作成されたリバース規則の参照は、保留中要求とともに格納され、接続要求がタイムアウトするか、ある他の理由により失敗した場合にも削除される。
【０１１５】
この例は、コンパートメント２からリモートホスト１０．１．１．１に接続が行われる場合である。かかる動作を許す元の規則は、以下のようなものであり得る。
【０１１６】
COMPARTMENT 2−＞NET 10.1.1.0/255.255.255.0 METHOD tcp
その結果、リバース規則はこのようなものである（abc/xyzが使用される特定のポート番号）。
【０１１７】
HOST 10.1.1.1 PORT abc−＞COMPARTMENT 2PORT xyz METHOD tcp
コンパートメント単位のルーティングテーブルをサポートするために、各ルーティングテーブルエントリにｃｓｅｃｉｎｆｏ構造体がタグ付けされる。本発明の例示的な実施形態における、変更された各種データ構造体は以下である。
【０１１８】
１．struct rt_key
２．struct rtable
３．struct fib_rule
４．struct fib_node
ルートコマンドを使用してルートを挿入すると、ユーザプロセスの呼び出しコンテキストから受け継いだｃｓｅｃｉｎｆｏ構造体を有するルーティングテーブルエントリが挿入される。すなわち、ユーザがコンパートメントＮ中のシェルからルートコマンドを呼び出すと、追加されるルートに、コンパートメント番号としてＮがタグ付けされる。ルーティングテーブル情報を見ようという試み（通常、／ｐｒｏｃ／ｎｅｔ／ｒｏｕｔｅおよび／ｐｒｏｃ／ｎｅｔ／ｒｔ＿ｃａｃｈｅを調べることにより）は、呼び出しユーザプロセスのｃｓｅｃｉｎｆｏ構造体の値に基づく。
【０１１９】
ｓｋ＿ｂｕｆｆがとるべき入出力ルートの判定に使用される主なルーチンは、ｉｐ＿ｒｏｕｔｅ＿ｏｕｔｐｕｔ（ ）およびｉｐ＿ｒｏｕｔｅ＿ｉｎｐｕｔ（ ）である。本発明の例示的な本実施形態では、これらのルーチンが、あらゆるルーティングテーブル参照の土台であるｃｓｅｃｉｎｆｏ構造体へのポインタからなる追加の引数を含むように拡張されている。追加されるこの引数は、入力あるいは出力のためにルーティングされているパケットのどちらか一方のｓｋ＿ｂｕｆｆから与えられる。
【０１２０】
カーネルに挿入されたルーティングエントリは、特別な状態を有し、ワイルドカードコンパートメント番号（−１Ｌ）が挿入される。コンパートメント単位ルーティングの状況では、すべてのコンパートメントがこういったエントリを共有することができる。かかる機構の主な目的は、入力パケットをスタックに適宜ルーティング可能にすることである。セキュリティチェックはいずれも、ｓｋ＿ｂｕｆｆがソケット（またはｓｋ＿ｂｕｆｆキュー）で送られる直前に、より上位のレベルで行われる。
【０１２１】
最終的な効果は、各コンパートメントが、デフォルトでは空のルーティングテーブルをそれぞれ個々に有するように見えることである。あらゆるコンパートメントは、システム全体のネットワークインタフェースを共用する。本発明の例示的な本実施形態では、個々のコンパートメントを、利用可能なネットワークインタフェースの限られた部分集合に制限することが可能である。これは、各ネットワークインタフェースが概念的にそれぞれのコンパートメントにある（それぞれのルーティングテーブルとともに）ためである。実際、ＩＣＭＰエコー要求に応答して、個々の各インタフェースは、オプションとして、ルーティングテーブルエントリをタグ付けして、プロトコル単位のＩＣＭＰソケットを出力パケットにルーティング可能にするように構成することができる。
【０１２２】
他のサブシステム
＊ＵＮＩＸドメインソケット−各ＵＮＩＸドメインソケットもまた、ｃｓｅｃｉｎｆｏ構造体がタグ付けされる。これらもｓｋ＿ｂｕｆｆを使用して、接続されたソケット間を移行するメッセージ／データを表すため、上述したＡＦ＿ＩＮＥＴドメインが使用する機構の多くも同様に適合する。加えて、セキュリティチェックもまた、ピアに接続する試みがある都度行われる。
【０１２３】
＊システムＶ ＩＰＣ−上に列挙した各ＩＰＣ機構は、同様にｃｓｅｃｉｎｆｏ構造体がタグ付けされた専用カーネル構造体を使用して実施される。これら構造体へのメッセージのリスト化、追加または除去を行おうとする試みは、個々のｓｋ＿ｂｕｆｆと同じセキュリティチェックの対象となる。セキュリティチェックは、使用される機構の厳密なタイプに依存する。
【０１２４】
＊プロセス／スレッド−個々のプロセス、すなわちｔａｓｋ＿ｓｔｒｕｃｔにはｃｓｅｃｉｎｆｏ構造体がタグ付けられるため、大半のプロセス関連演算は、プロセスのコンパートメント番号の値に基づくことになる。特に、プロセスリスト化（／ｐｒｏｃインタフェースを介して）は、コンパートメント単位のプロセスリスト化の効果を上げるように制御される。信号送出は、コンパートメントが切り換えられ、そのために１ビット隠れチャネルを構成している場合もある親プロセスへの信号送出に関して考慮すべき問題があるため、いくらか複雑である。
【０１２５】
システムデフォルト
プロトコル単位のソケット−ＬｉｎｕｘＩＰスタックは、特別なプライベートプロトコル毎ソケットを使用して、ＩＣＭＰ応答等デフォルトの各種ネットワーキングの振る舞いを実施する。これらプロトコル毎のソケットは、どのようなユーザレベルソケットにも限定されず、通常、ワイルドカードコンパートメント番号で初期化され、ネットワーキング関数が通常通り振る舞えるようにする。
【０１２６】
コンパートメント０の非特権デフォルトとしての使用−規定は、コンパートメント０による他のコンパートメントおよびネットワーク資源へのアクセスを許可する規則をいずれも決して挿入しないというものである。このように、初期化されたオブジェクト、または適宜説明されていないオブジェクトのデフォルトの振る舞いは、賢明で限定的なデフォルトに分類される。
【０１２７】
デフォルトカーネルスレッド−各種カーネルスレッド、たとえば、数例を挙げればｋｓｗａｐｄ、ｋｆｌｕｓｈｄ、およびｋｕｐｄａｔｅがデフォルトで現れ得る。これらスレッドにもｔａｓｋ＿ｓｔｒｕｃｔ毎にｃｓｅｃｉｎｆｏ構造体が割り当てられ、それぞれのコンパートメント番号は、それぞれの相対的な非特権状態を反映してデフォルトで０である。
【０１２８】
ｒｏｏｔＩＤの奪取に対抗してのコンパートメント封印−個々のコンパートメントは、オプションとして、そのコンパートメント中のプロセスがｓｅｔｕｉｄ（０）および友人（friends）の呼び出しが成功しないように、またいかなるＳＵＩＤ−ｒｏｏｔバイナリも実行されないように「封印」と登録することができる。これは通常、一般に悪意のあるコードの実行につながるバッファオーバーフロー攻撃を受けやすい場合がある外部アクセス可能なサービスに使用される。かかるサービスが最初に擬似ユーザ（非ｒｏｏｔ）として実行されるように制限され、また中で実行するコンパートメントが封印されている場合、バッファオーバーフロー攻撃および／または外部命令の実行によりｒｏｏｔアイデンティティを奪取する試みはいずれも失敗する。なお、ｒｏｏｔとして実行中の既存プロセスは、いずれも実行し続ける。
【０１２９】
上に述べたカーネル変更は、保護されたコンパートメント中の個々のユーザレベルサービスのホスティングのサポートに役立つ。これに加えて、本発明の例示的な本実施形態においてサービスを追加または除去する際に使用されるレイアウト、ロケーション、および規定についてこれより述べる。
【０１３０】
個々のサービスには一般にそれぞれコンパートメントが割り当てられる。しかし、エンドユーザがサービスとして認めるものは、実際には結局いくつかのコンパートメントを使用することになる場合がある。例は、それぞれ個々のコンパートメントにおいてＣＧＩバイナリを実行する高信頼性ゲートウェイエージェントをホストする別のコンパートメントに対する狭いインタフェースを備えた外部アクセス可能なウェブサーバをホストするコンパートメントの使用である。この場合、少なくとも３つのコンパートメントが必要である。
【０１３１】
＊ウェブサーバプロセス用のコンパートメント
＊ＣＧＩバイナリを実行する高信頼性ゲートウェイエージェント用のコンパートメント
＊高信頼性ゲートウェイはそれぞれの構成コンパートメントにおいてＣＧＩバイナリをフォーク／実行するため、ＣＧＩバイナリの適宜分類に必要な数のコンパートメント
あらゆるコンパートメントは名前を有し、／ｃｏｍｐｔの下でｃｈｒｏｏｔ可能な環境として常駐する。本発明の例示的な実施形態において使用する例は、以下を含む。
【表１】
加えて、以下のサブディレクトリも存在する。
【０１３３】
１．/compt/etc/cac/bin−コンパートメント管理用の各種スクリプトおよびコマンドラインユーティリティ
２．/compt/etc/cac/rules−システム上の登録されたあらゆるコンパートメントの規則を含むファイル
３．/compt/etc/cac/encoding−ｃａｃｃユーティリティ、たとえばコンパートメント名マッピングの構成ファイル
コンパートメントの総称的な開始／停止をサポートするために、各コンパートメントは少数の基本的な要件を満たす必要がある。
【０１３４】
１．コンパートメントロケーション／ｃｏｍｐｔ／＜ｎａｍｅ＞下でｃｈｒｏｏｔ可能であること。
【０１３５】
２．コンパートメントの開始／停止に／ｃｏｍｐｔ／＜ｎａｍｅ＞／ｓｔａｒｔｕｐおよび／ｃｏｍｐｔ／＜ｎａｍｅ＞／ｓｈｕｔｄｏｗｎを提供すること。
【０１３６】
３．スタートアップおよびシャットダウンスクリプトが、規則挿入、ルーティングテーブル作成、ファイルシステム搭載（たとえば、／ｐｒｏｃ）、および他のサービス毎の初期化ステップに対する責任を有すること。
【０１３７】
一般に、コンパートメントを外部から見えるようにすべき場合、そのコンパートメント中のプロセスは、デフォルトによりｒｏｏｔとして実行すべきではなく、コンパートメントは初期化後に封印すべきである。統合／移植されているレガシーアプリケーションの性質により、これが可能ではない場合もあり、その場合には、プロセスがｃｈｒｏｏｔ−ｊａｉｌ、たとえばｃａｐ＿ｍｋｎｏｄをエスケープしないように、可能な限り多くの機能を除去することが望ましい。
【０１３８】
各種管理スクリプトは各構成コンパートメントのファイルシステムにアクセスする必要があり、またこれら管理スクリプトは、管理ウェブサーバのＣＧＩインタフェースを介して呼び出されることから、これらスクリプトは正常なコンパートメントとして、すなわち／ｃｏｍｐｔ／＜ｎａｍｅ＞下に常駐することができないと言える。
【０１３９】
本発明の例示的な本実施形態では、使用される手法は、あらゆる構成コンパートメントの管理スクリプトのｃｈｒｏｏｔ可能な環境を封じ込めるが、その環境が確実にホストファイルシステムの限られた部分集合であるようにするというものである。自然な選択としては、管理スクリプトのｃｈｒｏｏｔ−ｊａｉｌにｒｏｏｔ ａｔ／ｃｏｍｐｔを持たせる。結果得られる構造を図面の図１１に模式的に示す。
【０１４０】
コンパートメントは、／ｃｏｍｐディレクトリ下のｃｈｒｏｏｔ化環境として存在するため、アプリケーションの統合に必要なのは、確実にｃｈｒｏｏｔ化環境で働くようにするために使用される普通の技法である。一般的な技法では、インストールされたソフトウェアの最小ＲＰＭデータベースを含む、最小実行中のコンパートメントのｃｐｉｏ−ａｒｃｈｉｖｅを用意する。所望のアプリケーションをこのトップにインストールすることが普通であり、ＲＰＭの形態のアプリケーションの場合、以下のステップを行うことができる。
【０１４１】
root@tlinux# chroot/compt/app1
root@tlinux# rpm-install＜PRM-package-filename＞
root@tlinux# [必要に応じて構成ファイル、たとえばｈｔｔｐｄ．ｃｏｎｆを変更]
root@tlinux# [スタートアップ／シャットダウンスクリプトを／ｃｏｍｐｔ／ａｐｐ１に作成]
後の少数のステップは、ＲＰＭインストール段階に統合することができる。ディスクスペースの削減は、検査、すなわちｒｐｍコマンドを介して使用されていないパッケージを選択的にアンインストールすることによって実現することができる。必要であれば、コンパートメントの／ｄｅｖディレクトリ中にエントリをさらに作成することができるが、通常、／ｄｅｖは殆どの場合、実質的にありのままである。さらなる自動化は、ウェブベースのインタフェースを上記プロセスに提供して、インストールするアプリケーションの各タイプに必要なパラメータをすべて与えることによって実現することができる。かかるアプリケーションのコンパートメントアウェアバリアントをインストールする必要がある場合を除いて、コンパイルされたバイナリを変更する必要は一般にない。
【０１４２】
本発明の一態様の特定の実施形態について詳細に上述した。しかし、多種多様な異なる技法を、本発明によって提供されるコンテインメントの一般的な概念の実施態様に使用することができる。オペレーティングシステムの書き換えは、可能な限り多くのユーザレベルアプリケーションを再使用可能である必要があるため、明らかに望ましくない。このため介在技法（interposition technique）があり、そのうちのいくつかを以下に列挙する。介在技法は、主にユーザレベルで動作しているもの、あるいはカーネルベースで動作しているものに分類することができる。
【０１４３】
ユーザレベルの技法
以下に、３つの一般的なユーザレベルの技法または機構について概説する。
【０１４４】
１．ｓｔｒａｃｅ（ ）機構
この機構は、システムカーネルに構築された機能を使用して、選択されたプロセスの各システムコールをトレースする。この機構を使用すると、各システムコールおよびその引数を識別することができ、システムコールは通常、規定されたセキュリティポリシーに従って続行許可されるか（引数が変更されることがある）、あるいは失敗する。
【０１４５】
この機構は、多くのアプリケーションに適しているが、いくつかの欠点を有する。これら欠点の１つは、トレースされているプロセスＰが、ｆｏｒｋ（ ）システムコールから戻る前に実行がスケジューリングされた子Ｑをフォークする可能性がある「子の暴走（runaway child）」問題の場合に明らかになる。ｓｔｒａｃｅ（ ）は、プロセスＩＤ（ＰＩＤ）を使用してプロセスに添付することによって働き、ＱのＰＩＤは、Ｑが実際に実行をスケジューリングされる前にＰ（ひいてはトレーサ）に必ずしも戻されるわけではないため、トレーサを添付することができるようになる前に、Ｑが任意の長さのコードの実行を許可されてしまう危険性がある。
【０１４６】
この問題に対する１つの方策は、まだトレースされていないプロセスについてカーネル中のあらゆるシステムコールをチェックし、トレーサが最終的に追いつくことができるように、たとえば、まだトレースされていないプロセスを強制的に「スリープさせる」ことにより、その場所に留めることである。しかし、この方策では、追加のカーネルコンポーネントが必要である。
【０１４７】
２．システムコールラッピング
この機構の別の欠点は、トレースされたシステムコールへの引数が変更されることがある競合状況が存在する場合に発生する。これが発生する期間は、トレーサが引数のセットを検査するときから、実際にシステムコールの続行を許可するときまでである。トレースされたプロセスと同じアドレス空間を共有するスレッドは、この間隔中にメモリにおける引数を変更することができる。
【０１４８】
この機構を使用すると、トレースする必要のあるプロセスに対してリンクされた、システムコールへのラッパを含む動的リンク共有ライブラリを用いてシステムコールをラップすることができる。こういったラッパは、予め定義されたセキュリティポリシーに従って判定を行うモジュールへのコールアウトを含むことができる。
【０１４９】
この機構に関連する１つの欠点は、プロセスが使用するものと想定されるシステムコールが未解決の外部参照ではなく、動的ローダによりリンクすることができない場合に容易に破壊される可能性があることである。また、レジスタのセットアップが通常のシステムコールのように正しい状態で、プロセスがソフト割り込み自体を実行する場合、システムコールにラッパを迂回させることも可能である。この場合、カーネルは、ラッパに渡すことなくコールを処理する。加えて、場合によっては、ＬＤ＿ＰＲＥＬＯＡＤ環境変数への依存もまた、許容できない弱いリンクであることもある。
【０１５０】
３．ユーザレベルの認証サーバ
このカテゴリは、カーネルへのプライベートチャネルを介して与えられるデータに対して作用するユーザ空間における認証サーバを含む。この手法は、多くの場合に非常に効果的であるが、いくつかの欠点を有する。すなわち、Ｉ）チェック中の各システムコールが少なくとも２つのコンテキスト切り換えを受け、この方策が比較的低速になること、ｉｉ）割り込みルーチンが、スリープしないという要件によりユーザ空間カーネルにブリッジすることがより難しいこと、およびｉｉｉ）カーネルレベルのコンポーネントが通常、強制トレースを実施する必要があること、である。
【０１５１】
上に概説したユーザレベル手法の欠点にも関わらず、本発明の一態様による高信頼性オペレーティングシステムを実施するユーザレベル技法は、開発および維持が比較的容易であるという利点を有するが、状況によっては、システム全体の強制制御の実施には不十分なことがある。
【０１５２】
最終的に、本発明の目的は、実行中のアプリケーションを封じ込めることであり、これは好ましくは、セキュリティ管理者により直接許可されていないエージェントが自由裁量ベースで無効とすることができない一連の強制アクセス制御によって実施される。実行中の第三者アプリケーションにトランスペアレントなコンテインメントの実施は、カーネルレベルのアクセス制御によって実現することができる。考えられるエントリポイントを調べ、互いの中および互いに対するカーネルサブシステムの相互作用を分離することにより、カーネルおよびその資源のビューを実行中のアプリケーションに関してセグメント化することが可能になる。
【０１５３】
かかるセグメント化方式は、カーネル自体内での実施により強制的な性質のものであり、コンテインメント方式を明らかに承知して、それを利用するように書き換えられた場合を除き、実行中のアプリケーションによって無効とされる可能性がある自由裁量的な側面がない。
【０１５４】
本発明を実施するカーネルレベルの手法の３つの例を以下に概説し、図面の図６に示す。第１の手法は主に、カーネルおよびその内部データ構造へのパッチに基づく。第２の手法は、いずれのカーネルパッチもまったく必要としないという点においてまったく異なり、代わりに、選択されたシステムコールを置き換え、おそらく実行時のカーネルのイメージを変更することによって動作する動的ロード可能カーネルモジュールである。これら手法は両方とも、通常、カーネルへのプライベートチャネルを介して動作するユーザレベルの構成ユーティリティを必要とする。第３の手法は、第１の手法によって提供される絶対制御と、第２の手法によって提供されるカーネルソース変更からの独立とを折衷したものである。
【０１５５】
１．コンテインメントをサポートするようにするソースレベルでのカーネル変更（Ｖ１）
この手法は、標準オペレーティングシステム（この場合、Ｌｉｎｕｘ）のカーネルソースへの一連のパッチとして実施される。規則テーブルの維持に必要なロジックをホストし、また、カーネルとユーザ空間構成ユーティリティとの間のインタフェースとしても動作する動的ロード可能カーネルモジュールもある。カーネルモジュールは、初期にブートシーケンスに挿入され、定義された規則がない状態で限定セキュリティモデルを即座に実施する。これに先立って、カーネルは、すべてのプロセスが、機能可能であるが、本質的に大半の目的に役立たないデフォルトコンパートメント０で生成される状態で、適切にブートできるように設計された限定セキュリティモデルを実施する。カーネルモジュールがロードされると、カーネルは内蔵モデルからモジュールにおけるモデルに切り替わる。コンテインメントは、カーネル資源をタグ付けし、タグの値および規定されているかもしれないあらゆる規則に応じてこれら資源へのアクセスを分割することによって実現される。
【０１５６】
したがって、保護が必要な各カーネル資源は、資源が属するコンパートメントを示すタグで拡張される（上に述べたように）。コンパートメントは、カーネル内の単一ワードサイズの値によって表されるが、ユーザレベル構成ユーティリティはより記述的なストリング名を使用する。かかる資源の例としては、以下を記述するデータ構造体が挙げられる。
【０１５７】
＊個々のプロセス
＊共有メモリセグメント
＊セマフォ、メッセージキュー
＊ソケット、ネットワークパケット、ネットワークインタフェース、およびルーティングテーブル照会
本発明の例示的な実施形態によるこのコンテインメント手法をサポートするように変更されたデータ構造体の完全なリストを本明細書に添付した付録７．１に示す。上で説明したように、タグの割り当ては主に継承を通して行われ、ｉｎｉｔ−プロセスはまずコンパートメント０に割り当てられる。プロセスによって作成されるあらゆるカーネルオブジェクトは、実行中プロセスのカレントラベルを継承する。カーネルの適切なポイントで、アクセス制御チェックが、別のコンパートメントの資源へのアクセスが許可されているコンパートメントを示す規則テーブルを照会する動的ロード可能セキュリティモジュールへのフックの使用を通して行われる。これは、実行中アプリケーションにトランスペアレントに行われる。
【０１５８】
各セキュリティチェックでは、規則テーブルを照会する。上に述べたように、各規則は以下の形態を有する。
【０１５９】
source−＞destination method m[attr][netdev n]
ただし、ｓｏｕｒｃｅ／ｄｅｓｔｉｎａｔｉｏｎは、以下のうちの１つである。
【０１６０】
ＣＯＭＰＡＲＴＭＥＮＴ（名前の付いたコンパートメント）
ＨＯＳＴ（固定ＩＰｖ４アドレス）
ＮＥＴＷＯＲＫ（ＩＰｖ４サブネット）
ｍ：サポートされるカーネル機構。たとえば、ｔｃｐ、ｕｄｐ、ｍｓｇ（メッセージキュー）、ｓｈｍ（共有メモリ）等
ａｔｔｒ：メソッドｍをさらに修飾する属性
ｎ：妥当な場合には、名前の付いたネットワークインタフェース、たとえばｅｔｈ０
「ＷＥＢ」と名前の付いたコンパートメント中のプロセスが、たとえば、ｓｈｍａｔ／ｓｈｍｄｔ（ ）を使用して、「ＣＧＩ」と名前の付いたコンパートメントの共有メモリセグメントへアクセスするのを許可するような規則の例は、以下のようなものである。
【０１６１】
COMPARTMENT:WEB−＞COMPARTMENT:CGI METHOD shm
特定の暗黙の規則も存在し、コンパートメント内で実行されるある通信を許可する、たとえば、プロセスによる、同じコンパートメントに常駐するプロセスのプロセス識別子の検査を許可することができる。これにより、そうでなければ構成されていないコンパートメント内の機能を必要最小限にすることができる。例外はコンパートメント０であり、これは相対的に非特権であり、より多くの制限が課される。コンパートメント０は通常、カーネルレベルスレッド（スワッパ等）をホストするために使用される。
【０１６２】
コンパートメント間アクセスの実行を明示的に許可する規則がない場合、かかる試みはすべて失敗する。規則の最終的な効果は、別のコンパートメントの資源へのアクセスが明示的に許可されているものを除き、個々のコンパートメントにわたって強制セグメント化を実施することである。
【０１６３】
規則は方向的な性質のものであり、ＴＣＰソケット接続の接続／受け入れの振る舞いに合致する影響を有する。許される入力ＨＴＴＰ接続の指定に使用される以下の形式の規則を考える。
【０１６４】
HOST*−＞COMPARTMENT X METHOD TCP PORT 80
この規則は、ポート８０上の入力ＴＣＰ接続のみが許可され、出力接続は許可されないことを指定する（図７参照）。規則の方向性により、出力接続の実行を許可することなく、入力接続を正しく確立するために、パケットの逆流を行うことが可能である。
【０１６５】
上に述べた手法にはいくつかの利点がある。たとえば、サポートされる各サブシステムに対して完全なる制御を提供するとともに、サポートされていないもの、たとえば、ハードウェア駆動のカード間転送をコンパイルアウトする機能を提供する。さらに、この手法は、ｐｓ、ｎｅｔｓｔａｔ、ｒｏｕｔｅ、ｉｐｃｓ等のユーザ空間コマンドを変更する必要なく、比較的包括的な名前空間区分けを提供する。プロセスが現在入っているコンパートメントに応じて、可視の識別子のリストが規則に何が指定されているかに従って変更される。名前空間の例としては、プロセステーブル、ｖｉａ／ｐｒｏｃ、ＳｙｓＶ ＩＰＣ資源識別子、アクティブで閉じられたリスニング中のソケット（すべてのドメイン）、およびルーティングテーブルエントリが挙げられる。
【０１６６】
この手法の別の利点は、カーネルおよびその実行中プロセスに関しての同期状態である。スカラータグが各種カーネル資源に添付されることを鑑みて、完全な生存期間にわたる追跡を行う必要がなく、これは、カーネル変数が作成／消費される場所を深く理解する必要があまりないため、パッチを最新に保つという問題を考えた際に大きな利点である。さらに、セキュリティタグの継承は、＃ｉｆｄｅｆｓおよびクローンルーチンを使用することにより明示的に指定する必要がある場合とは異なり、普通のＣ割り当て演算子（＝）またはｍｅｍｃｐｙ（ ）を通して自動的に行われるため、行う必要のあるソース変更はより少ない。
【０１６７】
加えて、アクティブ化されるときに、カーネル資源を再帰的に列挙する必要がない。これは、かかる計算がカーネル開始時に行われるためである。さらに、この手法は、行われるソース変更の数が比較的少ないため、比較的高速なパフォーマンス（最適の約１〜２％）を提供する。システムの使用意図に応じて、内部ハッシュテーブルは、挿入された規則が各ハッシュバケット内で平均して１レベル深さである（これにより、規則参照ルーチンの振る舞いがＯ（１）のオーダになる）ように構成することができる。
【０１６８】
しかし、多くの利点に関わらず、この手法では、ソース変更をカーネルに対して行う必要があり、また、新しいカーネル改訂が入手可能になったときにパッチをアップデートする必要がある。さらに、構造サイズが異なる可能性があるため、モジュールとして配布されるプロプラエタリデバイスドライバは使用不可である。
【０１６９】
２．動的ロード可能カーネルモジュールを介してのシステムコール置換（Ｖ２）
この手法は、動的ロード可能カーネルモジュールの形態でコンテインメントを実施することを含み、上に概説したソースレベルカーネル変更手法の機能を、カーネルソースを変更する必要なく再現することを意図した手法を表す。
【０１７０】
この手法では、モジュールは、選択されたシステムコールをｓｙｓ＿ｃａｌｌ＿ｔａｂｌｅ［］アレイを上書きすることによって置換し、また、それ自体をｎｅｔｆｉｌｔｅｒモジュールとして登録して、入力／出力ネットワークパケットをインタセプトする。モジュールは、システム上の各実行中プロセスが要求する資源を反映し、インタセプトされたシステムコールの適切な時点でアップデートされるプロセスＩＤ（ＰＩＤ）駆動内部状態テーブルを保持する。これらテーブルは、所望の実施態様に応じてプロセス単位あるいは資源単位でセキュリティ属性も含むことができる。
【０１７１】
この手法の規則形式およびシンタックスは実質的に、上に概説したソースレベルカーネル変更手法に関して述べたようなものであり、同様に振る舞う。セグメント化は、システムコールレイヤにおける名前空間の区分けを通して行われる。元のシステムコールを介してのカーネル資源へのアクセスは、実際にシステムコールを行う前に行われるセキュリティチェックを条件としている。
【０１７２】
すべてのシステムコールの置換は、この手法におけるシステムコールの取り扱い方の条件的な性質を反映した独特なｐｒｅ／ａｃｔｕａｌ／ｐｏｓｔ形態を有する。
【０１７３】
したがって、この手法には、カーネル変更が必要ないという利点があるが、カーネル内部の知識が要求される。さらに、セキュリティモジュールが一時的にディセーブルされている間にシステムを実行する機能により、バグの分類がより容易になる。
【０１７４】
この手法と併せて考慮すべきいくつかの欠点および／または問題もある。第１に、実行中のプロセスに関して真に同期する状態を保つことは、主に包括的なカーネルイベント通知機構の欠如に起因する様々な理由から困難である。たとえば、ＳＩＧＳＥＧＶ、ＳＩＧＢＵＳ等によりプロセスが異常に終了する状況を捕捉する正式な機構はない。この問題に提案されている１つの方策は、ｄｏ＿ｅｘｉｔ（ ）に対してわずかなソースコード変更を行い、かかる場合を捕捉するコールバックを提供することを含む。例示的な一実施形態では、カーネルレベル刈り取り（reaper）スレッドを使用して、グローバルタスクリストを監視し、死んだＰＩＤに対してガーベッジコレクション（ごみ収集）を行うことができる。これにより、不安定な短い期間が導入されるが、これは、ＰＩＤのサイクルが上向きであること、および刈り取りスレッドの単一サイクル内で以前使用されたＰＩＤが再度割り当てられる可能性が比較的低いことによっていくらか相殺される。
【０１７５】
上に述べた子の暴走問題に関して、ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅは、おそらくは子が実行するようにスケジューリングされた後まで、子のＰＩＤを戻さない。モジュール実施によりＰＩＤ駆動状態テーブルが作成される場合、これは、子に対する状態エントリが作成される前に、子がシステムコールを呼び出す可能性があることを意味する。子プロセスに添付する必要性があるためにフォークされた子を適宜辿ることができないｓｔｒａｃｅコマンド（上述）にも同じ問題がある。この問題に対して考えられる１つの方策は、必須条件チェックですべてのシステムコールをインタセプトすることであるが、この方策は比較的遅く、状況によっては効果がない。
【０１７６】
考えられる別の方策は比較的複雑であり、本明細書に添付した付録７．２に示される。
【０１７７】
１．ｆｏｒｋ（ ）−親のスタック上のリターンアドレスが、スタックをユーザ空間に書き込むことによって実際のｆｏｒｋ（ ）システムコールを呼び出す前に変更される。これは、変更されたリターンアドレスを継承する子に引き継がれる。変更されたリターンアドレスは元の値よりも５バイト前のポイントにセットされ、これによりｆｏｒｋ（ ）システムコールが子によって最初のアクションとして再び呼び出される。次いで、システムはこれをインタセプトし、必要な状態エントリを作成する。親は、ｆｏｒｋ（ ）から戻る直前に、保存されているリターンアドレスを回復させ、通常通り続行する。（５バイトはまさにＩＡ−３２のｆａｒ ｃａｌｌの形態の命令の長さであることに留意する。他のバリアントは、ＬＤ＿ＰＲＥＬＯＡＤおよび所望の５バイト形態を有するシステムコールラッパを使用してラップすることができる）
２．ｃｌｏｎｅ（ ）−スタックのセットアップが異なるため、フォークされた子（上述したように）がクローン化された子を取り扱うには不適切な場合に用いられるメソッド。代わりに提案されている方策は、以下である。
【０１７８】
ａ．ユーザプロセスの代わりにｂｒｋ（ ）を呼び出し、小さな２５６バイトの塊のメモリを割り当てる。
【０１７９】
ｂ．用意された実行可能コードの塊を新たに割り当てられたこのメモリにコピーする。このコードは、クローン化された子を通常通り処理する前に、指定されたシステムコールを呼び出すであろう。
【０１８０】
ｃ．ｃｌｏｎｅ（ ）への呼び出しにおいて与えられる元のルーチンの代わりに、この新たに用意されたコードの塊を実行するように、ユーザプロセスのスタックを変更する。
【０１８１】
ｄ．ユーザプロセスによって与えられたルーチンへの元のポインタをクローンに保存する。
【０１８２】
クローン化された子が最初に実行されるとき、ポインタを、実行すると想定されていた元のルーチンに戻すシステムコールを行う、用意されたコードの塊を実行する。子はこのポイントでトラップされ、これに対して状態エントリが作成される。次いで、クローン化された子が通常通り元のルーチンを実行する（本明細書に添付した付録７．４を参照）。
【０１８３】
両方の場合において、子はカーネルモジュールに下がって呼び出すように強制され、そこで子をトラップすることができる。
【０１８４】
考えられる別の方策は、子が作成される都度、コールバックを提供するように、カーネルにおけるｒｅｔ＿ｆｒｏｍ＿ｆｏｒｋ（ ）ルーチンを変更することである。代替としては、ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅを実施するｄｏ＿ｆｏｒｋ（ ）カーネル関数を変更することができる。
【０１８５】
ｃｌｏｓｅ−ｏｎ−ｅｘｅｃ振る舞いの追跡もまた、この実施態様では、各プロセス構造体内のファイルシステム関連構造体を熟知していなければ難しい。
【０１８６】
この手法と併せて考慮すべき別の問題は、カーネル資源の事後列挙が、ブートシーケンスが進むにつれて累進的に難しくなることから、可能な限り早くカーネル資源の監視を開始するために、通常、モジュールがブートシーケンスのかなり初期にロードされることである。この手法においてシステムコール引数の有効性をチェックするプロセスが、元のシステムコールではなくカーネルモジュールにシフトされることにも留意されたい。したがって、元のカーネルは変更されないため、この手法ではオーバヘッドがさらにもたらされる。同様に、実質的に複製された状態情報をカーネルから離れて維持することにより、メモリ使用およびプロセッササイクルに関してオーバヘッドが追加される。
【０１８７】
さらに別の欠点は、コンパートメント毎のルーティングおよびこれに依存する機構、すなわち仮想化ＡＲＰキャッシュ、ならびにルートを使用してバックエンドネットワークアクセスをセグメント化する機能が失われることである。これは、タグ付きデータ構造体なしでルーティングコードが変更されずに実行されるためである。最後に、すべての構成を満足させる単一バイナリモジュールを提供することは、不可能でないとしても非常に困難であると考えられる。構造体内のデータメンバのサイズおよびレイアウトは、その特定のカーネルビルドにおける構成オプションに依存する。たとえば、ｎｅｔｆｉｌｔｅｒのコンパイルを指定すると、あるネットワーキング関連データ構造体のサイズおよびレイアウトが変更される。
【０１８８】
動的ロード可能カーネルモジュールの配備と併せて考慮すべきいくつかの問題がある。特定のカーネルデータ構造体のサイズは、構築時に決定される実際の構成オプションに依存する、すなわちデータメンバの数は、カーネルにおいてコンパイルするように選択された機能が何であるかに応じて可変であるため、モジュールをカーネルに整合させる必要性が極めて重要である。したがって、モジュールは既知のカーネルに対して構築することができ、この場合、ソースおよび構成オプション（構成ファイルに表される）を容易に入手可能であり、あるいはインストール時に構築することができ、この場合、モジュールへのソースはインストール場所まで運ぶ必要がある。
【０１８９】
３．カーネルベースの変更をサポートするハイブリッドシステムコール置換
図面の図８を参照して、上に述べた変更カーネルベースの手法（Ｖ１）とシステムコール置換手法（Ｖ２）の特徴のいくつかを組み合わせたハイブリッドコンテインメントオペレーティングシステムの構築に利用可能なオプションのいくつかを模式的に示す。
【０１９０】
実行中のカーネルに関しての状態維持について、Ｖ１手法は、適切な通知機構が欠如していること、およびガーベッジコレクション（ごみ収集）が必要なことから歩調がわずかにずれたままであるＶ２と比較して、カーネルの実際の動作とはるかに密接に歩調を揃えている。Ｖ１での状態情報は、カーネルに関して厳密に同期し、Ｖ２は非同期である。同期性は、内部状態テーブルが、通常、同期プリミティブの取得によってバウンディングされる同じコードセクション内の実際のカーネル状態の変更に伴ってロックステップでアップデートされるか否かによって決まる。同期の必要性を図面の図９に示し、図中、組み込まれたソースから生じるカーネル状態の変更は、介在レイヤにおける複製状態に反映する必要がある。
【０１９１】
再び図面の図８を参照すると、Ｖ１およびＶ２の手法を併せた相対的な利点は、開発者が、略同期状態を実現するためにカーネルソースを変更したいと望む強度に応じて、Ｖ１手法が代表する同期状態の位置と、Ｖ２手法によって提供される非同期状態の位置との間で可変的に決められる。図８は、Ｖ２手法を変更することで、カーネルソースコード変更という相対的にわずかな犠牲で大きな利点が得られる３つのポイントを示す。
【０１９２】
１．ｄｏ＿ｅｘｉｔ（ ）−ｄｏ＿ｅｘｉｔ（ ）カーネル関数を５ライン変更すると、コールバックを提供して、プロセスの異常終了によるグローバルタスクリストの変更を捕捉することが可能になる。かかる変更は、プロセス終了がどのように処理されたかについて知る必要はないが、制御パスがどこにあるかを理解する必要がある。
【０１９３】
２．ｆｏｒｋ／ｖｆｏｒｋ／ｃｌｏｎｅ−ｄｏ＿ｆｏｌｋカーネル関数をさらに５ライン変更すると、実行するようにスケジューリング可能になる前に子のＰＩＤを適宜通知することが可能になる。代替は、ｒｅｔ＿ｆｒｏｍ＿ｆｏｒｋ（ ）を変更することであるが、これはアーキテクチャ依存である。これらオプションのいずれでも、プロセスセットアップの知識は必要なく、ＰＩＤ作成の性質およびＰＩＤ関連構造体を取り巻くロックを認識している必要があるだけである。
【０１９４】
３．割り込み、ＴＣＰタイマ等−このカテゴリは、ハード／ソフトＩＲＱ、ｔａｓｋｌｅｔ、内部タイマ、またはユーザプロセスにトレース不可能なあらゆる実行コンテキストのいずれかの結果としてカーネルにおいて非同期に実行されるすべての動作を網羅する。例は、閉じられたが、まだ完全に消失していないソケットを維持するために使用されるＴＣＰ時間待ちハッシュバケットである。ハッシュテーブルは、パブリックにエクスポートされず、ハッシュテーブルの変更は、コールバック用に正式なＡＰＩがないため追跡することができない。パケット単位で計算を行う必要がある（これは、Ｖ１手法の主要な利点であり、ここからいくつかの特徴が導出される）場合、このカテゴリのカーネルソースへの変更が必要である。しかし、これら（比較的広範な）変更を実行するためには、サブシステムの内部作業について熟知している必要がある。
【０１９５】
本発明の最も重要な用途の１つは、任意のＣＧＩバイナリの制限実行をサポートし、非ＨＴＴＰ関連処理（たとえば、Ｊａｖａサーブレット）がいずれも別個のコンパートメントに区分けされ、それぞれの動作に必要な最低限の規則をそれぞれ有する安全なウェブサーバプラットフォームの提供である。これは、以下の一般的なシナリオよりも具体的な構成である。
【０１９６】
１．ＤＮＳ、Ｓｅｎｄｍａｉｌ等の様々なサービスをホストする安全なゲートウェイシステム。かかるシステムにおけるコンテインメントまたはコンパートメント化を用いて、サービス間の競合の可能性を低減し、また、サービス単位でバックエンドホストの可視性を制御することができる。
【０１９７】
２．中間アプリケーションサーバを含む積層バックエンドに対するフロントエンド（通常ＨＴＴＰ）のクラスタ化。かかるシステムにおけるコンパートメント化は、外部クライアントから直接アクセス可能なコードを可能な限り多く取り除くといった望ましい効果を有する。
【０１９８】
要約すれば、本発明の背後にある基本原理は、あらゆる外部アクセス可能コードのサイズおよび複雑性を最小まで低減することであり、これによって実際のセキュリティ侵害が発生する可能性がある範囲を制限する。可能な限り狭いインタフェースが、可能な限り具体的な規則を使用することにより、かつ／または規則の方向性を利用することにより、個々のコンパートメントにグループ化された各種機能コンポーネントの間に指定される。
【０１９９】
これより、図面の図２を参照して、選ばれた手法であるＶ１に基づいて構成されたウェブサーバプラットフォームを示す。上に述べたように、各ウェブサーバは、それぞれのコンパートメントに置かれる。ＭＣＧＡデーモンは、ＣＧＩ実行要求を取り扱い、それぞれのコンパートメントに置かれる。同様に、管理目的のコンパートメントもさらにある。ユーザレベルコマンドラインユーティリティを利用して、規則の追加／削除、およびプロセスラベルのセットによりカーネルを構成する管理ＣＧＩユーティリティも示される。これらユーティリティは、特権デバイスドライバインタフェースを介して動作する。カーネルでは、各サブシステムが、規則および初期にセットされた構成情報にのっとって動作するカスタムセキュリティモジュールへのコールアウトを含む。システムコールを行うユーザプロセスは最終的に、各サブシステムに存在するセキュリティチェックを受け、対応するデータが処理され、適宜タグ付けされる。
【０２００】
以下の説明は、本発明をどのように使用して、Ｊａｖａサーブレットの取り扱いまたはＪＳＰファイルの扱いを、各自のコンパートメント内でそれぞれ実行中の２つの別個のインスタンスＪａｋａｒｔａ／Ｔｏｍｃａｔに委譲するように構成された、外部を向いたＡｐａｃｈｅウェブサーバを含むセットアップをコンパートメント化することができるかについての説明を意図するものである。デフォルトにより、各コンパートメントは、その他のコンパートメントに干渉しないように、ｃｈｒｏｏｔ化されたファイルシステムを使用する。
【０２０１】
図面の図１０は、１つのコンパートメント（ウェブ）に常駐するＡｐａｃｈｅプロセスを模式的に示す。このコンパートメントは、以下の規則を用いて外部からアクセス可能である。
【０２０２】
HOST*−＞COMPARTMENT WEB METHOD TCP PORT 80 NETDEV eth0
規則中のＮＥＴＤＥＶコンポーネントの存在により、Ａｐａｃｈｅが使用可能なネットワークインタフェースが指定される。これは、デュアル／マルチホームゲートウェイシステム上の外部インタフェースのみを使用するようにＡｐａｃｈｅを制限する際に有用である。これは、不正侵入されたＡｐａｃｈｅのインスタンスが、内部を向いたネットワークインタフェースを通してバックエンドネットワークに対する攻撃の開始に使用されることの回避を意図する。ウェブコンパートメントでは、以下の形態をとる２つの規則を介して、Ｊａｋａｒｔａ／Ｔｏｍｃａｔの２つの別個のインスタンス（ＴＯＭＣＡＴ１およびＴＯＭＣＡＴ２）との通信が許可されている。
【０２０３】
COMPARTMENT:WEB−＞COMPARTMENT:TOMCAT1 METHOD TCP PORT 8007
COMPARTMENT:WEB−＞COMPARTMENT TOMCAT2 METHOD TCP PORT 8008
ＴＯＭＣＡＴ１中のサーブレットは、次の規則を使用して、サーバ１と呼ばれるバックエンドホストにアクセス許可されている。
【０２０４】
COMPARTMENT:TOMCAT1−＞HOST:SERVER1 METHOD TCP …
しかし、ＴＯＭＣＡＴ２は、いずれのバックエンドホストにもアクセス許可されていない。これは、任意の追加規則がないことに反映されている。カーネルは、ＴＯＭＣＡＴ２からのかかる試行をいずれも拒絶するであろう。これにより、どのサービスがホストされているかに応じてバックエンドネットワークのビューを選択的に変更し、また、バックエンドホストの可視性をコンパートメント単位で制限することが可能になる。
【０２０５】
上記４つの規則だけがこの例示的な構成に必要なものであることはまったく価値がない。任意の他の規則がない場合、ＪａｖａＶＭで実行中のサーブレットは、出力接続を開始することができず、特に、インタフェースｅｔｈ１上の内部バックエンドネットワークに対する攻撃の開始に使用することはできない。加えて、他のコンパートメント（たとえば、共有メモリセグメント、ＵＮＩＸドメインソケット等）から資源にアクセスすることができない場合があり、また、リモートホストが直接到達できない場合がある。この場合、ＡｐａｃｈｅおよびＪａｋａｒｔａ／Ｔｏｍｃａｔの振る舞いに対して、それぞれソースを再コンパイルまたは変更することなく、強制制限が課されている。
【０２０６】
これより、アプリケーション統合の例について、ＯｐｅｎＭａｉｌ６．０を参照して述べる。Ｌｉｎｕｘ版ＯｐｅｎＭａｉｌ６．０は、いくつかの未指定フォーマットの大きな１６０Ｍｂ＋アーカイブおよびインストールスクリプトｏｍｉｎｓｔａｌｌからなる。ＯｐｅｎＭａｉｌをインストールするためには、割り当てられた必要最小限度の内部コンパートメントにｃｈｒｏｏｔ化を行うことがまず必要である。
【０２０７】
root@tlinux# chroot/compt/omailin
root@tlinux# ominstall
root@tlinux# [ＯｐｅｎＭａｉｌが自然にインストールされるのを待つ]
root@tlinux# [必要であれば、さらなる構成、たとえばｍａｉｌｎｏｄｅセットアップを行う]
ＯｐｅｎＭａｉｌ６．０は、これもまたインストールする必要があるウェブベースのインタフェースであるため、別の必要最小限度のコンパートメントが割り当てられ（ｏｍａｉｌｏｕｔ）、ＡｐａｃｈｅＨＴＴＰサーバがＨＴＴＰクエリの処理のためにインストールされる。
【０２０８】
root@tlinux# chroot/compt/omailout
root@tlinux# rpm―install＜apache-RPM-filoename＞
root@tlinux# ＯｐｅｎＭａｉｌのインストール命令に必要なＣＧＩ要求を扱うようにＡｐａｃｈｅのｈｔｔｐｄ．ｃｏｎｆを構成］
この時点で、ＡｐａｃｈｅＨＴＴＰサーバがアクセスできるように、ＯｐｅｎＭａｉｌ６．０に付属のＣＧＩバイナリをインストールする必要もある。これは、２つの方法のうちの一方によって行うことができる。
【０２０９】
＊ＯｐｅｎＭａｉｌをｏｍａｉｌｏｕｔに再びインストールし、不必要な部分、たとえばサーバプロセスを除去する、または
＊ＯｐｅｎＭａｉｌ ＣＧＩバイナリをｏｍａｉｌｉｎからコピーし、許可およびディレクトリ構造体を保持するように取り計らう。
【０２１０】
いずれの場合でも、ＣＧＩバイナリは通常、Ａｐａｃｈｅウェブサーバのｃｇｉ−ｂｉｎディレクトリに置かれる。ディスクスペースが問題ではない場合には、前者の手法がより強力であり、うまくいく。後者の方法は、厳密にどのバイナリを外部に向けられたｏｍａｉｌｏｕｔコンパートメントに配置するかを確実にする必要がある場合に使用することができる。最後に、両方のコンパートメントを開始することができる。
【０２１１】
root@tlinux# comp_start omailout omailin
異なる発信元コンパートメント番号を有するＩＰフラグメントを受け取る場合もあり得る。かかる場合、システムは、フラグメントの再アセンブリが、コンパートメント番号の異なるフラグメントを続行するのを許可しない手段を備えることができる。
【０２１２】
他の様々なネットワークプロトコル、たとえばＩＰＸ／ＳＰＸ等へのサポートも含むことができる。
【０２１３】
ｃｈｒｏｏｔ−ｊａｉｌよりも包括的なファイルシステム保護方法を使用し得るものと考えられる。
【０２１４】
図面の図１３を参照して、本発明の第１の同時係属中の国際出願の発明の例示的な実施形態の動作を模式的に示す。ゲートウェイシステム６００（内部および外部ネットワークの両方に接続された）を示す。ゲートウェイシステム６００は、複数のタイプのサービス：サービス０、サービス１、・・・、サービスＮをホストしており、各サービスは指定されたあるバックエンドホスト、すなわちホスト０、ホスト１、・・・、ホストＸ、ホストＮに接続され、その機能、たとえばバックエンドデータベースからの記録検索を行う。多くのバックエンドホストが、随時内部ネットワークに存在してよい（すべてのバックエンドホストが同じサービスセットによりアクセス可能であるわけではないよう意図される）。これらサーバプロセスが不正侵入されても、不正侵入されたサーバプロセスを使用して、サービスによる使用を当初意図されていない他のバックエンドホストをプロービングすることはできないはずである。本発明の第１の同時係属中の国際出願の発明の態様は、同じネットワーク上のホストの可視性を制限することにより、攻撃者が与え得る損害を制限するよう意図される。
【０２１５】
図１３では、サービス０およびサービス１のみが、ネットワークインタフェースｅｔｈ０を通してネットワークサブネット１にアクセス許可されている。したがって、ホスト０／ホスト１がサブネット１であるため、ホスト０／ホスト１にアクセスする試みは成功するが、ｅｔｈ１を介してサブネット２にアクセスする試みは失敗する。さらに、サービスＮは、ｅｔｈ１上のホストＸのみへのアクセスが許可されている。このため、ホストＮがホストＸと同じサブネット上にあってもサービスＮによるホストＮへのアクセス試行はいずれも失敗し、また、サービスＮによるサブネット１上のあらゆるホストへのアクセス試行は失敗する。
【０２１６】
制限は、（規則またはルーティングテーブルにより）サブネットまたは特定のホストによって指定することができ、同様に、特定のサブネットによっても限定することができる。
【０２１７】
図面の図１４を参照して、本発明の第４の態様の例示的な実施形態によるオペレーティングシステムの動作を模式的に示す。本発明のこの態様の例示的な実施形態の主な好ましい特徴は、以下である。
【０２１８】
１．ｒｏｏｔへの移行が可能なエリアにおけるオペレーティングシステムのソースコードに対する変更。フックがこれらポイントに追加され、フックにより、実行時に、遷移の実行を許可あるいは拒絶する関数をコールアウトする。
【０２１９】
２．各実行中プロセスにタグをマークするという、オペレーティングシステムのソースコードに対する変更。上に述べたように、生成されるプロセスは、それぞれのタグをそれぞれの親プロセスから継承する。特別な特権プログラムが、それ自体のタグとは異なるタグを有する外部プログラムを起動することができる（異なるタグを有するプロセスでシステムを埋めるための手段）
３．構成ユーティリティが、特定のタグに関連するいずれのプロセスに「封印」とマークすべきかを実行時にオペレーティングシステムに対して指定することができるようにする機構
４．上記構成ユーティリティに渡すべきデータを記述する構成ファイル
したがって、本発明は、ファイルまたはプログラムにアクセスするときにアクセスされないパスベースの規則仕様を使用して、機能が主にカーネルレベルで提供される高信頼性オペレーティングシステム、特にＬｉｎｕｘベースの高信頼性オペレーティングシステムを提供する。これは、ディスクに格納されているプログラムまたはファイルではなく実行中のプロセスにおいてあらゆる管理特権を推論することによって実現される。かかる特権は、アクティブ化されると管理タグまたはラベルの継承により付与されるため、組み込まれたセキュリティ属性のためにストリームまたはパケットを後に復号化する必要はない。これは、ストリームまたはパケットがそれぞれのセキュリティ属性に従って異なるパスに沿って再ルーティングされないためである。
【０２２０】
Ｌｉｎｕｘの機能には、ユーザ空間における高信頼性アプリケーションを必要とすることなくアクセス可能であり、実行中プログラムのセキュリティレベルのアップグレード、ダウングレード、もしくは変更は必要ない。
【０２２１】
本発明の実施形態について例としてのみ上述したが、特許請求の範囲に規定される本発明の範囲から逸脱することなく、変更および変形を上記実施形態に行うことができることが当業者には明白であろう。
【図面の簡単な説明】
【０２２２】
【図１】コンテインメントプロパティを有するオペレーティングシステム上でマルチサービスホストとして機能するための例示的なアーキテクチャの模式図である。
【図２】本発明の例示的な実施形態による高信頼性Ｌｉｎｕｘホストオペレーティングシステムのアーキテクチャの模式図である。
【図３】図２に示すオペレーティングシステムにおいて使用される例示的な変更データ型を示す。
【図４】ＬｉｎｕｘＩＰネットワーキングにおける主なネットワーキングデータ型を示す。
【図５】ＩＰネットワーキングのｓｔｒｕｃｔ ｃｓｅｃｉｎｆｏデータメンバの伝搬を示す。
【図６】コンテインメントをＬｉｎｕｘカーネルに構築する例示的な３つの手法を模式的に示す。
【図７】規則：ＨＯＳＴ＊−＞ＣＯＭＰＡＲＴＭＥＮＴｘＭＥＴＨＯＤ ＴＣＰ ＰＯＲＴ８０の影響を模式的に示す。
【図８】ハイブリッドコンテインメントプロトタイプオペレーティングシステムの構築に利用可能な多様なオプションを模式的に示す。
【図９】複製したカーネル状態を同期して更新することの望ましさを模式的に示す。
【図１０】Ａｐａｃｈｅおよび２つのＴｏｍｃａｔ Ｊａｖａ Ｖｍの例示的な構成を模式的に示す。
【図１１】図２に示す高信頼性Ｌｉｎｕｘにおけるｃｈｒｏｏｔ化された層状の環境を模式的に示す。
【図１２】カーネル強制コンパートメントアクセス制御規則の効率的な参照プロセスを模式的に示す。
【図１３】本発明の一態様による高信頼性ゲートウェイシステムの例示的な実施形態を模式的に示す。
【図１４】本発明の一態様の例示的な実施形態によるオペレーティングシステムの動作を模式的に示す。
【図１５】従来技術によるオペレーティングシステムの例示的な実施形態を模式的に示す。
Claims (27)
- 複数のアプリケーションをサポートするオペレーティングシステムであって、前記アプリケーションの少なくともいくつかにはラベルまたはタグが提供され、該ラベルまたはタグはそれぞれ該システムの論理的に保護されたコンピュータ処理コンパートメントを示し、同じラベルまたはタグを有するアプリケーションはそれぞれ同じコンパートメントに属し、該オペレーティングシステムは、前記コンパートメント間に１つまたは複数の通信経路を定義し、通信経路が間に定義されないコンパートメント間の通信を阻止するオペレーティングシステム。
- 前記コンパートメント間に前記１つまたは複数の通信経路を定義し、通信経路が間に定義されていないコンパートメント間の通信を阻止するカーネルを備える請求項１記載のオペレーティングシステム。
- 複数のアプリケーションをサポートするオペレーティングシステムであって、複数のアクセス制御規則をさらに備え、該複数のアクセス制御規則は、前記オペレーティングシステムのカーネルによって実施され、選択された前記アプリケーション間の通信インタフェースまたは経路のみを定義するオペレーティングシステム。
- 前記アクセス制御規則は、ユーザ空間から追加することができる請求項３記載のオペレーティングシステム。
- 前記アクセス制御規則は、該オペレーティングシステムにとってローカルな、選択されたアプリケーション間の通信インタフェースまたは経路のみを定義する請求項３記載のオペレーティングシステム。
- 前記アクセス制御規則は、該オペレーティングシステムからリモートな、選択されたアプリケーション間の通信インタフェースまたは経路のみを定義する請求項３または５記載のオペレーティングシステム。
- 前記アプリケーションの少なくともいくつかにはラベルまたはタグが提供され、該ラベルまたはタグはそれぞれ該システムのコンパートメントを示す請求項３記載のオペレーティングシステム。
- 強制セキュリティチェックを行って、あるコンパートメントからのプロセスが別のコンパートメントからのプロセスに干渉することができないように保証する請求項７記載のオペレーティングシステム。
- ファイルシステムを備え、該ファイルシステムは少なくとも部分的にセクションに分割され、該セクションはそれぞれ、前記メインファイルシステムの限定された部分集合であり、各コンパートメントに関連する請求項７記載のオペレーティングシステム。
- 前記コンパートメントそれぞれで実行されているアプリケーションは、前記ファイルシステムの関連セクションにしかアクセスすることができない請求項９記載のオペレーティングシステム。
- プロセスがそのコンパートメント内からｒｏｏｔに移行することを阻止し、それによって前記限られた部分集合からエスケープできないようにする請求項１０記載のオペレーティングシステム。
- 限られた部分集合内の選択されたファイルを変更不可にするように構成される請求項１０または１１記載のオペレーティングシステム。
- 前記１つまたは複数の通信経路は、１つまたは複数の規則によって統制される請求項３記載のオペレーティングシステム。
- 前記１つまたは複数の通信インタフェースまたは経路は、１つまたは複数の規則によって統制される請求項７記載のオペレーティングシステム。
- 前記規則は、ユーザ空間から規定・追加される請求項１４記載のオペレーティングシステム。
- 前記規則はコンパートメント単位で追加される請求項１４または１５記載のオペレーティングシステム。
- 前記規則は、あるコンパートメントと他のコンパートメントまたはホストとの間の許可アクセスを指定し、該オペレーティングシステムの前記カーネルによって実施される請求項１４記載のオペレーティングシステム。
- 前記オペレーティングシステムに規定される規則は追加することができる請求項１４記載のオペレーティングシステム。
- 前記オペレーティングシステムに規定される規則は削除することができる請求項１４記載のオペレーティングシステム。
- 前記オペレーティングシステムに規定される規則はリスト化することができる請求項１４記載のオペレーティングシステム。
- 前記規則はカーネルレベルのデータベースに格納される請求項１４記載のオペレーティングシステム。
- 前記カーネルレベルのデータベースは２つのハッシュテーブルから構成され、該テーブルの一方は前記規則の発信元アドレス詳細に焦点をあて、他方は前記規則の宛先アドレス詳細に焦点をあてたものである請求項２１記載のオペレーティングシステム。
- 複数のアプリケーションをサポートするオペレーティングシステムであって、前記アプリケーション間の許可通信経路を定義する複数の規則が格納されたデータベースを備え、前記規則は少なくとも２つの符号化テーブル、すなわち前記規則の発信元詳細に焦点をあてた第１のテーブルおよび前記規則の宛先詳細に焦点をあてた第２のテーブルの形態で格納され、該システムは、システムコールに応答して、要求された通信経路を定義する規則があるかどうかについて前記テーブルの少なくとも一方をチェックし、前記要求された通信経路が定義されている場合にのみ前記システムコールの続行を許可する部分をさらに含むオペレーティングシステム。
- 前記符号化テーブルは、少なくとも１つのハッシュテーブルを含む請求項２３記載のオペレーティングシステム。
- 複数のアプリケーションをサポートするオペレーティングシステムであって、
前記アプリケーションの少なくともいくつかにタグまたはラベルを提供し、該タグまたはラベルは、アプリケーションが要求に応答してｒｏｏｔに移行することが許可されているか否かを示し、
かかる要求を識別し、
そのタグまたはラベルから、アプリケーションのｒｏｏｔへの移行が許可されているか否かを判定し、
該判定に応じて前記移行を許可または拒絶するオペレーティングシステム。 - システムオブジェクト間の許可された通信経路を定義する１つまたは複数の規則からなる規則ベースを格納するカーネルと、かかる規則の追加、削除、および／またはリスト化を行うためのユーザ操作可能インタフェースとを備えるオペレーティングシステム。
- ２つのエントリポイントを該オペレーティングシステムの前記カーネルに提供するカーネルデバイスドライバを備え、第１のエントリポイントは規則の追加および／または削除規則のためのものであり、第２のエントリポイントはカーネルによって生成された規則のリストを読み出すためのものである請求項２６記載のオペレーティングシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0102518.8A GB0102518D0 (en) | 2001-01-31 | 2001-01-31 | Trusted operating system |
| PCT/GB2002/000419 WO2002061554A1 (en) | 2001-01-31 | 2002-01-29 | Trusted operating system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004529408A true JP2004529408A (ja) | 2004-09-24 |
Family
ID=9907905
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002562063A Pending JP2004529408A (ja) | 2001-01-31 | 2002-01-29 | 高信頼性オペレーティングシステム |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20030172109A1 (ja) |
| EP (1) | EP1362277A1 (ja) |
| JP (1) | JP2004529408A (ja) |
| GB (1) | GB0102518D0 (ja) |
| WO (1) | WO2002061554A1 (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006059639A1 (ja) * | 2004-11-30 | 2006-06-08 | Nec Corporation | 情報共有システム、情報共有方法、グループ管理プログラム及びコンパートメント管理プログラム |
| JP2009509273A (ja) * | 2005-09-22 | 2009-03-05 | モカナ・コーポレーション | 組み込みパッチの管理 |
| JP2010092465A (ja) * | 2008-10-06 | 2010-04-22 | Internatl Business Mach Corp <Ibm> | ハードウェア・ベースの強制アクセス制御 |
| JP2015507896A (ja) * | 2012-12-18 | 2015-03-12 | ▲華▼▲為▼▲終▼端有限公司 | ＷｉＦｉ装置に対するアクセス制御方法およびＷｉＦｉ装置 |
| US9467932B2 (en) | 2012-12-18 | 2016-10-11 | Huawei Device Co., Ltd. | Access control method for WiFi device and WiFi device |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020178248A1 (en) * | 2000-10-26 | 2002-11-28 | Metilinx | Application program interface for optimization integration model |
| US7962950B2 (en) * | 2001-06-29 | 2011-06-14 | Hewlett-Packard Development Company, L.P. | System and method for file system mandatory access control |
| GB2415530B (en) * | 2001-06-29 | 2006-02-15 | Hewlett Packard Co | System and method for file system mandatory access control |
| US20030014466A1 (en) * | 2001-06-29 | 2003-01-16 | Joubert Berger | System and method for management of compartments in a trusted operating system |
| GB2410352B (en) * | 2001-06-29 | 2005-12-21 | Hewlett Packard Co | System and method for management of compartments in a trusted operating system |
| JP2004126854A (ja) * | 2002-10-01 | 2004-04-22 | Mitsubishi Electric Corp | 攻撃対策装置 |
| US7613836B2 (en) * | 2002-10-04 | 2009-11-03 | Starent Networks Corporation | Managing resources for IP networking |
| US20040193703A1 (en) * | 2003-01-10 | 2004-09-30 | Guy Loewy | System and method for conformance and governance in a service oriented architecture |
| US7437556B2 (en) | 2003-05-09 | 2008-10-14 | Sun Microsystems, Inc. | Global visibility controls for operating system partitions |
| US7389512B2 (en) * | 2003-05-09 | 2008-06-17 | Sun Microsystems, Inc. | Interprocess communication within operating system partitions |
| US8892878B2 (en) | 2003-05-09 | 2014-11-18 | Oracle America, Inc. | Fine-grained privileges in operating system partitions |
| US20050010752A1 (en) * | 2003-06-23 | 2005-01-13 | Nokia, Inc. | Method and system for operating system anti-tampering |
| US20050091658A1 (en) * | 2003-10-24 | 2005-04-28 | Microsoft Corporation | Operating system resource protection |
| US20050091535A1 (en) * | 2003-10-24 | 2005-04-28 | Microsoft Corporation | Application identity for software products |
| US7784063B2 (en) * | 2004-01-09 | 2010-08-24 | Hewlett-Packard Development Company, L.P. | Method and apparatus for system caller authentication |
| US7587594B1 (en) | 2004-08-30 | 2009-09-08 | Microsoft Corporation | Dynamic out-of-process software components isolation for trustworthiness execution |
| JP4327698B2 (ja) * | 2004-10-19 | 2009-09-09 | 富士通株式会社 | ネットワーク型ウィルス活動検出プログラム、処理方法およびシステム |
| US20070073858A1 (en) * | 2005-09-27 | 2007-03-29 | Nokia Corporation | Security of virtual computing platforms |
| US7739731B2 (en) * | 2006-01-09 | 2010-06-15 | Oracle America, Inc. | Method and apparatus for protection domain based security |
| US7882227B2 (en) * | 2006-02-23 | 2011-02-01 | Oracle America, Inc. | Mechanism for implementing file access control across a network using labeled containers |
| US20070204167A1 (en) * | 2006-02-28 | 2007-08-30 | Aladdin Knowledge Systems Ltd. | Method for serving a plurality of applications by a security token |
| US7821985B2 (en) * | 2006-03-13 | 2010-10-26 | Microsoft Corporation | Network interface routing using computational context |
| US8028908B2 (en) * | 2006-05-01 | 2011-10-04 | Patrick Shomo | Systems and methods for the secure control of data within heterogeneous systems and networks |
| US7831960B2 (en) * | 2006-06-08 | 2010-11-09 | Oracle America, Inc. | Configuration tool with multi-level priority semantic |
| WO2008018055A2 (en) * | 2006-08-09 | 2008-02-14 | Neocleus Ltd | Extranet security |
| US8087065B2 (en) | 2006-11-17 | 2011-12-27 | Mcafee, Inc. | Method and system for implementing mandatory file access control in native discretionary access control environments |
| US8443188B2 (en) * | 2006-11-30 | 2013-05-14 | Microsoft Corporation | Using code access security for runtime accessibility checks |
| WO2008114257A2 (en) * | 2007-03-21 | 2008-09-25 | Neocleus Ltd. | Protection against impersonation attacks |
| WO2008114256A2 (en) * | 2007-03-22 | 2008-09-25 | Neocleus Ltd. | Trusted local single sign-on |
| US8266685B2 (en) * | 2007-05-18 | 2012-09-11 | Microsoft Corporation | Firewall installer |
| US7895435B2 (en) * | 2007-05-21 | 2011-02-22 | International Business Machines Corporation | Framework for managing attributes of objects |
| US8719830B2 (en) * | 2007-12-10 | 2014-05-06 | Hewlett-Packard Development Company, L.P. | System and method for allowing executing application in compartment that allow access to resources |
| US8474037B2 (en) * | 2008-01-07 | 2013-06-25 | Intel Corporation | Stateless attestation system |
| US8675551B2 (en) * | 2008-03-31 | 2014-03-18 | Futurewei Technologies, Inc. | Multi-protocol label switching support for proxy mobile internet protocol version 6 |
| US9418219B2 (en) * | 2008-04-11 | 2016-08-16 | Microsoft Technology Licensing, Llc | Inter-process message security |
| KR101294816B1 (ko) * | 2008-05-29 | 2013-08-08 | 엘지전자 주식회사 | 제어신호 암호화 방법 |
| EP2286333A4 (en) * | 2008-06-05 | 2012-08-08 | Neocleus Israel Ltd | SAFE MULTIPURPOSE COMPUTER CLIENT |
| US8312043B2 (en) * | 2008-11-26 | 2012-11-13 | Red Hat, Inc. | Isolating an execution container in a system with mandatory access control (MAC) |
| US8479256B2 (en) * | 2008-11-26 | 2013-07-02 | Red Hat, Inc. | Merging mandatory access control (MAC) policies in a system with multiple execution containers |
| US9767273B2 (en) * | 2008-11-26 | 2017-09-19 | Red Hat, Inc. | Reliably terminating processes in a system with confined execution environments |
| US8627451B2 (en) * | 2009-08-21 | 2014-01-07 | Red Hat, Inc. | Systems and methods for providing an isolated execution environment for accessing untrusted content |
| US9684785B2 (en) * | 2009-12-17 | 2017-06-20 | Red Hat, Inc. | Providing multiple isolated execution environments for securely accessing untrusted content |
| US20110154364A1 (en) * | 2009-12-22 | 2011-06-23 | International Business Machines Corporation | Security system to protect system services based on user defined policies |
| US8495750B2 (en) | 2010-08-31 | 2013-07-23 | International Business Machines Corporation | Filesystem management and security system |
| US9135265B2 (en) * | 2010-09-09 | 2015-09-15 | Red Hat, Inc. | Asynchronous verification for extended file attributes |
| US9027151B2 (en) | 2011-02-17 | 2015-05-05 | Red Hat, Inc. | Inhibiting denial-of-service attacks using group controls |
| US9094830B2 (en) * | 2012-07-05 | 2015-07-28 | Blackberry Limited | Managing data transfer across a network interface |
| WO2014111922A1 (en) * | 2013-01-21 | 2014-07-24 | B.G. Negev Technologies And Applications Ltd. | Method and system for protecting computerized systems from malicious code |
| US9189149B2 (en) * | 2013-03-21 | 2015-11-17 | Sharp Laboratories Of America, Inc. | Equivalent gesture and soft button configuration for touch screen enabled device |
| US10452850B2 (en) | 2014-08-18 | 2019-10-22 | International Business Machines Corporation | Protected shell for risk validation |
| US9954873B2 (en) * | 2015-09-30 | 2018-04-24 | The Mitre Corporation | Mobile device-based intrusion prevention system |
| US10936713B2 (en) * | 2015-12-17 | 2021-03-02 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US10235176B2 (en) | 2015-12-17 | 2019-03-19 | The Charles Stark Draper Laboratory, Inc. | Techniques for metadata processing |
| US10127091B1 (en) * | 2016-12-22 | 2018-11-13 | Juniper Networks, Inc. | Intercepting socket metadata |
| CN107193590A (zh) * | 2017-05-10 | 2017-09-22 | 北京海杭通讯科技有限公司 | 一种基于android的防root方法 |
| CN109753347B (zh) * | 2017-11-06 | 2023-03-21 | 阿里巴巴集团控股有限公司 | 一种实现驱动的系统及方法 |
| SG11202007272QA (en) | 2018-02-02 | 2020-08-28 | Charles Stark Draper Laboratory Inc | Systems and methods for policy execution processing |
| WO2019152792A1 (en) | 2018-02-02 | 2019-08-08 | Dover Microsystems, Inc. | Systems and methods for policy linking and/or loading for secure initialization |
| EP3788488A1 (en) | 2018-04-30 | 2021-03-10 | Dover Microsystems, Inc. | Systems and methods for checking safety properties |
| TW202022678A (zh) | 2018-11-06 | 2020-06-16 | 美商多佛微系統公司 | 用於停滯主處理器的系統和方法 |
| WO2020132012A1 (en) | 2018-12-18 | 2020-06-25 | Dover Microsystems, Inc. | Systems and methods for data lifecycle protection |
| US11880483B2 (en) * | 2021-12-03 | 2024-01-23 | Amazon Technologies, Inc. | Authorizing access to database system resources using security policies managed by a service external to the database system |
| US11943261B1 (en) | 2021-12-03 | 2024-03-26 | Amazon Technologies, Inc. | Cloud-based security service for improved compliance of mainframe workloads |
Family Cites Families (79)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4747040A (en) * | 1985-10-09 | 1988-05-24 | American Telephone & Telegraph Company | Dual operating system computer |
| US5038281A (en) * | 1986-09-19 | 1991-08-06 | International Business Machines Corporation | Acceleration of system interrupts between operating systems in guest-host relationship |
| US4984272A (en) * | 1988-11-30 | 1991-01-08 | At&T Bell Laboratories | Secure file handling in a computer operating system |
| US4962533A (en) * | 1989-02-17 | 1990-10-09 | Texas Instrument Incorporated | Data protection for computer systems |
| US5278973A (en) * | 1989-03-27 | 1994-01-11 | Unisys Corporation | Dual operating system computer |
| US5029206A (en) * | 1989-12-27 | 1991-07-02 | Motorola, Inc. | Uniform interface for cryptographic services |
| US5261104A (en) * | 1990-03-22 | 1993-11-09 | International Business Machines | Flexible computer initialization |
| US5325529A (en) * | 1990-05-18 | 1994-06-28 | Compaq Computer Corporation | External boot information loading of a personal computer |
| US5032979A (en) * | 1990-06-22 | 1991-07-16 | International Business Machines Corporation | Distributed security auditing subsystem for an operating system |
| US5136711A (en) * | 1990-10-17 | 1992-08-04 | Ast Research | System for multiple access hard disk partitioning |
| US5414860A (en) * | 1991-01-29 | 1995-05-09 | International Business Machines Incorporated | Power management initialization for a computer operable under a plurality of operating systems |
| JPH06214670A (ja) * | 1991-04-29 | 1994-08-05 | Intel Corp | コンピュータ装置およびそれを初期化する方法 |
| US5694590A (en) * | 1991-09-27 | 1997-12-02 | The Mitre Corporation | Apparatus and method for the detection of security violations in multilevel secure databases |
| JPH0736175B2 (ja) * | 1991-10-11 | 1995-04-19 | インターナショナル・ビジネス・マシーンズ・コーポレイション | データ処理システムのシステム構成設定方法、データ処理システム、及びデータ処理システム用拡張ユニット |
| AU3777593A (en) * | 1992-02-26 | 1993-09-13 | Paul C. Clark | System for protecting computers via intelligent tokens or smart cards |
| JP2986299B2 (ja) * | 1992-04-15 | 1999-12-06 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 周辺装置接続検出システム |
| US5421006A (en) * | 1992-05-07 | 1995-05-30 | Compaq Computer Corp. | Method and apparatus for assessing integrity of computer system software |
| US5361359A (en) * | 1992-08-31 | 1994-11-01 | Trusted Information Systems, Inc. | System and method for controlling the use of a computer |
| US5379342A (en) * | 1993-01-07 | 1995-01-03 | International Business Machines Corp. | Method and apparatus for providing enhanced data verification in a computer system |
| US5497494A (en) * | 1993-07-23 | 1996-03-05 | International Business Machines Corporation | Method for saving and restoring the state of a CPU executing code in protected mode |
| US5548763A (en) * | 1993-07-26 | 1996-08-20 | International Business Machines Corporation | Desk top computer system having multi-level power management |
| US5444850A (en) * | 1993-08-04 | 1995-08-22 | Trend Micro Devices Incorporated | Method and apparatus for controlling network and workstation access prior to workstation boot |
| US5680452A (en) * | 1993-10-18 | 1997-10-21 | Tecsec Inc. | Distributed cryptographic object method |
| US5504910A (en) * | 1994-02-02 | 1996-04-02 | Advanced Micro Devices, Inc. | Power management unit including software configurable state register and time-out counters for protecting against misbehaved software |
| GB9408405D0 (en) * | 1994-04-28 | 1994-06-22 | Int Computers Ltd | High availibilty computer system |
| US5483649A (en) * | 1994-07-01 | 1996-01-09 | Ybm Technologies, Inc. | Personal computer security system |
| US5495569A (en) * | 1994-12-30 | 1996-02-27 | Compaq Computer Corp. | Circuit for ensuring that a local interrupt controller in a microprocessor is powered up active |
| US5555373A (en) * | 1995-02-06 | 1996-09-10 | International Business Machines Corporation | Inactivity monitor for trusted personal computer system |
| JP3262689B2 (ja) * | 1995-05-19 | 2002-03-04 | 富士通株式会社 | 遠隔操作システム |
| US5787175A (en) * | 1995-10-23 | 1998-07-28 | Novell, Inc. | Method and apparatus for collaborative document control |
| US5815665A (en) * | 1996-04-03 | 1998-09-29 | Microsoft Corporation | System and method for providing trusted brokering services over a distributed network |
| KR100198382B1 (ko) * | 1996-05-07 | 1999-06-15 | 윤종용 | 멀티-부팅 기능을 갖는 컴퓨터 장치 |
| US5809145A (en) * | 1996-06-28 | 1998-09-15 | Paradata Systems Inc. | System for distributing digital information |
| US5903732A (en) * | 1996-07-03 | 1999-05-11 | Hewlett-Packard Company | Trusted gateway agent for web server programs |
| US5867646A (en) * | 1996-07-12 | 1999-02-02 | Microsoft Corporation | Providing secure access for multiple processes having separate directories |
| US5692124A (en) * | 1996-08-30 | 1997-11-25 | Itt Industries, Inc. | Support of limited write downs through trustworthy predictions in multilevel security of computer network communications |
| US5889989A (en) * | 1996-09-16 | 1999-03-30 | The Research Foundation Of State University Of New York | Load sharing controller for optimizing monetary cost |
| US6519623B1 (en) * | 1996-10-31 | 2003-02-11 | International Business Machines Corporation | Generic semaphore for concurrent access by multiple operating systems |
| US6023765A (en) * | 1996-12-06 | 2000-02-08 | The United States Of America As Represented By The Secretary Of Commerce | Implementation of role-based access control in multi-level secure systems |
| US5845068A (en) * | 1996-12-18 | 1998-12-01 | Sun Microsystems, Inc. | Multilevel security port methods, apparatuses, and computer program products |
| US6292900B1 (en) * | 1996-12-18 | 2001-09-18 | Sun Microsystems, Inc. | Multilevel security attribute passing methods, apparatuses, and computer program products in a stream |
| DE69734968T2 (de) * | 1996-12-20 | 2006-07-27 | International Business Machines Corp. | Vermittlungssystem mit verteilten Elementen zur Verbindung mit Leitungsanpassern und mit Mehrfachübertragungsmöglichkeit |
| US5922074A (en) * | 1997-02-28 | 1999-07-13 | Xcert Software, Inc. | Method of and apparatus for providing secure distributed directory services and public key infrastructure |
| US5887163A (en) * | 1997-04-04 | 1999-03-23 | Compaq Computer Corporation | Method and apparatus for providing dual booting capabilities to a computer system |
| US5987608A (en) * | 1997-05-13 | 1999-11-16 | Netscape Communications Corporation | Java security mechanism |
| US6275848B1 (en) * | 1997-05-21 | 2001-08-14 | International Business Machines Corp. | Method and apparatus for automated referencing of electronic information |
| US6272631B1 (en) * | 1997-06-30 | 2001-08-07 | Microsoft Corporation | Protected storage of core data secrets |
| US6304970B1 (en) * | 1997-09-02 | 2001-10-16 | International Business Mcahines Corporation | Hardware access control locking |
| US6081830A (en) * | 1997-10-09 | 2000-06-27 | Gateway 2000, Inc. | Automatic linking to program-specific computer chat rooms |
| US6078948A (en) * | 1998-02-03 | 2000-06-20 | Syracuse University | Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions |
| US5987605A (en) * | 1998-02-28 | 1999-11-16 | Hewlett-Packard Co. | Methods and apparatus for dual-boot memory selection, update, and recovery in a programmable device |
| US6360282B1 (en) * | 1998-03-25 | 2002-03-19 | Network Appliance, Inc. | Protected control of devices by user applications in multiprogramming environments |
| US6446206B1 (en) * | 1998-04-01 | 2002-09-03 | Microsoft Corporation | Method and system for access control of a message queue |
| US6067559A (en) * | 1998-04-23 | 2000-05-23 | Microsoft Corporation | Server architecture for segregation of dynamic content generation applications into separate process spaces |
| US6175917B1 (en) * | 1998-04-23 | 2001-01-16 | Vpnet Technologies, Inc. | Method and apparatus for swapping a computer operating system |
| US6496847B1 (en) * | 1998-05-15 | 2002-12-17 | Vmware, Inc. | System and method for virtualizing computer systems |
| US6505300B2 (en) * | 1998-06-12 | 2003-01-07 | Microsoft Corporation | Method and system for secure running of untrusted content |
| WO2000019324A1 (en) * | 1998-09-28 | 2000-04-06 | Argus Systems Group, Inc. | Trusted compartmentalized computer operating system |
| US6308264B1 (en) * | 1998-09-30 | 2001-10-23 | Phoenix Technologies Ltd. | Dual use master boot record |
| US6330670B1 (en) * | 1998-10-26 | 2001-12-11 | Microsoft Corporation | Digital rights management operating system |
| US6327652B1 (en) * | 1998-10-26 | 2001-12-04 | Microsoft Corporation | Loading and identifying a digital rights management operating system |
| US6393556B1 (en) * | 1998-10-30 | 2002-05-21 | Intel Corporation | Apparatus and method to change processor privilege without pipeline flush |
| US6138239A (en) * | 1998-11-13 | 2000-10-24 | N★Able Technologies, Inc. | Method and system for authenticating and utilizing secure resources in a computer system |
| US6530024B1 (en) * | 1998-11-20 | 2003-03-04 | Centrax Corporation | Adaptive feedback security system and method |
| US6330669B1 (en) * | 1998-11-30 | 2001-12-11 | Micron Technology, Inc. | OS multi boot integrator |
| US20030191957A1 (en) * | 1999-02-19 | 2003-10-09 | Ari Hypponen | Distributed computer virus detection and scanning |
| US6948069B1 (en) * | 1999-07-02 | 2005-09-20 | Time Certain, Llc | Method and system for determining and maintaining trust in digital image files with certifiable time |
| US6892307B1 (en) * | 1999-08-05 | 2005-05-10 | Sun Microsystems, Inc. | Single sign-on framework with trust-level mapping to authentication requirements |
| US6487601B1 (en) * | 1999-09-30 | 2002-11-26 | International Business Machines Corporation | Dynamic mac allocation and configuration |
| US6757824B1 (en) * | 1999-12-10 | 2004-06-29 | Microsoft Corporation | Client-side boot domains and boot rules |
| US20010047473A1 (en) * | 2000-02-03 | 2001-11-29 | Realtime Data, Llc | Systems and methods for computer initialization |
| US6681304B1 (en) * | 2000-06-30 | 2004-01-20 | Intel Corporation | Method and device for providing hidden storage in non-volatile memory |
| GB0020441D0 (en) * | 2000-08-18 | 2000-10-04 | Hewlett Packard Co | Performance of a service on a computing platform |
| JP2002182614A (ja) * | 2000-12-11 | 2002-06-26 | Seiko Epson Corp | 半導体装置 |
| GB0102515D0 (en) * | 2001-01-31 | 2001-03-21 | Hewlett Packard Co | Network adapter management |
| US20030014466A1 (en) * | 2001-06-29 | 2003-01-16 | Joubert Berger | System and method for management of compartments in a trusted operating system |
| US6846894B2 (en) * | 2001-07-31 | 2005-01-25 | Mitsui Takeda Chemicals, Inc. | Laminate adhesive and usage thereof |
| WO2003029922A2 (en) * | 2001-10-01 | 2003-04-10 | Kline & Walker, Llc | Pfn/trac system faa upgrades for accountable remote and robotics control |
| US20030084436A1 (en) * | 2001-10-30 | 2003-05-01 | Joubert Berger | System and method for installing applications in a trusted environment |
-
2001
- 2001-01-31 GB GBGB0102518.8A patent/GB0102518D0/en not_active Ceased
-
2002
- 2002-01-29 WO PCT/GB2002/000419 patent/WO2002061554A1/en not_active Application Discontinuation
- 2002-01-29 US US10/240,137 patent/US20030172109A1/en not_active Abandoned
- 2002-01-29 EP EP02710135A patent/EP1362277A1/en not_active Ceased
- 2002-01-29 JP JP2002562063A patent/JP2004529408A/ja active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006059639A1 (ja) * | 2004-11-30 | 2006-06-08 | Nec Corporation | 情報共有システム、情報共有方法、グループ管理プログラム及びコンパートメント管理プログラム |
| US8656161B2 (en) | 2004-11-30 | 2014-02-18 | Nec Corporation | Information sharing system, information sharing method, group management program and compartment management program |
| JP2009509273A (ja) * | 2005-09-22 | 2009-03-05 | モカナ・コーポレーション | 組み込みパッチの管理 |
| JP2010092465A (ja) * | 2008-10-06 | 2010-04-22 | Internatl Business Mach Corp <Ibm> | ハードウェア・ベースの強制アクセス制御 |
| US10802990B2 (en) | 2008-10-06 | 2020-10-13 | International Business Machines Corporation | Hardware based mandatory access control |
| JP2015507896A (ja) * | 2012-12-18 | 2015-03-12 | ▲華▼▲為▼▲終▼端有限公司 | ＷｉＦｉ装置に対するアクセス制御方法およびＷｉＦｉ装置 |
| US9467932B2 (en) | 2012-12-18 | 2016-10-11 | Huawei Device Co., Ltd. | Access control method for WiFi device and WiFi device |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1362277A1 (en) | 2003-11-19 |
| US20030172109A1 (en) | 2003-09-11 |
| GB0102518D0 (en) | 2001-03-21 |
| WO2002061554A1 (en) | 2002-08-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004529408A (ja) | 高信頼性オペレーティングシステム | |
| JP2004530968A (ja) | ネットワークアダプタ管理 | |
| JP2004535611A (ja) | 高信頼性ゲートウェイシステム | |
| US20030014466A1 (en) | System and method for management of compartments in a trusted operating system | |
| US10191861B1 (en) | Technique for implementing memory views using a layered virtualization architecture | |
| US10846117B1 (en) | Technique for establishing secure communication between host and guest processes of a virtualization architecture | |
| US7464408B1 (en) | Damage containment by translation | |
| US8555404B1 (en) | Connectivity-based authorization | |
| US8972981B2 (en) | Implementing network traffic management for virtual and physical machines | |
| US20070006294A1 (en) | Secure flow control for a data flow in a computer and data flow in a computer network | |
| US20020065776A1 (en) | Method and process for virtualizing file system interfaces | |
| US11106800B1 (en) | Detecting kernel exploits | |
| US20020066022A1 (en) | System and method for securing an application for execution on a computer | |
| US20020092003A1 (en) | Method and process for the rewriting of binaries to intercept system calls in a secure execution environment | |
| Watson et al. | A taste of Capsicum: practical capabilities for UNIX | |
| US20020066021A1 (en) | Method and process for securing an application program to execute in a remote environment | |
| Chandramouli et al. | Security assurance requirements for linux application container deployments | |
| Dalton et al. | An operating system approach to securing e-services | |
| US20020065945A1 (en) | System and method for communicating and controlling the behavior of an application executing on a computer | |
| US20020065876A1 (en) | Method and process for the virtualization of system databases and stored information | |
| US20020065869A1 (en) | Method and process for virtualizing user interfaces | |
| US20080065840A1 (en) | Data processing system with data transmit capability | |
| Potter et al. | Secure Isolation of Untrusted Legacy Applications. | |
| Choo | Trusted linux: A secure platform for hosting compartmented applications | |
| US20020065874A1 (en) | Method and process for virtualizing network interfaces |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050117 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060912 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20061206 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20061213 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070508 |