JP2005531831A - 保護されたファイルシステムを有する移動体無線デバイス - Google Patents

Abstract

多数のルートディレクトリに区分されたファイルシステムでプログラムされた移動体無線デバイス。ファイルシステムの区分化は、プロセスがアクセスすべきでないあらゆるファイルを見るのを防ぐので、プロセスを囲うことである。信頼性のあるコンピューティング・ベースは、プロセスがルートのサブツリーにアクセスする権限又は能力を有しているか否かをチェックする。中にファイルが配置される特別なディレクトリは、様々なプロセスについてのアクセシビリティを自動的に決定する−すなわち、プロセスは特定のルートディレクトリ内にあるファイルだけにアクセスできる。この手法は負荷が軽い、なぜなら、プロセスがファイルについての自身のアクセス権を求めるために、そのファイルに関連したアクセス制御リストに問い合わせる必要が無い−ファイルの位置はプロセスのアクセス能力と共に、本質的にプロセスに対するファイルのアクセシビリティを定義している。本発明の別の態様では、各プロセスが、機密性と自身のデータの完全性を保証する、ファイルシステムの自身の専用領域を有していても良い。

Description

本発明は、保護されたファイルシステムを有する移動体無線デバイスに関する。該保護されたファイルシステムは、プラットフォーム・セキュリティ・アーキテクチャの要素をなす。

プラットフォームのセキュリティ（安全保証）は、考え方、アーキテクチャ及び悪意のある或いは誤って書かれたコードに対するプラットフォーム防御メカニズムに渡る。これら防御メカニズムは、そのようなコードが損害を生じさせるのを防止する。一般に悪意のあるコードは、損害を与える負荷メカニズムと、それが広がるのを助長する伝播メカニズムとの２つの構成要素を有している。それらは通常以下のように分類される。

トロイの木馬：悪意が無くユーザにとって魅力的な、正当なアプリケーションのように見せかける。
ワーム：その加害者又はユーザによる更なるマニュアル動作なしに複製し広がることができる。
ウィルス：正当なプログラムに侵入し、データを変更又は破壊する。

セキュリティに対する脅威は、（ａ）価値連鎖における機密性、完全性又はサービスやデータの有用性、及びサービスの完全性の潜在的な侵害と、（ｂ）サービス機能の低下とを含む。セキュリティの脅威は以下のカテゴリに分類される：
１．データの機密性及び完全性に対する脅威。例：ユーザのパスワードの入手；ファイルの改竄。
２．サービスの機密性及び完全性に対する脅威。例：使用料金を支払わない電話網加入者の帯域幅の使用；ネットワークサービスプロバイダとのデータ処理を拒絶する。
３．サービスの有用性に対する脅威（サービス拒否とも呼ばれる）。例：ユーザがテキストのメッセージを送信するのを阻む；ユーザが電話呼を受け付けるのを阻む。

従って、移動体無線デバイスは、非常に難しい課題をセキュリティ・アーキテクチャの設計者にもたらす。この課題の重要な側面は、悪意のあるアプリケーションが機密データ（例えば、ＰＩＮなど）を読み出すのを防止するため、及びファイルシステムの完全性を維持するために、ファイルシステムを有効に保護することである。しかしながら、今日まで、移動体無線デバイスのファイルシステムを保護する有効な提案はない。

本発明の第１の態様では、移動体無線デバイスが、複数のルートディレクトリで区分されており、ファイルの位置がそのアクセスポリシー（すなわち、どのプロセスがそのファイルにアクセスできるか）を十分に定義するように定められている、ファイルシステムでプログラムされる。この方法でのファイルシステムの区分化は、アクセスされてはならないものからあらゆるファイルが見られるのを防止するので、「囲い込み或いはケージング」プロセスと呼ぶ。（生来実行可能なコードを含むプログラムが一旦メモリにロードされると、それは「プロセス」となる；従ってプロセスは、ファイルシステム上に格納された、生来実行可能なコードを含むプログラムの実行中のメモリイメージである。）「信頼性のあるコンピューティング・ベース」（壊すことができず、デバイスの完全性を保証する構成要素をカバーするものと理解されたい；実施については詳細な説明のセクション１．１を参照せよ）のような信頼性のある構成要素は、ルートのサブツリー（例えば、サブディレクトリ内のファイル）にアクセスするために必要な特権又は「能力（capability）」（「能力」の説明については詳細な説明のセクション２を参照せよ）を、プロセスが有しているか否かを検証する。

