Capability-based security
最大の問題は、capabilityを保持するはずのプロセス、ファイル等の実体を、(capability によって代表される)セキュリティ情報の一貫性を保った形で永続的に維持できないことである。ユーザプログラムがオブジェクトへの参照やアクセス権を改竄しないことを、OS側では信頼することができない。そのため、ユーザプログラムが再度ディスク上にあると参照されているオブジェクトに対しアクセスを試みる際にOSはアクセス要求が正当なものか検査しなければならない。そのためACLや類似のものが必要になる。
実体の永続性がないという問題を解決する新しいアプローチが orthogonally persistent OSである(Flexマシンとして実現された。en:Ten15参照)。この種のシステムでは、実体は破棄される必要がなく、capability も無効になる必要がない。従って後に利用するためcapabilityをとっておくためのACL類似の機構も必要でない。OSは、揮発性のも不揮発性のも、全てのストレージについて常時capabilityの一貫性とセキュリティを維持するが、その一部はシリアル化(ここでは、データ等をネットに流せるようなタイプの一連のビット列に変換すること)作業をOSそれ自体が行い、ユーザプログラムに任せないことによる(ほとんどのOSではユーザプログラムが行う)。そのため、ユーザプログラムが合法的な capability だけを再生産すると信じる必要も、アクセス制御を用いてユーザプログラムからの要求を確認する必要もない。
Capability は オブジェクトの一種である。capability を所有しているユーザプロセスに限って、あるオブジェクトと何らかの相互作用を起こすための能力(あるいは名前)を得ることができる。相互作用とは、オブジェクトに関連するデータを読んだり、オブジェクトに変化を加えたり、オブジェクト内のデータをプロセスとして実行したり、といったアクセス権を必要とするような操作をいう。論理的には capability を構成するものは、ある特定のオブジェクトを一意に特定する参照と、一つまたは複数のアクセス権の集合である。
例えば、メモリ内にある一つのユーザプロセスに次のような文字列があるとする:
これはシステムの中のあるオブジェクト(パスワードを保管するのに用いられるファイル)を一意に特定するが(つまり上記の「参照」ではある)、アクセス権を特記していないので、capabilityではない。ここで、上記に代わって次の二つの値を考える:
一つのオブジェクトとアクセス権の集合とが一緒になっている(O_RDWRは「読み取り書き込み両用オープン」。パスワードファイルを読んだり変更したりできる状態で開く)。これでもなお capability ではない。というのもユーザプロセスがこれを「所有」したからといって、アクセスが実際に合法的なものになるのかはわからないからである。
さて、新たに次の文を考えよう。ユーザプロセスがこれを成功裡に実行できたとする(open関数はOSから受け取ったファイル記述子を返す。副作用としてファイルを実際に開ける):
この時点で変数fdはプロセス用ファイル記述子テーブル中のあるファイル記述子への添字を含んでいる。