JP2008502066A

JP2008502066A - プラグイン・コード・モジュールを実行する複数プロセス・アーキテクチャを有するコンピュータ装置

Info

Publication number: JP2008502066A
Application number: JP2007526540A
Authority: JP
Inventors: ウィリアムギブソン，
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2004-06-09
Filing date: 2005-06-08
Publication date: 2008-01-24
Anticipated expiration: 2025-06-08
Also published as: EP1763716A2; GB2415065B; WO2005121920A2; WO2005121920A3; GB2415065A; US8984529B2; CN100470440C; US20080022292A1; GB0413059D0; CN1965281A; JP4757873B2

Abstract

プラグイン・デザインパターンを使用してソフトウェアシステムのセキュリティ及び信頼性を向上するために、プラグイン・コード・モジュールを自身の専用のプロセスにおいて実行する複数プロセス・アーキテクチャを有するコンピュータ装置が提供される。

Description

本発明は、プラグイン・コード・モジュールを実行するコンピュータ装置に関し、特に、プラグインのデザインパターンを使用してソフトウェアシステムのセキュリティ及び信頼性を向上するために、自身の専用プロセスにおいてモジュールを実行する装置に関する。

本明細書において用いられる用語「コンピュータ装置」は、任意の形態の電子コンピュータ装置を含むように広範囲に解釈され、データ記録装置、ハンドヘルドコンピュータ及びパーソナルコンピュータを含む任意の種類又は形態のコンピュータ、並びに、単一装置内で通信、画像の記録と再生との少なくともいずれか、及び演算機能を組み合わせた移動電話、スマートフォン、通信機及び他の形態の無線／有線情報装置を含む任意の形態の通信装置を含む。

プラグインは、実行時にそのプラグインをロードすること又は呼び出すことが可能な疎結合アプリケーションに対して、特定のサービスを提供する実行可能コードの置換可能な項目として定義される。

プラグインは、多くのオペレーティングシステムや多くのアプリケーションにおいて広く使用されている。この技術の主な利点は一般に普及しており、以下のことを含む。：
・新しい機能が要求されたときにプラグイン・モジュールを追加又は置換できるため、プラグインを使用できるアプリケーションは本質的に拡張可能である。
・プラグインのコードは、要望に応じてのみアプリケーションによりロードされるため、プログラムによるメモリの要求量が少なくなり、起動が迅速になる。
・ソフトウェア設計者がプラグインの内部動作について理解する必要がないため、プラグイン・デザインはアーキテクチャに関して柔軟性（flexible）がある。
・商業上の利点を提供する；オプションの機能性又はライセンシーが提供する機能性をプラグインを介して提供することにより、製品化までの時間が短縮され、第三者が既存のアプリケーションに対するプラグイン・モジュールを作成する市場を活発にすることができる。

プラグインは、ダイナミック・リンク・ライブラリ（ＤＬＬ）として又はモジュールを呼び出すアプリケーションと同一のプロセス空間内で実行する同様の種類のモジュールとしてロードされることが多い。しかし、プラグインは、別個の（separated:分離された）プロセスとしても生成（ロード及び実行）される。それら２つの選択可能なパターンは双方とも広く使用されている。

実行時にアプリケーションによりロードされるダイナミック・リンク・ライブラリ（ＤＬＬ）モジュールは、多くのアプリケーションにとって、プラグインを実現するための従来からの手法であった。ソフトウェア設計者は、特定の種類の全てのモジュールが準拠する必要のある抽象ＡＰＩを含むフレームワーク又はアーキテクチャを事前に指定する。そのようなモジュールは、事前に定義された所定の手法で呼出しアプリケーションに「プラグイン」し、多くのオペレーティングシステムにおいて広く使用されている。ユーザは、プリンタドライバ等のモジュールの形態でその種類のプラグインをよく知っているだろう。

ＤＬＬプラグインは、非常に効率的であると考えられる。すなわち、アプリケーションは、それらメソッド（method）がアプリケーション自体に不可欠である場合に比べてメモリのオーバヘッドのないＤＬＬ又は非高速ＤＬＬにおいてメソッドを直接呼び出すことができる。また、ＤＬＬプラグインは非常に柔軟性がある。すなわち、プラグインは、新しい機能性を提供するために追加でき、あるいは既存の機能性を修正するために置換できる。一般に、呼出しアプリケーションは、特定の種類の全てのプラグインＤＬＬを識別するコードを含む（あるいは、プラグインが特定の固有のファイル拡張子又はディレクトリ位置を有する必要があることを指定する）。

