社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

分散システムにおける Capability を用いた資源アクセス制御
橋本

正樹†

藤澤

一樹†

宮本久仁男†

金美羅†

辻秀典†,††

田中 英彦†† 情報セキュリティ大学院大学 神奈川県横浜市神奈川区鶴屋町 2-14-1†† 株式会社情報技研 東京都中央区日本橋小舟町 3-1
E-mail: †dgs074105@iisec.ac.jp
あらまし分散システムは、単一システムと比較して経済性、速度、冗長性、拡張性、柔軟性といった面で優れているため、その実現に向けて従来より多くの研究が行われてきた。しかしながら、それらの諸研究における実装の多く
はミドルウェアやアプリケーションのような上位層で実現されているために権限管理の粒度が粗くなり、システム全体に対する適切な安全性確保を困難にしている。このため本研究では、ディペンダブルな分散システムの構築を目的としたシステムソフトウェアによる細粒度の権限管理方式を検討する。また、その実装として Capability を利用した手法について検討する。
キーワード

アクセス制御、分散システム、ケーパビリティ

Capability-Based System for Distributed Environment
Masaki HASHIMOTO† , Kazuki FUJISAWA† , Kunio MIYAMOTO† , Mira KIM† , Hidenori
TSUJI†,†† , and Hidehiko TANAKA†† Institute of Information Security
2-14-1, Tsuruya-cho Kanagawa-ku, Yokohama
221-0835, Japan†† Advanced Institute of Information Technology, Inc.
3-1 Nihonbashi-Kobunacho, Chuo-ku, Tokyo
113-0024, Japan
E-mail: †dgs074105@iisec.ac.jp
Abstract This paper describes the use of operating system for the realization of distributed secure computing
infrastructure. In particular, it describes a few resource management schemes for distributed environment, addressing the ﬁne-grained protection and the principle of least privilege. These are compared each other in terms of thefeatures they oﬀer in the context of secure computing: Reference monitor concept, secure channel, authorizationand naming. Finally, we suggest a prototype of our system and the future plan.
Key words Access Control, Distributed System, Capability

1. は じ め にり、中でもセキュリティに関しては最小特権のセキュリティ原則 [1](PLP: Principle of Least Privilege) の適用が課題となっ分散システムは、単一システムによる情報システムと比較している。PLP は、システムをセキュアに構成するための設計指て経済性、速度、冗長性、拡張性、柔軟性といった面で優れて針となる概念であり、タスクの実行に最小限の資源のみを関与いる。そこで、その実現に向けた研究が 1960 年代より盛んにさせることによって、余分な特権によるシステムへの影響を防行われ、大きな成果をあげてきた。それらの諸研究はいずれもぐものである。PLP を実現するためには、タスクに関与するア

性能が重大なテーマのひとつであったが、この問題は昨今の基クセス主体／アクセス対象／実行内容を細かく制御できる必要

盤技術の進歩と共に大きく改善されようとしている。しかしがあるため、この機能は細粒度アクセス制御と呼ばれ、PLP を一方で、いくつかのテーマに関する研究は未だ発展途上にあ支える要素技術となっている。

—1—

このような立場から、筆者らは分散システムにおける PLPている SID とドメインによる追加の評価が行われる。一方で、の実現に向けた研究を行っている。本稿では、分散システムにUNIX と Flask は共にアクセス制御に利用するコードとデータおける細粒度アクセス制御に関して、設計要件の定義とそれにをシステム内の特別な保護領域に置くことによって、その安全基づいたアクセス制御モデルの提案を行う。PLP の要素技術性を担保している。

は、ポリシー記述法、細粒度アクセス制御、アクセス制御対象

PLP の実現を目指したこれらのアクセス制御機構は、セキュとなる実体の識別／認証であるが、特に細粒度アクセス制御にリティを考慮した情報システムにおいて利用されている。しか関しては、細粒度のアクセス制御を強制的に OS 層から実施す

し、その要素技術である細粒度アクセス制御は、システムの規るセキュア OS が大きな成果をあげて、一般にも普及し始めて模が大きくなるに従ってアクセス主体と資源に付与する属性のいる。しかし一方で、セキュア OS のアクセス制御機構は単一管理が煩雑になるため、拡張性に問題がある。加えて分散シスシステムでの利用を想定しており、分散システムへの拡張にはテムへの適用を考えた時には、ネットワークを介するためにア問題がある。

クセス主体／資源の認証や重要な情報の漏洩を防ぐような対策

