Capability-based security入門
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/02/03 00:49 UTC 版)
「Capability-based security」の記事における「Capability-based security入門」の解説
Capability は オブジェクトの一種である。capability を所有しているユーザプロセスに限って、あるオブジェクトと何らかの相互作用を起こすための能力（あるいは名前）を得ることができる。相互作用とは、オブジェクトに関連するデータを読んだり、オブジェクトに変化を加えたり、オブジェクト内のデータをプロセスとして実行したり、といったアクセス権を必要とするような操作をいう。論理的には capability を構成するものは、ある特定のオブジェクトを一意に特定する参照と、一つまたは複数のアクセス権の集合である。 例えば、メモリ内にある一つのユーザプロセスに次のような文字列があるとする: /etc/passwd これはシステムの中のあるオブジェクト（パスワードを保管するのに用いられるファイル）を一意に特定するが（つまり上記の「参照」ではある）、アクセス権を特記していないので、capabilityではない。ここで、上記に代わって次の二つの値を考える: /etc/passwd O_RDWR 一つのオブジェクトとアクセス権の集合とが一緒になっている（O_RDWRは「読み取り書き込み両用オープン」。パスワードファイルを読んだり変更したりできる状態で開く）。これでもなお capability ではない。というのもユーザプロセスがこれを「所有」したからといって、アクセスが実際に合法的なものになるのかはわからないからである。 さて、新たに次の文を考えよう。ユーザプロセスがこれを成功裡に実行できたとする（open関数はOSから受け取ったファイル記述子を返す。副作用としてファイルを実際に開ける）: int fd = open("/etc/passwd", O_RDWR); この時点で変数fdはプロセス用ファイル記述子テーブル中のあるファイル記述子への添字を含んでいる。このファイル記述子（具体的にはfd）は capability である。このファイル記述子がプロセス用ファイル記述子テーブルに含まれることさえわかれば、そのプロセスにはそのオブジェクト（ここではファイル）への合法的なアクセスを持つことが確実にわかるからである。この方法だと、ファイル記述テーブルがカーネルに存在し、ユーザプログラムからは直接操作できないことに注目して欲しい。OSは、システム内の capability が特定の操作しか受け付けないことを、確実に保障しなければならない。それを怠るとセキュリティポリシーにおけるシステムの一貫性が維持できなくなる。 伝統的なOSではしばしば、プログラムは別のプログラムあるいはストレージと最初の二例のような参照を通して連絡しあう。パス名はコマンドラインパラメタとしてソケットを通してディスクに保存される。これら参照は capability ではなく、使用を許可する前にその有効性を確認しなければならない（あるディレクトリを触るのにパスワードを要求する等）。これらのシステムでは、中心となる質問は「誰の」権限 authority によって「任意の参照を評価することになるか?」である。二つの異なる権限をもったエンティティのために動作するプロセスにおいて、これは危険な問題になり、「混乱した使節の問題」Confused deputy problemとして知られるバグを引き起こす。これは極めてしばしばセキュリティホールの原因になるバグである。 capability-based system では、capability それ自体がプロセスやストレージ間でやりとりされ、やりとりにはOS監視下に一貫性をもって統合されたセキュリティーメカニズムが働く。
※この「Capability-based security入門」の解説は、「Capability-based security」の解説の一部です。
「Capability-based security入門」を含む「Capability-based security」の記事については、「Capability-based security」の概要を参照ください。
- Capability-based security入門のページへのリンク