上記のように、安全なオペレーティングシステムは、自身の完全性並びにユーザデータの機密性を保証するために、ファイルシステムへのアクセスを制御する必要がある。本発明によれば、中にファイルが設置される特定のディレクトリは、異なるプロセスについての自身のアクセシビリティ−すなわち、あるプロセスは特定のルートディレクトリ内のファイルだけにアクセスできる、を自動的に決定する。この手法は負荷が軽い、なぜなら、プロセスがファイルについての自身のアクセス権を求めるために、そのファイルに関連したアクセス制御リストに問い合わせる必要が無い−ファイルの位置はプロセスのアクセス能力と共に、本質的にプロセスに対するファイルのアクセシビリティを定義している。従って、ファイルシステム内でファイルの位置を（例えば、ルートディレクトリ間で）移動させると、そのファイルのアクセスポリシーを変更できる。

また、各プロセスが、機密性と自身のデータの完全性を保証する、ファイルシステムの自身の専用領域を有していても良い。

本発明の考えられる実施形態の１つ（以下、本明細書では実施形態Ａと呼ぶ）では、ファイルは４つのタイプのルートディレクトリ（或いはそれらの機能的等価物）、すなわち、
/system
/private/<process_secure_id>
/resources
/<others>
内に配置される。

/systemは、ルートのオペレーティングシステム特権又は能力（「能力」の概念については詳細な説明のセクション２で述べられている）が許可されたあらゆるプロセスによってアクセス可能である。'Root'又は'AllFiles'の能力が割り当てられたプロセスだけが/systemのサブツリー内にあるファイルを見ることができ、'Root'が割り当てられたプロセスだけがそれらを変更できる。

/private/<process_secure_id>は、process_secure_idに安全用識別子が割り当てられたあらゆるプロセス、並びに'Root'又は'AllFiles'の能力が許可されたプロセスによって利用可能である。プロセスのＳＩＤ（安全用識別子）は、ＯＳで実行可能であり関連する実行可能部分に格納されるコードの一部を一意に識別する方法である。この実行可能部分は/systemの下に格納され、ルートのオペレーティングシステム権限が無いとプロセスによって変更され得ない。プロセスがファイルにアクセスしようとするとき、システムサーバはそのＳＩＤ及びその権限をチェックして、アクセスを許可するか否認するか決定する。

/resourceは、一般に読み取り専用である；信頼性のあるコンピューティング・ベース（ＴＣＢ）だけが追加、削除、変更を行える。ある実施形態ではＴＣＢは、カーネル、ローダ、ファイルサーバ及びソフトウエア・インストーラを備えている。

/<others>は、ファイルの読み取り及び書き込み動作、ファイルの生成、並びに削除があらゆるプロセスで利用可能である。

別の実施形態では、既存のファイルシステムの完全性に悪影響を与えること（compromising）無しに、新たなアプリケーションとそれらのファイルとをインストールするのを受け持つ、ソフトウエア・インストーラでプログラムされている、「開いた」移動体無線デバイスが提供される。ファイルはそれらのタイプ、それらの位置（公のディレクトリ）及びプログラムの安全用識別子（ＳＩＤ）に従って生成又は更新される（詳細な説明の３．３を参照せよ）。

別の態様では、プログラムが別のプログラムの専用ディレクトリに悪影響を与えずに、それに寄与することを可能とする、ファイル・インストレーション・メカニズムを備えているオペレーティングシステムが提供される。

以下、本発明を、単一ユーザの無線デバイス用に設計された、オブジェクト指向のオペレーティング・システムであるシンビアンＯＳのセキュリティ・アーキテクチャを参照して説明する。シンビアンＯＳは、英国のロンドンにあるシンビアン リミテッドによって移動体無線デバイス用に開発された。

