Polyinstantiation

LSPP向けなど情報フロー制御をゴリゴリやっている人は、/tmpや/var/tmp等を経由して、機密レベルの高い区画から低い区画へとデータが流出するのを避けたいということで、ユーザのMLSレベルに応じて /tmp に別のディレクトリをマウントするという改造をやっているらしい。

彼らはその事を指して Polyinstanced Directory と呼んでいるのが、Polyinstantiationというのはそもそもデータベースの用語。

http://en.wikipedia.org/wiki/Polyinstantiation

通常、主キーを持っているテーブルにおいては、それによって唯一つのタプルを識別することができるが、Polyinstantiation化されたテーブルの場合は複数のタプルが存在しえる。そしてその場合、最終的にタプルを識別するのはセキュリティ属性ということになる。

前に James MorrisとSE-PostgreSQLについて話したとき、Polyinstantiation化テーブルのサポートも入れたらいいんじゃない？と言われたので、真面目に実装を考えてみることにする。

まず、この場合にセキュリティ属性となるのはMLSラベル以外にはあり得ない。つまり、テーブルの主キー＋MLSラベルが真の主キーとなる。
現状、SE-PostgreSQLにはセキュリティコンテキストを示す"security_context"列が存在するが、ここからMLSラベル部分だけを切り出して表示する"security_level"システム列を追加する。
システム列の内容は動的に生成して出力できるので、データ自体は"security_context"と同一だが、text型(文字列)でMLSラベルを表示すればよい。

そして、テーブルが作成された時に Polyinstantiation オプションが設定されていれば、SQLによって与えられた主キーに加えて"security_level"列を真の主キーとするよう設定する。

最後に、テーブルを検索する時に "security_level" が一致するタプルしか表示しないという制約を常に加えるようにする。若干疑問なのは、ここの制約は「クライアント＝タプル」でいいのか「クライアント≧タプル」でいいのか。この辺実はよく分かってない。誰か知っている人がいたら聞きたいんだがなぁ…。