AppArmor再燃

セキュアOS

AppArmorがLKMLに出されてスルー気味だったが、
また議論が再燃している。
今回は、TOMOYO Linuxの人たちも参戦してる。
SELinuxネ申が出てこないのが残念。彼は最近NSAのMLにも現れない休暇中だろうか。
再燃ポイントは↓。ここから派生している。
http://lkml.org/lkml/2007/5/23/304

以下、自分用メモも兼ねて。途中だけど。。

論点その１: AppArmor(AA)の妥当性

AppArmorのモデルは↓で解説。
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.html

このうち、論点になっているのは「3.2 Namespaces」。
ここを解読してみよう。
まず、namespaceとは。
kernel2.6の「per-process namespace」のことを言っている。
↓のstruct namespaceに格納されたデータのことか？
http://hira.main.jp/wiki/pukiwiki.php?namespace%2Flinux2.6
プロセス毎にルートを

以下引用と私の解読を。

From the point of view of a process, an absolute path is a path that goes all the way up to the root directory of that process. This is ambiguous if processes have different root directories. Therefore, instead of paths relative to process root directories, AppArmor uses paths relative to the namespace root.
Pathnames are meaningful only within a namespace. Each namespace has a root where all the files, directories, and mount points are hanging off from.

AAは絶対パスをパス名として使っていない。なぜならば、絶対パスでは一意に定まらないことがあるから。プロセスのルートディレクトリが違っていると一意で無いと言っている。
つまり、あるプロセスは
chroot /var/named/chrootして、/var/named/named.confで named.confにアクセスし、
あるプロセスは同じファイルの内容に
/var/named/chroot/var/named/named.conf
にアクセスする、ということか。
一意に定まらないという議論をすると、namespaceのルートからのパスでもハードリンクがあれば既に一意に定まらない気がする。
これを論点にするとAAに勝ち目が無い気がするが。。。
Linuxシステムで、一意に定まる識別子は、ラベル以外にないだろうし。

The privilege of creating new namespaces is bound to the CAP_ SYS_ ADMIN capability, which grants a multitude of other things that would allow a process to break out of AppArmor confinement, so confined processes are not supposed to have this privilege, and processes with this capability need to be considered trusted.
In this setup, privileged processes can still create separate namespaces and start processes in those namespaces; processes confinement will be relative to whatever namespace a process ends up in. It is unclear at this point how AppArmor should support separate namespaces -- either by computing all pathnames relative to one particular namespace considered global (assuming that such a globally meaningful namespace will exist in all setups in which AppArmor is relevant), or by allowing different sets of profiles to be associated with different namespaces.

AAの制限事項を教えてくれている？ありがとう（汗
CAP_SYS_ADMINがあれば、AAを破れると言っている？
まずい気がする。
CAP_SYS_ADMINはかなり粗いため、
与えざるを得ない場合が時々現れるので。
Capabilityも変えなきゃ駄目ですな。

これに関して、色々な人が噛み付いている。

論点２： argv[0]チェック

AAの人とTOMOYOの人がargv[0]の扱いについて議論してるみたいだ。
TOMOYO Linuxのargv[0]チェック
http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/2007-April/000095.html
http://lists.sourceforge.jp/mailman/archives/tomoyo-users/2006-July/000077.html
うーむ、ややこしい。
argv[0], filenameは本来は同じであるべき。
違う場合は、allow_argv0で許可しないと許されない。
http://tomoyo.sourceforge.jp/ja/1.4.1/policy-reference.html
のallow_argv0参照。

↑で出てきた例
exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
→lsのドメインでcatが走る
exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";
→lsのドメインでrmが走る

この例だと事実上悪さはできなそうだけど、問題は
「/bin/passwd用ドメインでシェルが走る」みたいな攻撃をされたらまずい，
ということか。