シンビアンＯＳのセキュリティ・アーキテクチャの基本的概要は、中世の城の防御と類似している。同様な方式で、該ＯＳはインストレーション周囲の上及び離れた位置に単純なジグザグ状のセキュリティ層を用いる。このモデルが対処しようとするキーとなる脅威は、ユーザデータ及びシステムサービス、より詳細には電話スタックへの未認証アクセスと結びついた脅威である。電話スタックは、電話網への恒久的な接続を制御するので、スマートフォンとの関連で特に重要である。このモデルの裏には２つのキーとなる設計を駆り立てるものがある：
・能力ベースのアクセス制御を用いたキーとなるシステムリソースのファイアウォールでの保護。
・標準的なソフトウエアがアクセスできない、ファイルシステムの保護された部分を生成するデータの区分化（partitioning）。

以下で説明する能力モデルの主要な概念は、ユーザができることではなくプロセスができることを制御することである。この手法はWindows NT（登録商標）やUnix（登録商標）のような周知のオペレーティング・システムとは極めて異なっている。その主な理由は：
−シンビアンＯＳは元々本質的に単一ユーザである。
−シンビアンＯＳは独立したサーバ・プロセスを通じてサービスを提供する。それらは常に実行されておりユーザセッションに伴わない。電力が供給されている限り、ログオンするユーザが居なくてもシンビアンＯＳは常に動作中である。
−シンビアンＯＳは技術的知識の無い大衆に使用されるデバイスで使用されるのを目的としている。ソフトウエアをインストールするとき、ユーザはアプリケーションに何を許可するのかを決定するスキルが無くてもよい。その上、常時接続のデバイスでは、誤った或いは悪意のある決定はデバイス自体よりも大きな領域に影響を与えるかもしれない。

１ 信頼性のあるコンピューティング・プラットフォーム
１．１ 信頼性のあるコンピューティング・ベース
信頼性のあるコンピューティング・ベース（ＴＣＢ）は、頑健なプラットフォーム・セキュリティについての基本的構成要件である。信頼性のあるコンピューティング・ベースは、壊すことができずデバイスの完全性を保証するいくつかの構成要素からなる。このベースをできるだけ小さく保つことと、システムサーバ及びアプリケーションが使用する必要のない特権を与えられなくてもよいのを保証すべく、最小特権の原則を適用することが重要である。閉じたデバイス上では、ＴＣＢはカーネル、ローダ及びファイルサーバからなり；開いたデバイス上ではソフトウエア・インストーラも必要となる。これら全てのプロセスはシステムに渡って信頼性があり、そのためデバイスに対してフルアクセスを有している。この信頼性のあるコアは、他のプラットフォーム・コードで利用できない「ルート」能力で実行される（セクション２．１を参照せよ）。

本発明の範囲外に、信頼性のあるコンピューティング・ベースの完全性を維持するのに重要な他の１つの構成要素、すなわち、ハードウエアがある。特に、信頼性のあるコンピューティング・ベース機能をフラッシュＲＯＭ内に保持するデバイスでは、信頼性のあるコンピューティング・ベースを悪意のあるＲＯＭイメージで壊すことができないのを保証すべく、安全なブートローダを提供する必要がある。

１．２ 信頼性のあるコンピューティング環境
コア以外の、他のシステムの構成要素が、限定された直交する（orthogonal）システム能力を与えられ、信頼性のあるコンピューティング環境（ＴＣＥ）を構成するであろう；それらには電話サーバ及びウインドウサーバのようなシステムサーバが含まれる。例えば、ウインドウサーバには電話スタックのアクセス能力は与えられず、電話サーバにはキーボード・イベントへの直接アクセス能力は与えられないであろう。これらの特権の何らかの誤用による損害の可能性を制限するために、ソフトウエア・コンポーネントに与えるシステム能力をできるだけ少なくすることを強く勧める。

ＴＣＥの各要素が１つのサービスの完全性を保証するので、ＴＣＢはシステム全体の完全性を保証する。ＴＣＥはＴＣＢなしには存在し得ないが、ＴＣＢはそれ自体で各プロセスに安全な「砂箱（ユーティティ機能：sand box）」を保証することで存在し得る。