そこで本研究では、分散システムにおいて細粒度アクセス制を行う必要がある。

御を実現するための要件を定義し、これに基づいたアクセス

2. 2 近年の研究

制御モデルを提案する。実応用での利用を考える時には、アク

PLP の実現は、セキュリティに関連する活発な研究テーマのセス対象の位置を特定する参照情報の扱いや制御情報の改竄、ひとつである。近年の研究では、アクセス主体や資源を表現す

Confused Deputy Problem [2], [3] などに耐え得る細粒度アクる専用のポリシー言語に関するもの [9]〜[11] や細粒度の強制ア

セス制御を行う必要がある。ここで Confused Deputy Problem

クセス制御機構に関するもの [8], [12], [13]、複数システム間のとは、アクセス制御を行うプログラムが不適切な制御によってセキュアな認証技術に関するもの [14], [15] に焦点があてられて本来意図された情報保護を行えない問題である。本稿では上記いる。これらの諸研究は、PLP の実現に寄与するものであり、の問題を解決するために Capability [4], [5] を用いた仕組みにつ実運用されているシステムで実装することによってセキュアないて検討する。

システム設計に有効であることを証明している。特に、細粒度

2. 関 連 研 究のアクセス制御機構に関してはセキュア OS と呼ばれる OS での実装が行われており、一般的なものになりつつある。しかし、本章では、はじめに PLP についてその概要と効果を説明す

これらのアクセス制御機構は単一システムでの利用を想定してる。その後、この領域に関する近年の状況を説明し、本研究といるものであり、分散システムでの利用に関してはシステムのの関連を述べる。

特性が大きく異なるため、問題がある。例えば、分散システム

2. 1 最小特権のセキュリティ原則

は情報の伝達経路にネットワークを利用するが、これは飽和す

PLP は、システムをセキュアに構成するための設計指針とる可能性があるので他の様々な問題を引き起こし得る。また、なる概念であり、タスクの実行に最小限の資源のみを関与させネットワークを利用した通信は単一システム内でのデータ交換

ることによって、余分な特権によるシステムへの影響を防ぐ。

に比べて秘密を守るのが難しい。そのため、現状の分散システ

PLP は、要素技術としてポリシー記述法や細粒度アクセス制

ムにおいては粒度の粗いアクセス制御が行われている。

御、アクセス制御対象となる実体の識別／認証を必要とし、中そこで、本研究では、必要十分なアクセス権限付与を行う新でも細粒度アクセス制御は、あらかじめ制御対象となる実体

しいカーネルと、それに基づいた分散システムにおけるアクセ

に対してポリシーに基づいた細粒度の属性を設定し、それをス制御モデルを提案する。提案モデルは、システムの各構成要

評価することによって行われる。ACL [6](ACL)、Capability、素に関するセキュリティ耐性を向上するものではなく、システ

Flask [7] といったものが細粒度アクセス制御機構の代表的なもムを権限に関して適切に区画化することにより全体としての強のであり、属性の設定方法や評価の仕組みがそれぞれに異なっ度向上を期待するものである。必要最低限のアクセス権限を付ているが、そのアクセス制御に利用するコードとデータを不正与するためには、細かい粒度のアクセス制御が必要であるが、な改竄から防ぐために特別な領域に保護している点で一致して分散システムでは制御すべき情報が膨大であるため、それら全いる。

て正しく把握し、制御するのが困難である。そのため従来の仕例えば、UNIX は ACL によるアクセス制御を行っているシ

組みでは、アクセス制御情報の大雑把なグループ化とそれに基ステムであるが、あるプロセスがシステム内のファイルをオーづいた大雑把なアクセス制御を実施している。そこで本研究にプンしようとするときには、システムがまずアクセス対象となおいては、アクセス主体を全て把握することの困難性に着目し、るファイルに設定されている保護ビットをアクセス主体に設定

Capability と呼ばれるチケットを利用することによって、分散されている実効 UID、実効 GID と照らし合わせ、アクセスがシステムにおける細粒度アクセス制御を目指す。

許可されているかどうかを評価する。また、Flask の一実装である Security-Enhanced Linux [8] においては、あるプロセス

3. 設 計 要 件がシステム内のファイルをオープンしようとするとき、システ

本研究においては、分散システムにおける細粒度アクセス制

ムはまず通常の UNIX システム同様のアクセス権限の評価を行御の実現を第一の目標とする。これは PLP に則した情報シスう。その後、システムコールがフックされ、Flask で設定されテムを構築するためであり、そのために提案モデルは一般的な—2—