生成プロセスは、長年の間、オペレーティングシステムにおいて実現されてきた。Dennis Ritchieによると、プロセスをフォークする機能は、Unix（登録商標）が６０年代中頃のBerkeley SDS30タイムシェアリングシステムから継承したものである（http://cm.bell-labs.com/cm/cs/who/dmr/hist.htmlにおいてDennis Ritchieによる非特許文献１を参照）。機能をアプリケーションに追加することを可能にするプラグイン機構としてその機能を使用することは、完全に開発されるまでに長い時間がかかったが、現在では、種々のUnix（登録商標）系オペレーティングシステムにおいて普及しており、特に種々のコンテンツを扱うために種々の実行ファイルがInternet Explorerにプラグインされる等、Microsoft Windows（登録商標）においても普及している。

しかし、全てのプラグイン・モジュール・アーキテクチャは、オペレーティングシステム又はプラットフォームのセキュリティの分野において問題を引き起こすだろう。これは、悪意のあるコード又は不適切に書かれたコードに対するプラットフォームの防御機構の原理、アーキテクチャ及び実現を含む。プラグインがその分野において問題を引き起こすと考えられることは意外なことではない。これは、システムの公開性、柔軟性及びグレードアップの可能性が増加することにより、そのような問題が引き起こされる可能性が高くなるからである。

プラットフォームのセキュリティは、全てのコンピュータ装置及び通信装置に対する課題である。そのような装置上のデータの完全性と、ユーザの出費に見合う装置の潜在性と、秘密情報及び個人情報の格納に装置を使用することは、製造業者及び消費者等にとって高い関心事である。従って、プラグイン機構がセキュリティを損なわないことを保証することは、最も重要な問題である。

信頼及び危険性の課題を考慮することは、プラグインに対する真の関心事をセキュリティ問題が反映する理由を理解する際に非常に役立つ。ユーザの銀行口座にアクセスできるアプリケーションが、プラグインをサポートするアプリケーションであると仮定しよう。このアプリケーションは、プラグイン・モジュールを信頼して銀行口座にアクセスさせてもよいことをどのようにして区別できるであろうか？また、アプリケーションが特定のプラグイン・モジュールを信頼できることを確信していない場合、銀行口座に対するアクセス権を与えるという危険を冒すことなく、どのようにしてプラグインサービスを使用できるであろうか？

これに対して、装置は、装置上の保護されたコンテンツに対するアクセス権を制御するのに用いられる暗号化アルゴリズム及び復号アルゴリズムを実現するプラグイン・モジュールを含むと仮定する。プラグイン・モジュールは、データオブジェクトにアクセスするためにプラグイン・モジュールをロードしようと試みるアプリケーションがロードする権利を実際に有することを確信できる必要があることは明らかである。信頼できないアプリケーションにアクセス権を付与することで、保護されたコンテンツの完全性を危険にさらすことになる。

コンピュータ装置のユーザの多くは、それらの種類の問題及び危険性がインターネットに常に蔓延するウイルス、トロイ、ワーム及び他の種類のコンピュータ有害ソフトにより起こる問題及び危険性に非常に類似するため、それら問題及び危険性をよく知っているだろう。

この分野においてオペレーティングシステム及びプラットフォームをセキュリティ保護する多くのスキームが存在するが、本発明に関連して説明されるような問題に対する解決策は、セキュリティの単位であり、メモリ保護の単位でもあるプロセスに基づくスキームと主に関係している。そのようなスキームにおいて、プロセスは種々のセキュリティ属性を有する。セキュリティ属性は、機能、許可及びアイデンティティを含んでもよいが、それらに限定されない。これらの用語は、当業者には容易に理解されると仮定する。

この種類の最も広く使用されるオペレーティングシステムはUnix（登録商標）から派生し、許可及びグループアイデンティティの集合は、システムにおいて実行できるプロセス及びプロセスが開放又はアクセスできるリソースについて規定する。しかし、LondonのSymbian Software Ltdの移動通信装置用のSymbian OS（商標）オペレーティングシステムに導入される多少異なるプロセスに基づくプラットフォーム・セキュリティ・アーキテクチャに関して、一例として本発明を説明する。