２ プロセス能力
能力（capability）は、慎重に扱うべき動作に着手する許可に対応するアクセス・トークンとして考えられる。能力モデルの目的は、慎重に扱うべきシステムリソースへのアクセスを制御することである。アクセス制御を必要とする最も重要なリソースはカーネル管理（kernel executive）自体であり、クライアントがカーネルＡＰＩを通じて特定の機能にアクセスするにはシステム能力（セクション２．１を参照せよ）が必要とされる。他の全てのリソースは、ＩＰＣ（Inter Process Communication）を介してアクセスされるユーザ側のサーバにある。サーバ上でのクライアントの特定の動作を監視するためには、基本的能力の小さなセットが定義されるであろう。例えば、発呼能力の所有は、クライアントが電話サーバを使用するのを許可するであろう。能力が表すリソースへのクライアントのアクセスを監視するのは、対応するサーバが責任を持つであろう。能力はまた、各ライブラリ（ＤＬＬ）及びプログラム（ＥＸＥ）にも関連し、カーネルによって保持されるであろう実際のプロセス能力を生成するために実行時にローダによって組み合わされるであろう。開いたデバイスでは、サードパーティのソフトウエアには、それらのインストール用パッケージへのサインに使用される認証に基づいたソフトウエアのインストールの間、或いはソフトウエアのインストールの後にユーザによって、のいずれかで能力が割り当てられるであろう。能力の監視は、ローダ、カーネル及び影響を受けるサーバの間で管理されるが、ＩＰＣメカニズムを通じてカーネルによって調停されるであろう。

プロセス能力モデルのキーとなる特徴は：
・主としてシステムサーバ及びそれらのエンティティ間のクライアント−サーバＩＰＣインタラクションの周りに注目している。
・能力はスレッドではなくプロセスに関連している。同じプロセス内のスレッドは、同じアドレス空間及びメモリアクセス許可を共有する。これは１つのスレッドで使用されているあらゆるデータは、同じプロセス内の他の全てのスレッドによって読み出され変更され得ることを意味する。
・能力の監視はローダ及びカーネルによって、及びターゲット・サーバでの能力監視を通じて管理される。カーネルＩＰＣメカニズムは後者に関連する。
・コードが実行中でないとき、能力はライブラリ及びプログラム内部に格納される。ライブラリ及びプログラムに格納された能力は、インストールの間に信頼性のあるコンピューティング・ベースによってのみアクセス可能な位置に格納されるので、変更可能ではない。
・クライアントの能力を扱う必要があるのは全てのサーバではない。サーバはそれらが所望するのに応じて能力を解釈するのを受け持つ。
・この方式に関連する唯一の暗号化は、好適なルート認証に対する認証のチェックが外されるソフトウエアのインストール段階であろう。

２．１ システム能力：デバイスの完全性の保護
ルート、“全てのファイルへのフルアクセス−実行可能に関連する能力を変更できる”
“ルート”能力−信頼性のあるコンピューティング・ベースだけに使用され、デバイス内の全てのファイルへのフルアクセスを提供する。

システム能力
いくつかのシステムは、信頼性のあるコンピューティング・ベースにいくつかの特定のアクセスを必要とする。シンビアンＯＳのオブジェクト指向の実施により、システムサーバによって要求されるリソースの種類は、それに独占される時間が大部分である。従って、１つのシステムサーバは、別のシステムサーバによって要求されるシステム能力と直交するいくつかのシステム能力を許可されるであろう。例えば、ウインドウサーバは、カーネルによって発行されるキーボード及びペンのイベントへのアクセスを許可されるであろうが、電話スタックへのアクセスは許可されないであろう。同様に、電話サーバは、電話スタックへのアクセスは許可されるであろうが、カーネルからのイベントを収集するのは許可されないであろう。

１例として、以下のように命名することができる：
WriteSystemData システム・コンフィグレーションのデータの変更を許可
CommDD 全ての通信及びイーサネット（登録商標）・カード・デバイスドライバへのアクセスを許可
DiskAdmin ディス上の管理タスク（再フォーマット、ドライブのリネーム等）を実行できる。

２．２ ユーザに公開される能力：現実世界へのマッピング許可
能力を生成するプロセスは難しくても良い。最初に監視を必要とするこれらのアクセスを識別し、その後これらの要件をユーザにとって意味のある何かにマッピングする必要がある。加えて、大きな能力は複雑さがより大きいことを意味し、複雑さは安全性の主要な敵であると広く認識されている。従って、能力に基づく解決策は、配備される全体数を少なくしようと努める必要がある。以下の例は、システムサービス（例えば、電話スタック）への未認証アクセスである主な脅威と、ユーザデータの機密性／完全性の保護とをかなり広くマッピングしている。