認可システムとしての応用層からの利用も考慮する。この目標のために、本稿ではまず想定する分散システムの特徴を明確に

4. 提案システム概要した上で、その特徴から分散システムにおける細粒度アクセス

4. 1 想定システム構成

制御システムの機能要件を定義する。

提案システムの実装方式に関しては、既存の OS に対する拡分散システムにおいて現在一般的に利用されているアクセス張を想定している。通常 OS には、アクセス制御以外にも多く

制御モデルは、アクセス主体と資源の関係性に関して、その認の機能があるので、その全てをはじめから実装していくのは現

可情報をあらかじめ静的に定義できることを期待しているた

実的ではない。

め柔軟性に乏しく粒度も粗い。しかし、分散システムにおいて

本提案が想定する分散システムは、構造として同一の資源アは潜在的に無制限で流動的なアクセス主体、資源、その利用方

クセス制御機能を持つ OS の集合として構成され、それぞれの法が存在し得るため、認可情報を動的に扱える方が望ましい。

個別システムは分散システムにおける資源アクセス制御に必要

また、アクセス制御の粒度に関しては、現状のような計算機毎な情報を保持するための保護された記憶領域を持つものとすやプロセス毎といった単位では十分ではなく、トランザクショ

る。保護された記憶領域は TCB Boundary を形成するものでン下で実際にアクティビティを行う実体を管理できる必要がああり、提案する資源アクセス制御に必要なコードとデータ、加る [16]。そこで本研究において想定する分散システムは、柔軟

えてこれを実装する OS はこの中で保護される。

性の高い認可情報の扱いが可能であり、アクセス制御の粒度をアクセス主体による対象資源へのアクセスは、全て各個別シ

細かく保つためにプロセス内で無数に生成／削除され得る実体

ステム内の OS によって提供されるシステムコールを利用してを管理できるものとする。そのため、認可情報を上位の認める行われるものとし、アクセス主体はあらかじめ OS からシステ

範囲内で制限可能なものとし、子プロセスや生成／削除する実ムコールとして提供される手続きに引数のみを渡すことが可能

体に委譲できるような仕組みを用いるものとする。

である。結果としてあらゆる資源アクセスは OS によって捕捉

これらの要求に応えるために、提案モデルにおいては以下をされ、提案する資源アクセス制御機能によって検査される。

4. 2 提案する資源アクセス制御システムの構造設計要件とする。
参照情報と認可情報の不可分 : 参照情報と認可情報は不可分

提案システムは分散システムにおいて細粒度アクセス制御をに扱う。ACL のように、参照情報と認可情報を別々に扱ってア行うものであり、アクセス制御表を Service をアクセス制御対クセス制御の際に統合するような仕組みでは Confused Deputy

象とした Capability によって記述する点に特徴がある。

Problem を防ぐのが難しい。参照情報と認可情報が不可分であService は実際にアクセスされる資源を機能毎にグループ化

れば、アクセス主体は常に特定の目的の基に参照を行うため、した Object であり、資源の詳細情報を隠蔽する。分散システ

そのような問題が起こりにくくなる。

ムにおいてはアクセス制御の対象となる資源数が構成システム

動的なアクセス主体の生成 :

認可情報をアクセス主体に関連づける。ACL においては、アクセス主体に関する情報を別数に応じて増加するが、Service Object としてまとめることにより制御表を簡単にできる。

に扱うのでアクセス主体が頻繁に変化する場合は整合性を保つ

Capability は Service Object の Location と Access Modeのが難しい。アクセス主体が変化する頻度は粒度に依存するこを記述したデータ構造であり、システムの保護領域においてプとになるので、ACL ではプロセスをユーザアカウントなどのロセス毎に関連付けられる。Capability をローカルシステムに粗い実体にマップし、通常のオペレーションではあまり変化し保持することにより、分散システム内のあらゆる Object に対ないことを想定している。認可情報をアクセス主体毎に関連付する認可問い合わせをローカルシステム内で完結できる。

ければ、アクセス主体が頻繁に変化しても問題にならず、プロ

提案システムは ISO10181-3 をベースに拡張されており、コセス自身やプロセスの生成するより細かな実体を扱うことがで

ンポーネントの種別は可能な限り踏襲されている。それぞれ、きる。

Initiator は資源へのアクセス要求を最初に発行するシステム