このオペレーティングシステムの多くのコアコンポーネントは、特許文献１において説明される。この特許出願の一部が便宜上要約される。

Symbian OS（商標）オペレーティングシステムのプラットフォーム・セキュリティ・アーキテクチャにおいて、実行可能コードのある項目（アプリケーション又はプラグイン）に設けられる信頼度の公開指標は、１つ以上の機能を付与することにより示される。実行可能プロセスの場合、機能は特定のシステムリソースに対するアクセス権を公開できる能力を規定する。そのようなアクセス権は、便宜上付与されるべきではない。これは、コードに付与されたアクセス権の結果、信頼違反が発生するという高い危険性が存在しないと評価される場合のみに許可されるべきである。

機能に加え、Symbian OS（商標）オペレーティングシステムにおいて使用される他のセキュリティ属性が存在する。それは、実行可能コードの項目を含む各ファイルに対する固有の識別子（ＵＩＤ：unique identifiers）の集合と、項目の作成元を示すのに使用されるベンダＩＤ（ＶＩＤ：vendor ID）等のグループＩＤとを含む。Symbian OS（商標）オペレーティングシステムのインストール可能なアプリケーションは、Ｘ．５０９等の公開鍵インフラストラクチャ（ＰＫＩ：public key infrastructure）仕様に準拠するセキュリティ証明書を搬送してもよい。

Symbianにより提供されるプラットフォーム・セキュリティ・アーキテクチャの重要な特徴は、全ての種類の実行可能コードモジュールは、構築されたときに固定機能を割り当てられることである。それらのうち２つの例の概要を以下に示す。
・アプリケーションの場合、それら機能により、アプリケーションがシステム設備（電話機能性等）又は電話機に格納されたデータ（連絡先データ等）に対するアクセス権を有するのに必要なオペレーティングシステムのアプリケーションに対する信頼度が判定される。それら機能はプロセス全体にわたり、変更されることはない。
・ＤＬＬの場合、それら機能によりアプリケーションのＤＬＬのコードに対する信頼度を判定するが、ＤＬＬはロードされると、ＤＬＬがロードされたプロセスと同一の機能を有して実行される。

このアーキテクチャが、ある特定の状況において不適切なプラグインＤＬＬデザインを提供することは明らかである。これは、ＤＬＬが、呼出しアプリケーションと同一のプロセスの一部としてロードされ、且つアドレス空間全体及び格納された全てのデータに対してアクセス権を有するためである。このため、アプリケーションは、プラグインＤＬＬの完全性において完全な信頼を有する必要がある。ＤＬＬに対するシステムローダは、ＤＬＬを呼び出すことを必要とするアプリケーションと少なくとも同等の機能を有さないＤＬＬのロードを拒否することにより、必要な信頼を実現する。これは、アプリケーションとＤＬＬとの周知の安定した組合せの場合には問題ない。しかし、問題が発生する状況が想定され、セキュリティ保護された機能に基づくプラットフォームに対して、プラグインＤＬＬを不適切なデザインにする。

最も明らかな例として、新しい機能の追加によりアップグレードされたアプリケーションは、先のバージョンが正常にロードできた同一のＤＬＬが信頼されず新しくアップグレードされた機能を有さない場合、それらＤＬＬをロードすることはできない。別の例として、既存のＤＬＬにより提供されるサービスを使用することを必要とする新しく書かれたアプリケーションは、ＤＬＬが信用されず機能の集合全体を有することができないため、サービスを使用できないことを発見する。

上記の例の反対のことも起こる可能性がある。アプリケーションの機能は変更されることがないため、提供しようとする機能性に対して必須の機密事項を扱う機能を有することができる信頼されたＤＬＬは、ある特定のアプリケーションがオペレーティングシステムにより信頼されず同等のレベルの機能を有さないためにＤＬＬを利用できないことを発見する。

そのような例は、単に理論上のものではない。すなわち、プラグインアーキテクチャの本来の目的はシステムに対して柔軟性及び拡張性を加えるが、このことは、その特性に関する問題がほぼ確実に発生することを意味する。要求するＤＬＬ及びサービスの数が増加するため、必要な実装機能の集合も増加する。