PhoneNetwork.“電話網サービスにアクセスでき、ユーザのお金を使う可能性がある”
“電話をかける”
“ショートテキストメッセージを送信する”
WriteUserData.“ユーザの個人情報を読み出して変更できる”
“連絡先の追加”
“約束（Appointment）の削除”
ReadUserData.“ユーザの個人情報を読み出せる”
“連絡先データへのアクセス”
“予定（Agenda）データへのアクセス”
LocalNetwork.“ローカルネットワークへアクセスできる”
“ブルートゥースメッセージの送信”
“ＩＲ接続の確立”
“ＵＳＢ接続の確立”
Location.“デバイスの現在位置へのアクセス”
“地図上でのデバイスの位置決め”
“もっとも近いレストラン及び映画館の表示”。

ルート及びシステム能力は必須である；実行可能に許可されていない場合、デバイスのユーザはそれを行うのを決めることができない。それらの厳格な制御は信頼性のあるコンピューティング・プラットフォームの完全性を保証する。しかしながら、ユーザに公開された能力をサーバがチェックしたり解釈する方法は、十分に柔軟でユーザが任意に決定できても良い。

２．３ プロセスへの能力の割り当て
実行時の能力とプロセスとの関係はローダに関わっている。本質的には、ローダは個々のライブラリ及びプログラムに関連した静的能力の設定を、カーネルが保持しカーネルのユーザライブラリＡＰＩを通して照会され得る実行時の能力に変換する。

ローダは以下の規則を適用する。
規則１．プログラムからプロセスを生成するとき、ローダはそのプログラムの能力として同じ能力のセットを割り当てる。
規則２．実行可能なものの中でライブラリをロードしているとき、ライブラリの能力はロードしている実行可能なものの能力のセットと等しいか大きく設定する必要がある。これが真でない場合、そのライブラリはその実行可能なものにロードされない。
規則３．実行可能なものはより高い能力のライブラリをロードできるが、そうすることによって能力は取得できない。
規則４．ローダは、ＴＣＢに確保されたファイルシステムのデータが囲われた部分にないあらゆる実行可能なものをロードするのを拒否する。

以下の点に注意されたい：
・ライブラリの能力はロードの時点でだけチェックされる。その上で、ライブラリに含まれる全てのコードは自由に実行され、同じＩＰＣ呼び出しを開始するときに、それが中で実行されるプログラムと同じ能力のセットが割り当てられる。
・定位置での実行用のＲＯＭイメージについては、ＲＯＭ書き込みツールは、全てのシンボルが実行時のローダと同じタスクを行うことを決定する。従って、ＲＯＭに書き込むときに、ＲＯＭ書き込みツールはローダと同じ規則を適用する必要がある。
これらの規則は、
・例えば、システムサーバへのプラグインなどの、慎重に扱うべきプロセス内で異常なものがロードされるのを防ぐ。
・あらゆるバイパスなしにプロセス内部の慎重に扱うべきコードのカプセル化を促進する。
以下の例は、静的及び動的にロードされたライブラリそれぞれの場合に、これらの規則がどのように適用されるのかを示している。

２．３．１ リンクされたＤＬＬの例
プログラムP.EXEはライブラリL1.DLLにリンクされている。
ライブラリL1.DLLはライブラリL0.DLLにリンクされている。
ケース１：
P.EXEは、Cap1 & Cap2を保持
L1.DLLは、Cap1 & Cap2 & Cap3を保持
L0.DLLは、Cap1 & Cap2を保持
プロセスＰは生成され得ない、ローダはL1.DLLがL0.DLLをロードできないのでプロセスの生成を失敗する。これはL0.DLLがL1.DLLと等しいか大きい能力を有していないためで、規則２が適用される。
ケース２：
P.EXEは、Cap1 & Cap2を保持
L1.DLLは、Cap1 & Cap2 & Cap3を保持
L0.DLLは、Cap1 & Cap2 & Cap3 & Cap4を保持
プロセスＰは生成される、ローダはプロセスの生成に成功し新たなプロセスにはCap1 & Cap2が割り当てられる。新たなプロセスの能力は規則１を適用して決定される；規則３で定義されたように、L1.EXEはL0.DLLの保持する能力Cap4を取得できず、P1.EXEはL1.DLLの保持する能力Cap3を取得できない。