アクセス主体の認可情報委譲 :新しく生成／削除される実内の実体を示し、Target はそのアクセス対象となる実体を示体に対して、アクセス主体が認可情報を委譲できるようにする。

す。また、Access Enforcement Function(AEF) は、Initiator

ACL においては、認可情報に対する編集能力が資源毎に関連から Target へのアクセス要求 (Access Request) を仲介する

付けられており、ひとつのアクセス主体に対する認可情報の編ことによってアクセス制御を強制するためのコンポーネント、

集能力は通常 ACL 全体の編集能力となる。アクセス制御の柔Access Decision Function(ADF) は AEF からの認可決定要求

軟性を保つためにはアクセス主体に関する動作をあらかじめ固(Decision Request) を受け取るコンポーネントを示す。図 1 に定できないので、認可情報をアクセス主体毎に委譲できるよう

おいて、ISO10181-3 アーキテクチャの概要を示す。

にする。
動的な資源の生成 :動的に生成／削除される資源に対して

5. 提案システムの構成

アクセス制御を行う。あらゆる情報システムは、資源の生成と5. 1 Architectural Overview

削除を繰り返しながら運用されるので動的な資源に対してのア

提案システムのアーキテクチャを図 2 に示す。本アーキテ

クセスを制限できる必要がある。

クチャは分散システムを構成しており、ISO10181-3 に Envi-ronment と Agent をコンポーネントとして加えたものである。
—3—

Initiator

SubmitAccessRequestPresent
AccessRequestAEF

Decision
Information

TargetADFA

Decision
RequestDecision
RequestDecision

ADF

図 1 ISO10181-3 Access Control Framework

Env.A

Env.B

AEFA

SubmitAccessRequestRemoteAccessRequestAgentA

SubmitProxy
AccessRequestAgentBTCB Boundary

TCB Boundary

SystemA

SystemB

Initiator

ADFB

TargetInformation
DecisionTargetInformation
Decision

SubmitAccessRequestDecision
RequestAEFB

Present
AccessRequestTarget

図 2 Architectural Overview

Initiator、Target、AEF、ADF の基本的な役割は ISO10181-3と同等であり、Environment は Initiator の Capability 情報とTarget の Location 情報を保持する。また、Agent はリモートシステムの Agent に対する安全な情報伝達を担うものであり、またリモートシステムにおいては Target に対して Initiator の代理アクセスを行う。
図 2 は SystemA の Initiator によって生成された Access Re-

quest が SystemB の Target に到達するまでの手順を含んでおり、以下にその概要を示す。

Step 1 Initiator は AEFA に Access Request を行う。
Step 2 AEFA は Initiator から Access Request を受け取
り、ADFA に Decision Request を行う。

Step 3 ADFA は AEFA から Decision Request を受け取り、Env.A に保持されている情報を元に Decision を生成してAEFA に返す。
Step 4 AEFA は ADFA から Decision を受け取り、Env.Aに保持されている情報を元に Service の Location を解決する。

Step 5 AEFA は AgentA に Remote Access Request を行う。

Step 6 AgentA は AEFA から Remote Access Request を受け取り、AgentB に Proxy Access Request を行う。

Step 7 AgentB は AgentA から Proxy Access Request を受け取り、AEFB に Access Request を行う。

Step 8 AEFB は AgentB から Access Request を受け取り、
ADFB に Decision Request を行う。
Step 9 ADFB は AEFB から Decision Request を受け取り、Env.B に保持されている情報を元に Decision を生成してAEFB に返す。
Step 10 AEFB は ADFB から Decision を受け取り、Env.Bに保持されている情報を元に Service の Location を解決する。

Step 11 AEFB は Target に Access Request を行う。
5. 2 Initiator
Initiator は Access Request を発行するプロセスであり、希望
する Service Name と Operation Name を知っている。Initiator
は AEF に Service Name と Operation Name を含む Access

Request を行い、Location の解決と認可決定を委ねる。Access
Request が認可された場合は、AEF から Access Responce を受け取る。

5. 3 Target
提案システムの Target は、Service として機能毎に資源をグループ化した Object である。Target は AEF から Access

Request を受け取り、Responce を返す。Target は複数の資源が連携することによって機能するものであり、Service Table

Directory に登録されることによって他システムからの利用が可能となる。Service Object の詳細な構成と受け入れ可能な

Operation は、Service 毎に規定される。
5. 4 Operation
Operation は Target に対して要求する操作種別である。Operation は Service Object 毎にインターフェースとしてあらかじめ提供されるものであり、Access Request に対して Responceを返す。

