情報フロー分析再考：パス名ベースのセキュアOSの弱点とSELinuxの留意点
http://d.hatena.ne.jp/himainu/20060419#1145484710
の続き。
ラベル vs パス名論争で、ラベルのほうがいい根拠として、
パス名は、情報フロー分析が不可能（ハードリンクがあるから）
というのがある。
seedit的にも分からなくなってきたので、ここでじっくり考察。
結論を言ってしまうと、
「パス名ベースのセキュアOSで継続的にセキュリティを保つには、
ハードリンクの生成を常に監視しつづけなければならない。」
というパス名ベースのセキュアOSの弱点が導かれた。
以下、結論に至る過程。
ハードリンクされた情報への情報フロー分析
/etc/shadow というファイルがあったとする。
このファイルの中身には、パスワード（のハッシュ)が格納されている。
/etc/shadowへのアクセスパスは、一意に定まらない。
/var/shadowにハードリンクされてたら、
/var/shadowからもパスワードにアクセスできてしまう。
このように、情報へのアクセスパスは複数存在する。
- パス名ベースのセキュアOSで、パスワードに誰がアクセスできるか？を分析したいとする。
- ラベルパス名ベースのセキュアOSで、パスワードに誰がアクセスできるか？を分析したいとする。
- /etc/shadowのラベルにアクセスできるドメイン一覧を検索
- 終わり。
となる。
パス名ベースのセキュアOSの情報フロー分析は大変で、
ラベルベースの情報フロー分析は簡単という主張になる。
この話が成り立つには、
パス名ベースのセキュアOSで、
「/etc/shadowに適切なラベル(タイプ）が割り当てられている」ことが大前提となる。
この前提がSELinuxで本当に満たされているのかを考察してみた。
初期状態について
初期状態とは、インストール時の「file_contexts」
/etc/shadow system_u:object_r:shadow_t
/var(|/.*) system_u:object_r:var_t
と書いてたとする。
すると、
/var/shadowに付与されるタイプは不定！
shadow_t, var_tのどっちがつくか分からない！
もしvar_tが付与されてしまったら、パー。
初期状態では、以下のように、全てのハードリンクに正しくタイプを付与する必要がある。
/etc/shadow system_u:object_r:shadow_t
/var/shadow system_u:object_r:shadow_t
で、インストール直後にfixfiles restoreを走らせ、ラベルを付ける。
ちなみに、ハードリンクがあって、ラベル付けが不定になる場合は、
ちゃんと警告が出てくる。
初期状態の後に作られたハードリンク
さて、この初期状態の後にハードリンクが作られた場合はどうなるのか？
ln /etc/shadow /usr/shadow
してみる。
/usr/shadowのラベルは、/etc/shadowと同じ。
これは、セキュリティ的には素晴らしい振る舞い。
情報フロー分析の前提が崩れることはない（パスワードの情報にshadow_tが付与されているという前提）
ただ、restorecon -R /var
をしてしまうと、
/var/shadow、/etc/shadowのラベルが、var_tになっちゃう!
初期状態後のrestoreconは望ましくないのである。
SELinuxで情報フロー分析可能の留意点
以上をまとめると、
SELinuxで情報フロー分析可能な状態にするには。。
- インストール時のfile_contextsをしっかり設定。
- 全ハードリンクを洗い出す必要がある(!) ← 重要
- 運用時にはrestoreconを使ってはいけない
- restoreconを使うときは，自分がどんなファイルのどんなラベルを変えようとしているのか正しく認識する必要がある
パス名ベースが劣る点は実際？
- 結局、SELinuxでも「初期状態」構築時に、全ハードリンクを洗い出す必要がある。
- パス名ベースは,「初期状態後」に弱味が。
- 初期状態後に、/etc/shadowのハードリンクを作られたら、穴ができてしまう。
- ★結論★これを防ぐには、常にハードリンクが作られてないか監視する必要がある
おお、パス名ベースが困る点がついに分かった！
LIDSは、ファイルの中身の識別にiノードを使ってるのでOK。
AppArmor, TOMOYO Linuxにはこの弱点が当てはまると思う(間違ってたら教えてください)
現実的に、この問題が起こる可能性、インパクトがどの程度あるのかが鍵だろう。
