AGL Application Framework - Privileges Management

AGL

AGL Application Framework - Privileges Management 翻訳元

1.概要

　AGLが最小のセキュリティー要件を満たすために、アプリケーションの実行に関する２つの基本的な仕組みがある。

  • ユーザー単位で許可を制限する：１つの車に対して、所有車、整備士、運転手、乗客 のように複数のユーザーがいる。それぞれのユーザーの特権は異なり、何人かは他のユーザーよりも権利を持つべきです。これは、ユーザーまたはプロフィールに関連した許可によって管理される。

  • アプリケーション単位で許可を制限する： アプリケーションは適切な操作をするために必要となる許可を要求しなければいけない。許可が与えられたとき、アプリケーションは保護されたサービスやリソースにアクセスすることができる。

　このドキュメントは次の事に焦点を当てています。 　："ユーザー"のために起動している"アプリケーション"が"許可"によって、制限されたリソースにアクセスする必要があるとき、(許可、ユーザー、アプリケーション)の３つはチェックしなければいけない。

The following diagram summarizes how restrictions should apply: overview.png

　現在のAGL Application Frameworkの実装では、アクセス制御の仕組み(DAC1/MAC2)が全体的なセキュリティとシステム全体の分離のために使われている。 　両方の仕組みは、より低いレベルのサービスとハードウェアへアクセスするために、アプリケーションに認証された通信路とAPIを使うことを強制するために使われる。しかし、実用的な許可をチェックする役割を持つ他の仕組みが必要である。：現在、AGLにはこの仕事はポリシーチェッカーサービス(Cynara)に依存している。 　ここに、AGL Application Framework を通してアプリケーションを実行する典型的なアーキテクチャを示す。：

architecture.png

　セキュリティコンテキストの違いを提供し、アプリケーションに低レベルのサービスとリソースにアクセスする既知のAPI呼び出しをすることを強制するために、アーキテクチャは階層化される。

SMACKはアプリケーションからシステムサービスに直接アクセスするのを防ぐ責任がある。

アプリケーションをインストールするどんなユーザーも、そのアプリケーションが何を要求するのか、何もないのか予想する。： 例えば、用心深いユーザーは、SMSを送信する、連絡帳を読み出す、インターネットアクセスするなどのいづれかを必要とする電卓アプリはインストールしないでしょう。

アプリケーションの許可(または、特権)は、特定のユーザーがサービスにアクセスでき、いくつかのサービスAPIの一部を使う権利を持っているかを検証するために用いられる。 この操作は上図の“Privileges Check”を指す。

アプリケーションの許可は"特権の分離"の法則が大事にされている時だけ意味をなす。： すべてのアプリケーションが実行などに必要な特権とリソースを持たなければいけないということを述べている。

だから、システムが失敗した場合、その損害は使われる特権とリソースによって認証されることを超えない。(特権の分離によって制限されるかもしれない)。

違いを言うと：理論的には、アプリケーションは常に最小限の特権を要求すべきで、それ以上はいらない。

したがって、sensitiveで保護されたAPIを使うアプリケーションは、WGTパッケージに含まれているアプリケーションの設定ファイルの中に、要求された特権を宣言しなければいけない： 要求された特権は、ユーザー承認後に、application framework と Cynara によって検査され保存される。

このステップで、ユーザーはインストールをキャンセルできる、また、要求された特権を調整できる。 特権を調整するとはつまり、以下のカテゴリの１つを特権に設定することです。：

  • Permit: ユーザーによらず、capabilityの使用が常に許可される。
  • Deny: Use of the device capability is always denied It’s also possible to envision dynamic privileges granted/revoked by the user at run time by using some extra states:
  • Blanket Prompt: User is prompted for confirmation the first time the API function is called by the widget, but once confirmed, prompting is never required again.
  • Session Prompt: User is prompted once per session.
  • One-Shot Prompt: User is prompted each time the restricted API is invoked.

特権をスマートに管理する別の方法は、オプションの特権を定義することです: もし実行時に、特権が与えられていなかったら、アプリケーションは優しく行動し、後で特権を尋ねるか、目的に達成できる他の資産を使うべき。 つまり、実行時、システムは、与えられたアプリケーションは要求されて与えられた特権にアクセスする サービスを使うだけであることを保証する。 インストール時のユーザー設定によるが、いくつかの動的な特権の獲得や破棄は実行時に起こる。

2.特権: 定義

2.1. Format