5. 5 Access Enforcement Function
AEF はアクセス制御対象となる資源へのアクセスを仲介するコンポーネントであり、ADF による認可決定を Initiator に強制する。

AEF は TCB Boundary の内側にあり、外側に対して定型化された手続きを提供する。外側のアクセス主体は、AEF から提供される手続きに変数を渡すことによってのみ資源にアクセス可能であり、AEF は資源への実アクセスに関わる詳細な手
続きとデータを隠蔽する役割を果たす。また、AEF は ADF から受け取った Capability を元に Target の Location 解決を行い、Location がリモートシステムであった場合は Agent に代理アクセスを依頼する。Location がローカルシステムであった
場合は、システムファンクションを利用して実際に資源へのア
クセスを行う。
以下に AEF の動作手順を示す。

Step 1 AEF は Initiator から Access Request [Initiator
Name : Service Name : Operation Name] を受け取る。
Step 2 AEF は ADF に Decision Request [Initiator Name
: Service Name : Operation Name] を行う。
Step 3 AEF は ADF から Decision [Capability or Reject]を受け取る。

Step 4 AEF は Capability の Directory Index と Service
Table Directory から Service の Location を特定する。
Step 5 AEF は Capability と Location から [Location :Table Index : Operation Name] を生成する。
1 [Location → Local]（図 3 参照）

Step 6 AEF は Service Table と Table Index から Service
Object を特定する 。

—4—Capability

ADF

Present
AccessRequestAEF

Object Descriptor

Decision Request

Target[Initiator Name : Target
Name : Op.Name : ...]

AEF

Decision

ADF[Capability or Reject]
Service Table
Directory

Service Table[Dir.Index : Table Index :Op.Name : ...]

[Op.Name : ...]

Initiator Table

Capability List

Env.
図 3 AEF Local Access

Capability

ADF

RemoteAccessRequestAEF

Object Descriptor

Env.
図 6 Inputs and Outputs to ADF

Agentの Decision Request に対して Decision を返す。ADF は TCB

Boundary の内側にあり、AEF と Environment から認可決定

Service Table
Directory[Dir.Index : Table Index :Op.Name : ...]

[Location : Table Index :Op.Name : ...]

Env.

に必要な情報を収集する。
以下に ADF の動作手順を示し、図 6 に ADF に入出力される情報の概略を示す。

Step 1 ADF は AEF から Decision Request [Initiator Name

図 4 AEF Remote Access: Service Name : Operation Name] を受け取る。
Directory Index

XXXX

Table Index

XXXX

Capability

Step 2 ADF は Initiator Name を元に、Environment に保持されている Initiator Table から特定の Initiator Descriptor

Object Descriptorを抽出する。

Step 3 ADF は Initiator Descriptor から Initiator Name にObject Descriptor

Service Table Directory

関連付けられた Capability List(C-List) を特定する。
Service Table

Service Object

図 5 Service Location Transition

Step 4 ADF は C-List の各 Capability を検索し、Service
Name と Operation Name を含む Capability を特定する。
Step 5 ADF は Capability を特定した後に Decision として

Step 7 AEF は Service Object に対して Operation を実行
し、Responce を Initiator に返す。

2 [Location → Remote]（図 4 参照）

Step 6 AEF は Agent に [Location : Table Index : Operation] を渡して Remote Access を依頼する。
Step 7 AEF は Agent から Responce を受け取り、Initiatorに返す。

[Capability] を返すが、必要が Capability が見つからなかった
場合は Decision として [Reject] を返す。

5. 7 Agent
Agent は分散システムを構成する各システムに存在し、自システム以外のシステムに存在する Agent と通信を行う。各

Agent はあらかじめ互いを識別することができ、各 Agent 間は安全な通信を行うことができる。Agent は自システムの AEF
から外部システムに存在する Service Object へのアクセス要求

図 5 に Capability から Service Object を特定する様子を示を受け取り、他システムの Agent に代理アクセスを依頼する。

す。AEF は以下の手順に従って、Service Object を特定する。

代理アクセスを依頼された Agent は、あらためて Initiator とStep 1 AEF は ADF から Capability [Directory Index :して自システムの AEF に Service Name と Operation Name

Table Index : Operation Name : ...] を受け取る。
Step 2 AEF は Directory Index を元に、Environment に保持されている Service Table Directory から特定の Service

