AppArmor調査

休暇から戻った。
SELinux vs AppArmorな雰囲気な今日この頃。
両者を比較するには、まず使わないと話にならない。
なので、AppArmorを試してみようと思う。
まずは文書を勉強。

情報源

• NovelのAppArmorのホーム
  • http://en.opensuse.org/Apparmor
• AppArmorの技術的概要
  • http://en.opensuse.org/AppArmor_Detail
• NovelForgeの最新版
  • http://forge.novell.com/modules/xfmod/project/?apparmor
  • ここのdocをダウンロードして生成されるmanページがかなり使える。
• OpenSuse
  • AppArmorはOpenSuseの最新開発版についてくるらしい。
  • http://en.opensuse.org/Development_Version よりOpenSuseの最新版をゲットして使うのがよさそう。

http://en.opensuse.org/AppArmor_Detail の読書感想文

● AppArmorの目標
http://en.opensuse.org/AppArmor_Detail
「AppArmor Goals」をみると…

• 1) セキュア
• 2) 高速
• 3) プログラム、ユーザに存在を意識させない(Transparency)
  • 使いにくいあまりオフにされるのが最悪と言っている。SELinuxへの当てつけか？(笑

● AppArmorによる解決
で上の目標がどう実現されてるか。
再び、http://en.opensuse.org/AppArmor_Detail

• セキュリティ

LSMを使っているから、MAC(アクセス制御が回避できないこと）が実現されており大丈夫だよ、
と言っている。
MACはある意味当たり前で、最小特権が重要だと思うが、
AppArmorでどこまで最小特権を実現できるかは書いてない。

• 高速

アクセス制御が単純だから早いといっている。

• Transparency

ポリシーの記述がわかりやすいからTransparencyが実現されていると言っている。

• • パス名ベース
  • ファイルパーミッションがわかりやすい
  • 加えてPOSIX capabilityを使っている

ここで生じた疑問。ネットワークはどうしているのか？？

● その他判明したこと

• AppArmorの設定をプログラム単位で外せる
  • 何がAppArmorに守られてないかはunconfinedコマンドで可能
• learningモードでポリシが生成できる
• ポリシーのことを「profile」と呼んでいる

アクセス制御モデル

subdomainというのを使っているらしい。
http://citeseer.ist.psu.edu/cowan00subdomain.html
にキャッシュされてた。微妙に違ってる気もする。
manページで最新の状況が分かった。
$man subdomain
$man sumdomain.d

アクセス制御できるものは以下。

• 1)ファイル

読み、書き、実行が可能。
実行は、以下の３種類。

• • px: 独自の権限でプログラムを実行
  • ix: 親の権限を継承
  • ux: AppArmor無効で(unconfined)実行
  • これから分かること。ドメイン遷移みたいなことやってるかも。pxパーミッションで実行しない限り独自の権限が割り当てられないから。プロセスの親子関係を意識しなければいけないところが、ドメイン遷移的。この部分はLIDSよりある意味複雑そう。

また、ファイルは「パス名ベース」で指定。
正規表現らしきものが使える。
正規表現なんか使って、実装が大丈夫かという懸念がある。
詳しい人は実装に突っ込み入れてほしい。

• 2) POSIX capability
• 3) ネットワーク
  • TCP connect
  • TCP accept
  • UDP send
  • UDP recv

の4種類を、ポート、ネットワークアドレス、NICの単位で制御できる。
むむ。Simplified Policyでこれから作ろうとしてるのと一緒だ。

あとは、#includeで、ポリシの使いまわし可能。
Simplified Policyでもこれはパクらなければな。

文書を読んだ限りの感想

• AppArmorの良い点

やっぱり、SELinuxよりはるかに単純。
Simplified Policyに近い。
SELinux陣営がrefpolicyなどを開発しているが、
AppArmorだったら、そんな大げさなことをやらなくても大丈夫だと思う。

seeditの、Simplified Policyもそうなるはず。Simplified Policyを無理にrefpolicyに合わせなくてもいいんじゃないかという気がする。

• AppArmorの悪い点

AppArmorは、「最強セキュリティ」は実現できないと思う。
すなわち、SELinux Symposiumで出てきた
1) 情報フローからかっちりポリシを設計
2) 設計図からポリシを作る
3) 作られたポリシは、いつでも情報フロー分析が可能
というような、形式的（数学的）に検証可能なセキュリティは実現不可能。
なぜかというと、、

• • パーミッションの粒度が粗い（情報フローの設計を実装できない部分がある）
    • 例えば、「a」パーミッションがない。プロセス間通信の制御をできない。
  • 情報フローの検証が難しい（ラベルベースじゃないから）
    • →を見るとなんとなく分かる http://marc.theaimsgroup.com/?l=selinux&m=110557207605125&w=2

また、ラベルベースじゃないから、LSPPでEALは取れない。
けどいつも思うのは、「EAL xxx」という数字しか表に出てこない。
これって、LSPPだろうが、もっと簡単なPPベースなのか分からない。
なので、世間の人は「EAL xxx」という数字しか見ないんだろうな(これってCCの欠陥だとよく思うのだけど)。
LSPPが差別化になるのは軍隊だけだろう。

改めて思ったこと。
SELinux: 最強セキュリティ
AppArmor: カジュアルセキュリティ
となっており、AppArmorを打倒することに意味を感じない。