ＤＬＬプラグインに代わるものとして、生成プロセス・プラグインがある。これにより、アプリケーション及びそれらのプラグインは、ばらばら（disjoint）の機能集合を有することができる。しかし、プロセス・プラグイン・パターンにより機能集合がばらばらであることが可能になるため、セキュア・プラットフォームに対する問題が生じる。相互の信頼関係が親プロセスと子プロセスとの間に確立されることを可能にする子プロセスを生成する明らかな機構は現在の技術には存在せず、この不足が原因となって起こる可能性のある脅威が重大であると考えられる。

例えば、ドライブをフォーマットするのに使用されるプラグインは、プラグインを呼び出したアプリケーションの挙動が信頼できることをどのようにして認識するのか？また、セキュリティ保護されたデータを処理するためにプラグインを使用することを必要とするアプリケーションは、プラグインが信頼されてそのデータの内容を有することができることをどのようにして認識するのか？

ＤＬＬプラグインの代わりとして生成プロセス・プラグインを実現する場合に、解決される必要のある実用上の問題が存在する。それら問題は、オペレーティングシステムにおいて、プロセスがメモリ保護の基本単位であるという事実から発生する。従って、呼出しアプリケーション及びプラグインプロセスの双方とも、互いのアドレス空間に自動アクセスできず、いずれも他方のアプリケーション・プログラム・インタフェース（ＡＰＩ）を直接呼び出すことはできない。
英国特許出願第０３１２１９１．０号,「安全な携帯無線装置（Secure Mobile Wireless Device）」 Dennis Ritchie,「Ｕｎｉｘ（登録商標）タイムシェアリング・システムの進化（The Evolution of the Ｕｎｉｘ（登録商標） Time-Sharing System）」

本発明は、プラグインがプロセスとして実現される方法であって、親アプリケーションと子プロセスとの間の相互信頼に基づいてアプリケーションにより新しいアドレス空間にプラグインが生成される、方法を提供することを目的とする。

本発明の第１の側面によると、プロセスに基づくセキュリティ・モデルを有するコンピュータ装置であって、前記装置上のソフトウェア・アプリケーションは、当該アプリケーションのセキュリティ属性と、異なる又は互換性のないセキュリティ属性を有するプラグイン・モジュールを、当該プラグイン・モジュールを別個のプロセスとして呼び出すことにより、利用することができる、コンピュータ装置が提供される。

本発明の第２の側面によると、プロセスに基づくセキュリティ・モデルを有するコンピュータ装置を動作させる方法であって、プラグイン・モジュールを別個のプロセスとして呼び出すことにより、ソフトウェア・アプリケーションのセキュリティ属性と、異なる又は互換性のないセキュリティ属性を有する前記プラグイン・モジュールを利用できるように前記装置上に前記ソフトウェア・アプリケーションを構成することを備える方法が提供される。

本発明の第３の側面によると、第１の側面によるコンピュータ装置を第２の側面による方法に従って動作させるためのコンピュータ装置に対するオペレーティングシステムが提供される。

更なる例として、本発明の一実施形態を次に説明する。

本発明は、複数プロセス・アーキテクチャを有するコンピュータ装置を提供し、親アプリケーションと子プロセスとの間に相互信頼を作成することに基づく。

従って、生成プロセスは、信頼されないアプリケーションにより呼び出されておらず、且つ情報が渡されていないことを保証する必要がある。これを容易にするために、コンピュータ装置のセキュア・オペレーティングシステムは、親に関する全ての関連アイデンティティ、セキュリティ及び機能情報を検索するために子プロセスに対して設備を提供するように構成される。例えば、システムディスクの内容全てを再フォーマットしたアプリケーションは、システムディスクを生成したアプリケーションが適切なシステム機能（Symbian OS（商標）オペレーティングシステムのDiskAdmin等）を有することを保証できるだろう。

セキュア・オペレーティングシステムは、子プロセスが生成される前に、子プロセスのアイデンティティ、セキュリティ及び機能情報を親アプリケーションが検索するための機能を含むように構成される。これにより、生成プロセスに対して情報を渡すアプリケーションは、それらプロセスが信頼されてその情報を有することができることを確信できる。