２．３．２ 動的にロードされるＤＬＬの例
プログラムP.EXEはライブラリL1.DLLを動的にロードする。
そしてライブラリL1.DLLはライブラリL0.DLLを動的にロードする。
ケース１：
P.EXEは、Cap1 & Cap2を保持
L1.DLLは、Cap1 & Cap2 & Cap3を保持
L0.DLLは、Cap1 & Cap2を保持
プロセスＰは成功裏に生成されCap1 & Cap2が割り当てられる。ＰがローダにL1.DLL & L0.DLLのロードを要求したとき、ＰはL1.DLL及びL0.DLLをロードできるのでローダは成功裏にロードできる。ここで規則２が適用され、ロードされている実行可能なものはプロセスＰでありライブラリL1.DLLではない：ローダが処理するＩＰＣロード要求はプロセスＰによって送信される。呼び出しがL1.DLL内部にあるというのはここでは適切でない。規則１＆３が上述のように適用され、ＰはL1.DLLをロードすることによってCap3を取得できない。
ケース２：
P.EXEは、Cap1 & Cap2を保持
L1.DLLは、Cap1 & Cap2 & Cap3を保持
L0.DLLは、Cap1 & Cap2 & Cap4を保持
プロセスＰは成功裏に生成されCap1 & Cap2が割り当てられる。ＰがローダにL1.DLL & L0.DLLのロードを要求したとき、ＰはL1.DLL及びL0.DLLをロードできるのでローダは成功裏にロードできる。ここでもロードされている実行可能なものはプロセスＰでありライブラリL1.DLLではないので、Ｐに再度規則２が適用され、規則３はＰがCap3もCap4も取得できないことを確実にする。

３ ケージング・プロセス
３．１ 位置に基づく概念
データの区分化は、単純な信頼性のあるパスがプラットフォームに生成されるように、ファイルシステム内のデータからコードを分離することを含んでいる。本発明の中心的な発想は、非ＴＣＢプロセスをファイルシステムのそれら自体の部分に“囲い込む（caging）”ことによって、慎重に扱うべきディレクトリをそれらから隠すことである。実施形態Ａでは、/systemディレクトリは通常のプロセスから隠される；カーネル及びファイルサーバは、/systemのサブツリーへのあらゆるアクセスを許可する前に、クライアント・プロセスがRoot又はAllFilesの能力を有しているかチェックする。他の全てのクライアントからは、/private/<app_SID>となるであろう特別な専用ディレクトリ、/resources及び/<others>からなるであろう、それぞれ制限された状態でファイルシステムが見えるであろう。加えて、ローダは/systemにないコードを実行しようとするあらゆる試みを認めないであろう。

サブツリー間を区別するのに、ＳＩＤ（安全用識別子）が使用されるであろう。例えば、アプリケーションは、それら自身のリソースファイルを保持するのにそれらのサブツリーを使用するであろう。要するに、データの区分化は、ファイルシステムのプロセス自身の小さな部分の中にプロセスを囲い込むこと（caging）を含んでいる。これは、アプリケーション毎及びサーバ毎に他のプロセスからデフォルトで保護する部分があること意味する。区分化が無いと、よからぬプログラムが能力モデルをバイパスしファイルからデータベース・ディレクトリを簡単に読み取ることを防止するために、アクセス制御リストをファイルシステムに導入することが必要となるであろう。加えて、この手法は、ＴＣＢに確保されたディレクトリ（実施形態Ａでは/system）内のシステム・プラグインの悪意のある置換の脅威に対する更なる保護をもたらす。メモリ管理を同様にしてもよい；現在はカーネルだけが実際のメモリ領域全体を制限無しに見れる。各プロセスは、他の全てのプロセスから独立したプロセッサのアドレス空間が見える。これはカーネル及びメモリ管理ユニット（ＭＭＵ）によって整理され監視される；１つのプロセスのメモリ空間の範囲外のあらゆるアクセスは拒否される。

