読者です 読者をやめる 読者になる 読者になる

The 2006 Linux Kernel Summit [Security]

OSS/Linux

Linux Weekly News中の、The 2006 Linux Kernel Summitの記事の中に、Kernel Summit 2006: Securityの記事がある。

例のSELinux vs AppArmorのバトルが場を変えて再び繰り広げられたということだが、議論の内容をフォローアップするのに程よくまとめられている。
以下は、その要約の要約。

議題は以下の2つだったが、1はスルーされた。

  1. AppArmorが本流カーネルにマージされるには何が必要?
  2. LSMは削除されるべきかどうか?
SELinux派(Stephen Smalley)は、本流カーネルにLSMのユーザは唯一SELinuxだけであり、これは不要な抽象レイヤであると主張。一方、AppArmor派(Tony Jones)はSuSEのプロダクトで広く使われている。

AppArmorの特徴がNetwork-Serverの保護を指向したEasy-Configurationであるという点について、Christoph Hellwigは「セキュリティはそもそも難しいのだから簡単な設定などあり得ない」と開き直った。
Stephen Smalleyはパス名ベースの設定が危険であることを主張したが、必ずしも賛同を得られなかったらしい。また、Linusを含む開発者はそれを理由としてAppArmorをドロップすべきではないと考えたようだ。
パス名ベースの問題点として、Hardlinkの問題が指摘されたが、AppArmorがHardlink作成の許可/禁止を制御下に置いているなら大丈夫ではないかということに落ち着いた様子。

LSM不要論に関して、StephenはSELinuxをLSM無しで実装できるとしたが、Tonyは「AppArmorをSELinuxフレームワークとして利用して実装することは不可能であり、AppArmorはLSMを必要としている」と主張。
Linusは「この種の論争を避けるためにLSMを導入した。よってLSMをカーネルの中に残しておこう」と結論付けた。



私も以前、パス名ベースの設定方法を指向していたことがあったが、Stephenから言われてなるほどと思ったのが、UNIXパーミッションPOSIX-ACLもinode(=オブジェクト自身)に付けられた属性であって、Linuxではinodeを単位としてアクセス制御を行うのがノーマルな方法であるということ。
確かにパス名基準にすると、Hard-LinkやVFS-Namespace、Bind-mountの扱いで例外的なことをごにょごにょする必要がでてきて美しくない。
(※)他にも、パス名を持たないオブジェクトに対する記述が困難という問題もある。
ただし、それを理由として他のモデルを排斥するのには賛同できない。唯一のセキュリティポリシーを決める必要などないし、何よりライバルがいないと面白くない。

それにしても、LWN.netの記事を見ている限り、Linux Kernel Summitの議論ではAppArmor派の方が優勢に議論を進めたようだというのが何よりオドロキ。
結論として「パス名ベースを理由として本流カーネルに入れないということはない」「LSMはカーネルに残す」という結果を得られたのは大きいと思う。