SELinuxは複雑か？−セキュアOSに関する考察(その２）

id:himainu:20050917 の続き。だいぶ前に書いていたのだが，アップを忘れてた
「複雑に見えないセキュアOSがあったならば，絶対に何かを犠牲にしている。一番犠牲になるのはセキュリティレベル」みたいに書いた。
その一例として，
セキュアＯＳのアクセス制御粒度における，セキュリティと利便性のトレードオフの例をいくつか。

セキュリティと利便性のトレードオフの例(1)

「ファイルタイプ遷移は分かりにくい」という話がある。
これは，「一時ファイルの保護」に必要である。「一時ファイルの保護」をしないなら不要になる。
例えば，LIDSの場合，/tmpに一時ファイルを作成する必要がある場合
「/tmp全体に書き込み可能」と設定する。これは単純である。しかし，「プログラムAが作成した一時ファイルを他と区別したい」という場合保護ができない。聞いた話だと，PHPなどは一時ファイルを/tmpに作るそうであるが，この一時ファイルに個人情報が入っていると，アウトである。
で， 「プログラムAが作成した一時ファイルを他と区別したい」という機能をLIDSに加えるとなると，結局ファイルタイプ遷移相当の新機能（/tmpに作成されるファイルに特殊なマークをつけるという設定）が必要となり，SELinuxと「tmpの保護」という点では難しさは差が無くなるはずである。

セキュリティと利便性のトレードオフの例(2)

「ドメイン遷移は分かりにくい」という話がある。
ただし，これは「同じ名前のプログラムに違った権限を与えるために必要なもの」
なのである。例えば，sshから起動したシェルとloginから起動したシェルの権限を変える，といったことをするために必要。
ドメイン遷移がないセキュアOS（例えばLIDS)の場合は，プログラム名とファイル名でアクセス制御をするが，プログラム名単位でしかできない。
もし，「同じ名前のプログラムに違った権限を与えたい」と思ったら，プロセスの実行履歴を示すマークをどこかにつけざるを得ず，結局ドメイン遷移と同じになってしまう。

セキュリティと利便性の落としどころ？

授業課題の現実逃避；）
意味不明なことを書いているかも…

とはいえ，セキュリティと利便性の関係は，線形ではないはず。
つまり，「ある一定のセキュリティを超えようとすると，急に利便性が損なわれる」という点があるはず。
これを見極めれば，セキュリティと利便性の落としどころがあるのだろう。
その一つが，「隠しチャネル(covert channel)」かもしれない。
隠しチャネルを防ごうと思うと，
何か属性を得るためのありとあらゆる操作を防ぐ必要が出てきて，
急に大変になる気がする。
例えば，「getsched(他プロセスのnice値を得る）」アクセスベクタ，
は，一方向隠しチャネル通信に使えそう。
setschedが可能なドメイン（A)が，setschedを使って，
情報を，nice値を使ってエンコードする。
getschedが可能なドメイン（B)が，getschedを使ってドメインAのnice値を得て，デコードする。
というわけで，隠しチャネルによる情報フローを防ぐためには，
「getxxx」系の操作を全部制御する必要がある。
そうなると，制御すべき操作，SELinuxでは，アクセスベクタが大変増えると思う。
そのわりに，「隠しチャネルがない」ということを保証するのは大変難しい。
Simplified Policyでは，
隠しチャネルを防ぐためのアクセス制御，
はやらないぐらいにしようかな。