その意味で、区分化は単純で頑健な解決策である：
−ファイルの位置はそのアクセス規則を完全に記述するのに十分である。補足的情報を何も必要としない。
−位置が変更されるた場合、その規則も変更され得る。
−各プロセスに機密性とそのデータの完全性を保証する専用領域が許可されている。

単純化のために、ファイルシステムは“専用ユーザデータ”及び“システムデータ”の意味を知らない。ファイルにはそのようなフラグが付けられない。要求されたときに、ReadUserData/WriteUserData及びReadSystemData/WriteSystemDataの能力を管理するのは、各サーバ及びアプリケーションが受け持つ。例えば、ユーザがワードプロセッサの文書を個人的に所望する場合、暗号化されたファイルへのアクセスにReadUserDataを不要として、彼女はそれをパスワードで保護してもよい。その上、データベースの場合には、ファイル自体がシステム、ユーザ及び公開のデータを含むことができ、そのためプライバシーのレベルをファイルに割り当てようとすることは不適切である。

好適な実施形態の例を実施形態Ａによって示す；各ファイルシステムは４つのタイプのルートディレクトリ、すなわち、
/system
/private/<process_secure_id>
/resources
/<others>
に区分されている。

/systemは、ＴＣＢ又はAllFilesを有するプロセスだけがアクセスできる。ＴＣＢだけがそれらを変更できる。
/private/<process_secure_id>は、process_secure_idに安全用識別子が割り当てられたあらゆるプロセス、並びに'Root'又は'AllFiles'の能力が許可されたプロセスによって利用可能である。
/resourceは、一般に読み取り専用である；信頼性のあるコンピューティング・ベース（ＴＣＢ）だけが追加、削除、変更を行える。
/<others>は、ファイルの読み取り及び書き込み動作、ファイルの生成、並びに削除があらゆるプロセスで利用可能である。

３．２ 安全用識別子（ＳＩＤ）の概念
上記のように、プロセスはそのＳＩＤが専用ディレクトリの名前と一致した場合にだけ、該専用ディレクトリへのアクセスを得ることができる。受け入れられるのであれば、複数のプロセスを強固な結びつきでサポートするために、プロセスのセットに所与の同じＳＩＤが付与されるであろう。この場合、同じＳＩＤの全てのプロセスは、同じ専用ディレクトリを共有してもよい。しかしながら、この概念はグループの概念とは極めて異なることに注意されたい：１つのプロセスはただ１つのＳＩＤを有し、１つを越えるセキュリティ領域の一部となることはできない。従って、データの囲い込みの実施形態は、ＳＩＤの性質とは関係無いものであるべきである。

３．３ ソフトウエア・インストーラ
１．開いたデバイスでは、アプリケーションのインストール時に、選択された実施形態の規則に従って対応するアプリケーションファイルをディレクトリ内に設置する、ソフトウエア・インストーラによってファイルシステムの構築がなされるであろう。実施形態Ａでは、能力を完備したプログラム及びライブラリは、/system内にある必要がある。
２．公の（読み取り専用或いはそうでない）ディレクトリ内の何らかのファイルがインストールされ得る。
３．インストールするアプリケーションが専用ディレクトリと同じＳＩＤを有している場合、専用ディレクトリ内の何らかのファイルがインストールされ得、そのファイルは中に入れられるべきである。
４．インポート・ディレクトリが存在する場合、プロセス専用ディレクトリのインポート・ディレクトリ内の何らかのファイルがインストールされ得る。実施形態Ａでは、このインポート・ディレクトリは、/private/process_sid/importである。
５．インストールされるべきパッケージが、そのファイルを生成した元のパッケージのアップグレードであると識別されない場合、そのパッケージによって書き換えられる既存のファイルは無い。アップグレードの定義は、本発明の態様に影響しないので、本発明の範疇外である。

規則４がデータ囲い込みの原則に逆らって実行されないことは重要である：インストールされたアプリケーションは、このファイルが一旦インストールされたらアクセスできないであろう。プロセスの専用領域内にインポート・ディレクトリが存在することにより、インストール時に別のアプリケーションがこのプロセスに寄与する可能性を通知する。好ましい例はフォントサーバであろう：全てのフォントはフォントサーバの専用ディレクトリ内に格納されるであろう。しかしながら、外部のアプリケーション・パッケージの全てがそれらの外部の出典を明確に記述しているインポート・ディレクトリの下にあるとき、外部のアプリケーション・パッケージが、サーバの専用ディレクトリを汚すこと無しに新たなフォントを追加することで寄与し得る。