アプリケーションが実行可能プラグインとなるものを信頼できると確信すると、多数の型なし（untyped）整数を保持する特別な一時データ構造を介してプラグインが実行を開始する前に、アプリケーションはプラグインに情報を渡す。それら整数は、型なしなので、システムリソース又は他のオブジェクト（共有メモリチャンク、ファイルハンドル、ミューテック及びセマフォ等）にファイルセッション及びハンドルを渡すために使用される。Symbian OS（商標）オペレーティングシステムにより使用される構造は、各々が１度のみ読出し可能である１６個の環境スロットに基づく。英国特許出願第０３２７２６１．４号の「安全なハンドル（Secure Handles）」には、オブジェクトに対するハンドルを安全に渡す方法が説明されている。英国特許出願第０３１２１９０．２号の「保護されたファイルシステムを用いた安全な携帯無線装置（Secure Mobile Wireless Device With Protected File System）」には、ファイルハンドルを渡す機構により、アプリケーションとそれらのプラグインとの間でセキュリティ保護されたファイルを共有することを可能にする方法が説明されている。

本発明によれば、アプリケーションがプラグインプロセスに対してどのような情報を示すかについて、非常に高度な制御がなされる。渡す情報の選択は、呼出しアプリケーションに完全に依存する。特定の項目を渡すことを選択しない場合、プラグインは、項目の内容を確認するどころか項目の存在さえ見つけられない。従って、ＡＰＩの不正な呼出し又はデータに対する不正なアクセスにより不良プラグインプロセスが、誤って又は故意に親アプリケーションの機能を、破損又は損なうことは、事実上不可能である。

その逆もまた真である。すなわち、プラグインプロセスは、自身のメソッド又はデータを呼出しアプリケーションに自動的に示さない。これにより、高度な機密機能が付与されているが、それら機能に対するアクセス権を必ずしも有さないアプリケーションが使用できる、プラグインプロセスを設計することが可能になる。プロセスは、アプリケーションにサービスを提供するときに機能が漏洩するのを回避するために、渡される情報を非常に慎重に監視するように構成される。しかし、先に概要を説明したように、これはプラグインＤＬＬでは不可能である。

プラグイン・モジュールを別個のプロセスとして実行させることにより、本当に必要とする機能のみを有するプラグインを提供できる。これを行なうことにより、セキュリティ上より安全なシステムが実現され、アプリケーションが所有する機能より少ない機能を有するプラグインプロセスを生成するアプリケーションをカバーするために、特別なルールは必要ない。

プラグインは自身のプロセス空間で実行するため、一般に、不適切に挙動するプラグインは親アプリケーションに損傷を与えない。これに対して、不適切に挙動するＤＬＬプラグインは、アプリケーションを破壊し、データを破損させやすい。従って、本発明により提供される複数プロセス・アーキテクチャは、オペレーティングシステム及びその全てのサブシステムの安定性及び信頼性を保証するという利点を有する。プラグインが故障した場合、そのプラグインはその後安全に無視される。

バイナリ互換性を維持してプラグインを呼び出すプロセスの機能を向上することが可能である。プラグインに必要な機能を要求しないことにより、システム全体の開発継続の結果、互換性に関する負担は少なくなる。

従って、本発明は、プラグインを自身の専用のプロセスにおいて実現することにより、プラグイン・デザインパターンを使用してソフトウェアシステムのセキュリティ及び信頼性を向上させる手段の一つである。これを行なうことにより、アプリケーションは、プラグインを呼び出す前に又はプラグインに情報を渡す前に、プラグインのセキュリティ属性をチェックでき、プラグインは、受信した情報に対して動作する前にプラグインを呼び出したアプリケーションのセキュリティ属性をチェックできる。

これは、セキュリティ属性が自身のセキュリティ属性と異なるか又は自身のセキュリティ属性と互換性のないプラグインをアプリケーションが使用できることを保証し、障害を起こしたプラグイン又は不適切に挙動するプラグインが、インタフェースするオペレーティングシステムフレームワークの障害の原因とならないことを保証する。