Table Object に関する Object Descriptor を抽出する。
Step 3 AEF は Object Descriptor を元に、Service Table
を特定する。

Step 4 AEF は Table Index を元に、Service Table から特定の Service Object に関する Object Descriptor を抽出する。

Step 5 AEF は Object Descriptor を元に、Service Objectを特定する。

によるアクセス要求を行い、Responce を元の Initiator に返す。
以下に Agent の特徴を示し、図 7 にその概略を示す。

•

Agent は各システムに存在する外部アクセスを行うシス

テムプロセスであり、各 Agent 間はあらかじめ互いを識別することができる。

•

Agent は Local AEF から Remote AEF まで安全な情報伝達経路を保証する。

•

Local Agent は Local AEF から Remote Access Re-

quest を受け取り、Remote Agent に中継する。
•

Local Agent から Remote Access Request を受け取った

5. 6 Access Decision Function

Remote Agent は、Remote Host で Target への Proxy Access

ADF は認可決定を行うコンポーネントであり、AEF から

を行う。

—5—

Responce Agent

AEF•

RemoteAccessRequestRemoteAccessRequestAgent Responce

Service Table Directory はひとつだけ存在し、分散シス

テムを構成する各ホスト間で共有される。
AEF

5. 8. 3 Service Table
Service Table は、各 Service Object 対応にあるエントリ

RemoteAccessRequestResponce Agent

AEF(Object Descriptor) を管理する。各エントリは、Length や IP

RemoteAccessRequestAgent Responce

AEF

Address 等の Service Object に関する属性情報を記述したデータ構造であり、アクセス制御の際には AEF によって利用される。Service Table は、Object Descriptor に記述された Base

図 7 Communication between Agents•

Object の特定される。
Remote Host で AEF から Responce を受け取った Re-

mote Agent は、Local Agent へ中継する。
•

Remote Agent から Responce を受け取った Local Agent

は、Local AEF へ Responce を中継する。

5. 8 Environment
Environment は TCB Boundary の内側で保持されるシステ
ムに関する属性情報の集合である。Environment は分散システ
ムを構成する各ホスト毎に構成され、アクセス制御を行う際に各コンポーネントによって利用される。

5. 8. 1 Initiator Table
Initiator Table は各 Initiator 対応にあるエントリ (Initiator Descriptor) を管理する表である。各エントリは Initiator
Name、Initiator ID、Initiator Group 等の Initiator に関する属性情報を記述したデータ構造であり、アクセス制御の際にはADF によって Initiator Name を Key に検索される。Initiator
Descriptor には C-List が格納された記憶領域へのポインタが含まれており、ADF による Capability の特定に利用される。
以下に Initiator Table の特徴を示す。

•

Initiator Table はシステム内の各 Initiator の属性情報を管理する表である。

•

Initiator Table は分散システムを構成する各ホスト毎に管理される。

•

Initiator Table は ADF によって参照される。

•

Initiator Table は C-List へのポインタを含んでいる。

5. 8. 2 Service Table Directory
Service Table Directory は、各 Service Table Object 対応にあるエントリ (Object Descriptor) を管理する。各エントリ
は、Length や IP Address 等の Service Table Object に関する属性情報を記述したデータ構造であり、アクセス制御の際には AEF によって利用される。Service Table Directory は、あらかじめ Environment に保持された Base Address によってAEF に指定され、Capability による Service Table Object の特定に利用される。
以下に Service Table Directory の特徴を示す。

•

Service Table Directory は Environment 内に保持され、あらかじめ設定された Base Address を元に指定される。

•

Service Table Directory は Service Table Object に関する属性情報の集合である。

•

Address によって AEF に指定され、Capability による Service

Service Table Directory は AEF によって Service Tableの Location 解決に利用される。

以下に Service Table の特徴を示す。

•

Service Table は Service Table Directory の Object De-

sciptor に記述された Base Address によって指定される。
•

Service Table は Service Object に関する属性情報の集

合である。

•

Service Table は AEF によって Service Object の Lo-

cation 解決に利用される。
•

Service Table は分散システムを構成する各ホスト毎に管理される。

5. 8. 4 Capability
Capability は、Service Object の Location と Operation を指定するものである。Initiator は、Capability を通じて Ser-vice Object の Location と Operation を指定するため、あるInitiator に関連付けられた Capability の集合はその Initiatorが利用可能な Service Set を規定するものである。Capability
は Service Name、Operation Name、Directory Index、Table