Claims (15)

1. 複数のルートディレクトリで区分されており、ファイルの位置が該ファイルのアクセスポリシーを十分に識別できるように定められている、ファイルシステムでプログラムされていることを特徴とする移動体無線デバイス。
2. 前記ファイルシステム内で前記ファイルの位置を移動させることによって、該ファイルのアクセス権が変更されることを特徴とする請求項１に記載のデバイス。
3. 前記ルートディレクトリの１つが、信頼性のあるコンピューティング・ベースを形成する構成要素に対して確保されていることを特徴とする請求項１に記載のデバイス。
4. １つ以上の信頼性のある構成要素が、プロセスがファイルシステムのサブツリーにアクセスするのに必要な権限又は能力を有しているか否かを検証することを特徴とする請求項１に記載のデバイス。
5. プロセスが、前記ファイルシステムの該プロセス自身の専用領域だけにアクセスするように制限されていることを特徴とする請求項１に記載のデバイス。
6. 前記専用領域が、正しい安全用識別子を有するプロセスだけにアクセス可能であることを特徴とする請求項５に記載のデバイス。
7. 前記ルートディレクトリのそれぞれが、
   （ａ）全てのファイルに渡ってオペレーティングシステム権限が許可された、あらゆるプロセスにアクセス可能なサブツリーを有するルートディレクトリ、
   （ｂ）正しい安全用識別子を有するプロセスだけにアクセス可能なサブツリーを有するルートディレクトリ、
   （ｃ）公で読み取り専用のサブツリーを有するルートディレクトリ、
   （ｄ）ファイルの読み取り及び書き込み動作、ファイルの生成並びに削除について、あらゆるプロセスで利用可能なサブツリーを有するルートディレクトリ、
   のいずれかと同等な機能を有することを特徴とする請求項１に記載のデバイス。
8. 移動体無線デバイス用のオペレーティングシステムであって、
   ファイルがインストールされている場所を制御することによって、既存のファイルシステムの完全性を維持するファイル・インストレーション・メカニズムを備えており、前記ファイルシステムは、複数のルートディレクトリで区分されており、ファイルの位置が該ファイルのアクセスポリシーを十分に識別できるように定められていることを特徴とするオペレーティングシステム。
9. 前記ファイルシステム内で前記ファイルの位置を移動させることによって、該ファイルのアクセス権が変更されることを特徴とする請求項８に記載のオペレーティングシステム。
10. 前記ルートディレクトリの１つが、信頼性のあるコンピューティング・ベースを形成する構成要素に対して確保されていることを特徴とする請求項８に記載のオペレーティングシステム。
11. １つ以上の信頼性のある構成要素が、プロセスがファイルシステムのサブツリーにアクセスするのに必要な権限又は能力を有しているか否かを検証することを特徴とする請求項８に記載のオペレーティングシステム。
12. プロセスが、前記ファイルシステムの該プロセス自身の専用領域だけにアクセスするように制限されていることを特徴とする請求項８に記載のオペレーティングシステム。
13. 前記専用領域が、正しい安全用識別子を有するプロセスだけにアクセス可能であることを特徴とする請求項１２に記載のオペレーティングシステム。
14. 前記ファイル・インストレーション・メカニズムが、プログラムが別のプログラムの専用領域に悪影響を与えずに寄与することを可能とすることを特徴とする請求項８に記載のオペレーティングシステム。
15. 前記ルートディレクトリのそれぞれが、
    （ａ）全てのファイルに渡ってオペレーティングシステム権限が許可された、あらゆるプロセスにアクセス可能なサブツリーを有するルートディレクトリ、
    （ｂ）正しい安全用識別子を有するプロセスだけにアクセス可能なサブツリーを有するルートディレクトリ、
    （ｃ）公で読み取り専用のサブツリーを有するルートディレクトリ、
    （ｄ）ファイルの読み取り及び書き込み動作、ファイルの生成並びに削除について、あらゆるプロセスで利用可能なサブツリーを有するルートディレクトリ、
    のいずれかと同等な機能を有することを特徴とする請求項８に記載のオペレーティングシステム。