アプリケーション及びプラグインが機能及びアイデンティティの発見に基づいて相互の信頼関係を確立することを可能にするSymbian OS（商標）オペレーティングシステム方法論、並びに親プロセスから子プロセスにデータを渡す方法を次に説明する。

以下のコードの例は、上記技術の実現例である。これらの例において、読み手は、Symbian OS（商標）オペレーティングシステムのプログラミング用語をよく知っているものと仮定する。当業者は、本明細書において開示される技術を自身のオペレーティングシステムの環境に容易に適応させられるだろう。

ａ）親が子プロセスの機能及びアイデンティティ情報をチェックする方法
TUint32 RProcess::SecureId() const;
TUint32 RProcess::VendorId() const;
これらは、目標プロセスのSecure ID及びVendor IDを返す。

TInt RProcess::HasCapability(TCapability aCap) const;
TInt RProcess::HasCapability(TCapability aCap1, TCapability aCap2) const;
TInt RProcess::HasCapability(TCapability aCap1, TCapability aCap2, TCapability aCap3) const;
これらは、目標プロセスが特定の機能又は機能の集合を有しているかをチェックし、KErrNone又はKErrPermissionDeniedのいずれかを返す。

TInt RProcess::CheckPolicy(const TSecurityPolicy& aPolicy) const;
目標プロセスがaPolicyにより特定された全ての機能を所有し、且つaPolicyにより特定されたSecure ID又はVendor ID（存在する場合は）を有することをチェックする。

ｂ）子プロセスが親の機能及びアイデンティティ情報をチェックする方法
TUint32 User::CreatorSecureId() const;
TUint32 User::CreatorVendorId() const;
これらは、現在のプロセスを作成したプロセスのSecure ID及びVendor IDを返す。

TInt User::CreatorHasCapability(TCapability aCap) const;
TInt User::CreatorHasCapability(TCapability aCap1, TCapability aCap2) const;
TInt User::CreatorHasCapability(TCapability aCap1, TCapability aCap2, TCapability aCap3) const;
これらは、現在のプロセスを作成したプロセスが特定の機能又は機能の集合を有するかをチェックし、KErrNone又はKErrPermissionDeniedのいずれかを返す。

TInt User::CreatorCheckPolicy(const TSecurityPolicy& aPolicy) const;
現在のプロセスを作成したプロセスがaPolicyにより特定された全ての機能を所有し、且つaPolicyにより特定されたSecure ID又はVendor ID（存在する場合は）を有することをチェックする。
ｃ）子プロセスにデータを渡す
Symbian OS（商標）オペレーティングシステムにおいて、プロセスは、開始プロセスにより渡される情報を含むことができる１６個の環境スロットを有する。本明細書において、開始プロセス（launching process）は親と呼ばれ、開始された（launched process）プロセスは子と呼ばれる。スロット０は確保され、汎用情報を渡すのには利用されない。

親プロセスは、子プロセスを作成した後、子プロセスを再開する前に、子プロセスに情報を渡すのが好ましい。再開されたプロセスに環境データを設定しようとすることはエラーである。

尚、子プロセスは、１度だけ自身の環境から情報を抽出できる。

親及び子プロセスの作成者は、環境スロットに含まれるものに関して同意するべきであり、スロットの長さとは別にスロットの内容をクエリする手法はない。

親プロセスはSetParameterを呼び出し、パラメータを子プロセスの環境に置く。

TInt RProcess::SetParameter(TInt aSlot, RHandleBase aHandle);
TInt RProcess::SetParameter(TInt aSlot, const RSubSessionBase& aSession);
TInt RProcess::SetParameter(TInt aSlot, const TDesC16& aDes);
TInt RProcess::SetParameter(TInt aSlot, const TDesC8& aDes);
TInt RProcess::SetParameter(TInt aSlot, TInt aData);
子プロセスは、RHandleBase::Open又はユーザAPIのいずれかを使用して、自身の環境から情報を抽出する。

TInt RSemaphore::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);
TInt RBusLogicalChannel::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);
TInt RMsgQueueBase::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);
TInt RMutex::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);
TInt RChunk::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);
TInt RSessionBase::Open(TInt aArgumentIndex, TOwnerType aType=EOwnerProcess);