Index を含むものであり、Service Object の認可決定の際はADF に参照される。また、Service Object の Location 解決の際には AEF に参照される。
以下に Capability の特徴を示す。

•

Capability は Environment 内に保持される Initiator に関する属性情報のひとつである。

•

Capability は Initiator Table と C-List によって各 Ini-

tiator に関連付けられて保持される。
•

Capability は Service Name、Operation Name、Direc-

tory Index、Table Index を含む。
•

Capability は ADF によって Initiator の認可決定に利用

される。

•

Capability は AEF によって Service Object の Location

解決に利用される。

5. 8. 5 Capability List
C-List は Environment に保持され、Initiator Table において Initiator 毎に関連付けられる。C-List は Initiator が保持する

Capability の集合であり、各 Initiator の Initiator Descriptor
からポイントされる。
以下に C-List の特徴を示す。

•

C-List は Environment 内に保持される。

•

C-List は Initiator Table において各 Initiator に関連付

けられる。

•

C-List は Initiator Descriptor からポイントされ、AEF—6—なった。この 2 つのテーブルは、OS の一部として保持される

Decision Request
Initiator

Env.

Submit Access Request[service name : op. name :params]AEF[initiator name : service name :op. name]

Decision

ADF[dir. index : table index]

ので不正な改竄を防止することが可能であり、同じく保護された Capability に含まれるインデックスを経由して利用される。

C-List Lookup [initiator name]アクセス制御の粒度 :Initiator Table C-List [pointer to capability segment]
Capability Lookup [service name : op. name]

提案システムにおいては、アクセス主体に提供する機能を基本単位とした Service に対象資源のグループ化を行い、その粒度においてアクセス制御を行うことがCapability List Capability [data structure of capability]

可能である。また、アクセス主体に関しては、それぞれのアク
図 8 Decision Making Procedure
Decision

ADF[dir. index : table index]

セス主体毎に Capability の有無が制御情報となるので、結果としてグループ化は行わないものとなった。提案システムは通AEF

Service Table Lookup [dir. index]

Env.

Service Table
Directoryを行うものである。

Service Table Location[ip address : base address of service table]

Service Object Lookup [table index]

Service Table

常の UNIX より粒度の細かい資源アクセス制御が可能であり、Security-Enhanced Linux よりは粒度の粗い資源アクセス制御

7. 今後の課題

Service Object Location[base address of service object]

図 9 Location Looking up Procedure

本研究では、分散システムにおける細粒度アクセス制御に関して、Capability-Based System の手法を取り入れた仕組みを検討した。分散システムも Capability-Based System も共に古と ADF によって参照される。

•

C-List はある Initiator が保持する Capability の集合である。

5. 9 処理の流れ

くから研究されてきたテーマであり、既に多くが確立されている分野であるが、昨今の技術革新とセキュリティへの要望の高まりを背景に融合・再考を試みた。
提案システムでは、Capability を利用した分散システムのア

提案システムにおいては、分散システム上で細粒度アクセス

クセス制御メカニズムを示したが、今後はポリシーから各種制制御を実現するために ADF において 5. 6 に示した Capability

御表を生成する仕組みと 5. で示した Agent に関して、Agent

チェックが実施される。この Capability チェックは、すべて間の安全な通信手法の詳細化が問題である。今後はこれらを課ADF が提供するインターフェースを利用して行われるもので題とするが、特に重要な点を以下に示す。

あり、Initiator が直接このインターフェースを呼び出すことはできない。
図 8 に Capability チェック時における各コンポーネント間の連携の様子を示す。

表とリストの初期化／変更方法 :Service Table Directory、Service Table、C-List の正しい初期化は、提案システムが期待通りに動作するための前提となるものである。提案システムにおいては認可決定をローカルシステムに保持された Capability を

Service の Location 解決は Capability から AEF が行い、Lo-参照をすることにより判断するものであるが、これには C-List

cation が Local であった場合は、システムファンクションを利があらかじめ正しく初期化されている必要がある。資源参照

用して AEF が Service Object へのアクセスを行う。Locationの際の Location 解決においても、Service Table Directory とが Remote であった場合は、Agent が提供するインターフェー

Service Table があらかじめ正しく初期化されている必要があスを呼び出し Remote Access を依頼する。

るので、これらの各データを初期化する仕組みは非常に重要な

図 9 に Location 解決時における各コンポーネント間の連携の様子を示す。