特権は多くのユニークな文字列によって説明でき特定できる 。 しかし、特権を簡単に認識できる共有の記法、その起源、およびそれを適用するコンテキスト(“profile”)を使うこと は良い習慣だろう。 この視点でみると、以下のフォーマットのうち１つを使うことで開始することができる。

  • URN style (好まれる)
    urn:<vendor>:privilege:<profile>:<name>[:<operation>]
  • URL style (Tizen 記法に近い):
    http://<vendor>/privilege/<profile>/<name>[.<operation>]

この記法を使うと、以下のようないくつかの特権を定義できる：

  • urn:automotivelinux.org:privilege:common:alarm:set
    いくつかのAGL ECU でアラーム設定するために使われる。
  • urn:automotivelinux.org:privilege:telematics:diagnostics:send
    ECUで“Telematics”プロフィールをでアクセスするために使われる。
  • urn:renesas.com:privilege:porter_ext:imu
    IMUチップにアクセスするために、Porterボードに拡張ボードを適用する。
  • urn:toyota.com:privilege:hybrid:energy:manage
    いくつかの製品範囲のために、OEMに定義されている特権の例です is an example of privilege defined by an OEM for some product range

AGLの特権のリストは書いた時点では決まっていない、が、異なる組み込みシステムで定義されている特権は開始ポイントで使われるだろう。：
AGLはおそらく、ベースの資源(5章？の網羅リストを見てください。)を保護するために、同じ特権分離を再利用または共有できるだろう。

2.2.Levels

すべてのインストールされたアプリケーションパッケージは正しい署名3を含んでいる。署名は主にパッケージの作者を識別し、ディストリビューターの署名も含んでいる場合もある。これらの署名を使用して、必要な"level"をもつ特定の作者のみが使用できる権限を設定できる。

言い換えれば、特権レベルは階層を導入する方法です。： 特定のレベルの特権は、パッケージ/アプリケーションの起源が必要なレベルを持つことがわかっている場合にのみ、インストール時にアプリケーションに付与することができます。

level.png

例えば、Tizenはplatform, partner, public の３つの特権レベルを定義している。：

  • “platform” は最も高い特権レベルです。platformの署名がされているアプリケーションは多くの定義された特権を使用できる。例えば、特権 “KEYGRAB” はplatformの特権です。
  • “partner” は、何らかの形の拡張特権を持つかもしれないが、"プラットフォーム "と比較して範囲が狭い仲介者です。
  • “public” は一番低い特権レベルです。このレベルのアプリケーションは、より高いレベルの特権を使用する権限は決してありません。

AGLでは, よく似た階層を持っている。

  • “vendor”: 最も高いレベルで、OEM特権アプリケーション用に予約されている。h
  • “tier1”: 中間レベルで。Tier1の特権が予約されている。
  • “partner”: 最も低いレベル。その他パートナー用に予約されている。
  • “public”: ベースのレベル。

2.3.Privileges Hierarchies/Dependencies

一方で、システムのために定義されたスタティックな特権の数が、異なるドメインの数と保護された操作の粒度のために重要かもしれません。(see in §5: ~100 for Tizen 2.x, ~130 for Android). 他方で、セキュリティルールが増えていくことはセキュリティホールになる(複雑でエンドユーザーが膨大な特権リストをレビューする時間がとれず、多かれ少なかれアプリケーションに盲目的になる？という事実のため)。 これは開発者にとっても面倒です(アプリケーションの特権リストを維持することが悪夢になるため)。 これらの事実を考えると、特権の階層を導入することはおもしろいかもしれない(階層化されたモデルで実行するのではなく)。例えば：

  • 特権をグループ化すると、Bluetoothをグローバルに有効/無効にしたり、単一の機能やプロファイルを許可/拒否することができるだろう。
  • 特権の階層化を導入すると、電話ディレクトリへの「書き込みアクセス権」をもつアプリケーションが、「読み出しアクセス権」を要求なしに自動的に承継することができる。
  • 抽象化の導入：ジオロケーションAPIを使うことは　GPSデータやUMTSネットワークジオロケーションへアクセスできることを意味する。

これは大きな利点をもたらす：

  • 開発者の視点では、アプリケーション構成ファイルを書くときに扱いが簡単になる。
  • 長期的には異質なシステムを扱うのにとても興味深い抽象化を作り出すことができる。：特権階層はアプリケーションによって宣言されているメタ特権を変えずに、時間とともに進化できる可能性がある。

注意：このトピックは進行中の作業であり、イン・アウトについてさらに研究していく価値がある。

2.4.Relationship with APIs

3.Cynara

4.Developing applications with privileges

5.Similar mechanisms on other systems

5.1.Tizen

5.2.Android

  1. DAC: Discretionary Access Control (POSIX user/group permissions)↩

  2. MAC: Mandatory Access Control (currently implemented with SMACK)↩

  3. http://www.w3.org/TR/widgets-digsig/↩