IMPORT_C static TInt User::ParameterLength(TInt aSlot);
IMPORT_C static TInt User::GetTIntParameter(TInt aSlot, TInt& aData);
IMPORT_C static TInt User::GetDesParameter(TInt aSlot, TDes8& aDes);
IMPORT_C static TInt User::GetDesParameter(TInt aSlot, TDes16& aDes);

ｄ）ファイルハンドルを渡す
ファイルサーバセッションハンドル及びファイルハンドルは、子プロセスに渡される。ファイルハンドルを使用するために、セッションハンドルが取得される。子プロセスは、ファイルハンドルを採用するため、ファイルハンドルが親により閉じられる必要はない。ファイルサーバセッションは、特にファイルを共有するために作成され、他の目的で親プロセスにより使用されないことがセキュリティの理由から好ましい。

//開始プロセス
RProcess p;
p.Create(KProcName, KNullDesC); //「子」プロセスを作成する
RFile file;
RFs session;
session.Connect(); //ファイルサーバへ接続する
session.ShareProtected();
file.Create(iSession, KFileName, EFileStreamText|EFileWrite|EFileShareAny);
file.Write(0, KTestData);
p.SetParameter(5, session); //セッションハンドル
p.SetParameter(6, file); //ファイルハンドル
session.Close();
p.Resume();

//開始されたプロセス
RFs session;
session.Open(5); //セッションハンドルを取得する
RFile file;
TInt handle;
ret = User::GetTIntParameter(6, handle); //ファイルハンドルを取得する
file.Adopt(session, handle); //ハンドルを採用する
TBuf8＜100＞ rbuf; //ファイルを使用する
ret = file.Read(0, rbuf);
file.Close();
session.Close();

ｅ）RHandleBaseから得られたハンドルを渡す
RHandleBaseから得られたハンドルは、子プロセスに渡される。ハンドルは、子の環境に格納される時に複写される。親は、SetParameterを呼び出した直後にハンドルを閉じるか、あるいはハンドルを使用し続け、後で閉じることができる。

//開始プロセス、ミューテック及びセマフォにハンドルを渡す
RMutex mutex;
RSemaphore sem;
RProcess p;
p.Create(KProcName, KNullDesC);
mutex.CreateGlobal(KMutexName); //ミューテックを作成する
sem.CreateGlobal(KSemName, 0); //セマフォを作成する
p.SetParameter(3, mutex); //ミューテックハンドルを子プロセスに置く
environment slot 3
p.SetParameter(4, sem); //セマフォハンドルを子プロセスに置く
environment slot 4
mutex.Close();
Sem.Close();
p.Resume(); //子プロセスを再開する

//ハンドルを検索する開始されたプロセス
RMutex mutex;
mutex.Open(3, EOwnerThread); //ミューテックハンドルを取得する
RSemaphore sem;
sem.Open(4, EOwnerThread); //セマフォハンドルを取得する
//セマフォ及びミューテックを使用する
mutex.Close();
sem.Close();

ｆ）記述子データを渡す
８ビット記述子データ及び１６ビット記述子データは、親から子プロセスに渡される。データは、User::GetDesParameter()を呼び出すことにより、子プロセスのバッファにコピーされる。パラメータの長さは、User::ParameterLength()を呼び出すことにより、データを検索する前にチェックされる。

//８ビットデータ及び１６ビットデータを渡す開始プロセス
ret = p.Create(KProcName, KNullDesC);
p.SetParameter(2, KSixteenBitDes);
p.SetParameter(3, KEightBitDes);
p.Resume();

//８ビットデータ及び１６ビットデータを検索する開始されたプロセス
TBuf16＜40＞ buf;
len = User::ParameterLength(2); //パラメータの長さはバイトサイズである
ret = User::GetDesParameter(2, buf);
test(buf.Length() == len/2);

TBuf8＜40＞ buf8;
len = User::ParameterLength(3);
ret = User::GetDesParameter(3, buf8);
test (len == buf.Length());

ｇ）整数を渡す
整数は、親から子プロセスに渡される。

//親プロセス
ret = p.Create(KProcName, KNullDesC);
p.SetParameter(12, 1234);
p.Resume();

//子プロセス
TInt val;
ret = User::GetTIntParameter(12, val)