6. 提案システムの評価ものである。
また、提案システムにおいては、Service Table Directory、Service Table、C-List によって認可情報と Location 情報が静的に各システムにおいて保持されるが、これらの情報が一定に

資源情報の保持 : 提案システムにおいては、資源情報を全体として保持する共通領域に一括して置くのではなく、Capability

固定され続けるような情報システムは考えにくいので、必然的に変更方法も検討する必要がある。

に含んで各個別システムに分配する。Capability は各個別シス

Agent 間通信の動作メカニズムとプロトコル : Agent 間通テム毎に OS の一部として保持されるので、不正な改竄を防止

信は、提案システムにおいて各構成システム間の相互識別と安することが可能である。また、各個別システム内で保持される全な情報伝達を担うものであり、Capability による認可決定とCapability は、そのシステム内のアクセス主体が分散システム

Location 解決を確実に実施するための鍵となる。提案システムのポリシーによってアクセスを許可されたものだけであるので、においては、あるシステムの ADF による認可決定が Agent を

結果として各個別システムはシステム内の全アクセス主体がア

通じて他システム内で実施されるので、Agent 間通信が信頼でクセス可能な資源情報のみを保持することとなった。

きない限りは成り立たないものである。

資源の参照方法 : 提案システムにおいては、Service Table

また、以下にその他の検討項目を列挙する。

Directory と Service Table を利用することにより、分散シス•

Initiator Table と Initiator Descriptor の詳細な内容

テム全体の資源に対して一貫した資源参照を行うことが可能と•Service Table Directory と Service Table、Object De—7—

scriptor の詳細な内容•

Capability と C-List の詳細な内容
文献[1] Peter J. Denning, “Fault Tolerant Operating Systems”,
ACM Computing Surveys (CSUR), v.8 n.4, p.359-389, December 1976.
[2] N. Hardy. The KeyKOS Architecture. ACM Operating Systems Review, September 1985, p. 8 - 25.
http://www.agorics.com/Library/KeyKos/architecture.html[3] N. Hardy. “The Confused Deputy (or why capabilities might
have been invented)”. Operating Systems Review 22(4), October 1988, pp. 36 - 38.
[4] Jerome H. Saltzer, and Michael D. Schroeder. “The Protection of Information in Computer Systems”. In Proceedingsof the IEEE 63, 9 pp. 1278 - 1308. September 1975.
[5] J. B. Dennis and E. C. Van Horn, “Programming Semantics
for Multiprogrammed Computations”, Comm. ACM, 1966.
[6] Jerome H. Saltzer, “Protection and the control of information sharing in Multics”, Comm. ACM, 1974.
[7] Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen, Jay Lepreau, “The Flask Security Architecture: System Support for Diverse Security Policies,”
USENIX, August 1999.
[8] “Security-Enhanced Linux”, NSA.
http://www.nsa.gov/selinux/[9] A. Keromytis, S. Ioannidis, M. Greenwald, and J. Smith,“The strongman architecture,” In Third DARPA Information Survivability Conference and Exposition (DISCEX III),
April 2003.
[10] Matt Blaze, Joan Feigenbaum, Martin Strauss, “Compliance Checking in the PolicyMaker Trust Management System,” Financial Cryptography 1998, Anguila, 1998.
[11] Matt Blaze, Joan Feigenbaum, Angelos D. Keromytis,“KeyNote: Trust Management for Public-Key Infrastructures,” In Proceedings of the 1998 Security Protocols International Workshop, Springer LNCS vol. 1550, pp. 59 63. April 1998, Cambridge, England. Also AT&T Technical
Report 98.11.1.
[12] “AppArmor”, Novell, Inc.
http://en.opensuse.org/Apparmor[13] ”TrustedBSD home page,“TrustedBSD Project.
http://www.TrustedBSD.org/[14] M. Y. Becker and P. Sewell. “Cassandra: Distributed access
control policies with tunable expressiveness”. In 5th IEEE
International Workshop on Policies for Distributed Systems
and Networks, 2004.
[15] E. Bertino, E. Ferrari, and A. C. Squicciarini. “TrustX: A peer-to-peer framework for trust establishment”.
IEEE Transactions on Knowledge and Data Engineering,16(7):827 - 842, Jul. 2004.
[16] 辻 秀典, 橋本 正樹, 金 美羅, 田中 英彦. “アプリケーション・プ
ラットフォームとしてのセキュア OS に関する初期的検討”. 情報処理学会 第 38 回コンピュータセキュリティ研究会, 2007 年 7月.

—8—