ｈ）エラー処理
親プロセスは、以下の場合、ハンドルを使用してSetParameterを呼び出した時にパニック（panicked）になる。
・親プロセスが作成プロセスでない場合。
・スロット番号が範囲外である場合。
・スロットが使用中の場合。
・ハンドルがローカルである場合。

親プロセスは、以下の場合、記述子又は整数を使用してSetParameterを呼び出した時にパニックになる。
・親プロセスが作成プロセスでない場合。
・スロット番号が範囲外である場合。
・スロットが使用中の場合。
・データの長さが負の場合。

子プロセスは、以下の場合にパニックになる。
・スロット番号が範囲外である場合。

スロットが誤ったデータの種類を含む場合又は長さが誤っている場合、プロセス環境からデータを抽出するＡＰＩ呼出しはKErrArgumentを返す。スロットが空の場合、ＡＰＩ呼び出しはKErrNotFoundを返す。

ｉ）実現例の考察
ファイルハンドルを共有する場合、親プロセスは、特にファイルハンドルを共有する目的で、別個のファイルサーバセッションを作成するべきである。これは、親プロセスがファイルサーバセッションと同時に他のファイルを開いている場合、子プロセスが、ファイルハンドルの全ての可能な値に対して繰り返し、且つ各々を採用するように試みることにより、それらファイルに対するアクセス権を獲得できるからである。同様の理由から、子プロセスは、そのセッションをファイルを共有するためだけに使用するべきであり、他のファイルにアクセスするために使用するべきではない。

SetParameterは、プロセスが再開される前でのみ呼び出される。
パラメータ情報は、１度だけ検索される。
ハンドル又はバイナリデータを含むことができる１６個のデータスロットが存在する。スロット０は確保される。

特定の実施形態を参照して本発明について説明したが、添付の請求の範囲により規定されるように、本発明の範囲から逸脱せずに変更が行なわれてもよいことは理解されるだろう。例えば、本発明は、Ｕｎｉｘ（登録商標）方式の許可を利用するプロセスに基づくセキュリティ・アーキテクチャを含む任意のプロセスに基づくセキュリティ・アーキテクチャに適用可能である。

Claims

プロセスに基づくセキュリティ・モデルを有するコンピュータ装置であって、
前記装置上のソフトウェア・アプリケーションは、当該アプリケーションのセキュリティ属性と、異なる又は互換性のないセキュリティ属性を有するプラグイン・モジュールを、当該プラグイン・モジュールを別個のプロセスとして呼び出すことにより、利用することができる、コンピュータ装置。
プラグイン・モジュールを呼び出そうとするアプリケーションは、該モジュールを呼び出す前に該モジュールの前記セキュリティ属性を検証することができる、請求項１記載のコンピュータ装置。
別個のプロセスとして呼び出されるプラグイン・モジュールは、該モジュールを呼び出す前記アプリケーションの前記セキュリティ属性を検証することができる、請求項１又は２記載のコンピュータ装置。
アプリケーションは、前記アプリケーションが実行される前に、一時データ構造を介してプラグイン・モジュールへ情報を渡すように構成される、請求項１から３のいずれか１項に記載のコンピュータ装置。
プロセスに基づくセキュリティ・モデルを有するコンピュータ装置を動作させる方法であって、
プラグイン・モジュールを別個のプロセスとして呼び出すことにより、ソフトウェア・アプリケーションのセキュリティ属性と、異なる又は互換性のないセキュリティ属性を有する前記プラグイン・モジュールを利用できるように前記装置上に前記ソフトウェア・アプリケーションを構成することを備える方法。
プラグイン・モジュールを呼び出そうとするアプリケーションは、該モジュールを呼び出す前に、前記モジュールの前記セキュリティ属性を検証することができるように構成される、請求項５記載の方法。
別個のプロセスとして呼び出されたプラグイン・モジュールは、前記モジュールを呼び出す前記アプリケーションの前記セキュリティ属性を検証できるように構成される、請求項５又は６に記載の方法。
アプリケーションは、前記アプリケーションが実行される前に、一時データ構造を介してプラグイン・モジュールに情報を渡すように構成される、請求項５から７のいずれか１項に記載の方法。
請求項１から４のいずれか１項に記載のコンピュータ装置を請求項５から８のいずれか１項に記載の方法に従って動作させるためのコンピュータ装置のためのオペレーティングシステム。