ソースを表示

=== LSM（Linux Security Modules Interface）を通じたセキュリティ ===

（回避不可能な）セキュリティを実現するためには、AppArmorのような仲介手段（mediation methods）はカーネル内部に組み込まれていなければなりません。元々、AppArmorはカーネル・パッチでしたが、特にエンタープライズ（企業）ユーザーにとっては、それが配布やシステムへの導入における大きな負担となっていました。カーネル・パッチを必要としないカーネル・レベルのセキュリティを実現するため、イミュニクス社（ノベルに買収される前のAppArmorの開発元）は、Linux 2.6カーネルでLSM（Linux Security Modules）インターフェースと呼ばれる機構を開発しました。LSMは、カーネル・モジュールに効率的なアクセスコントロールを仲介できるようにカーネルAPIを提供します。その他のLSM開発参加者には、SELinuxコミュニティやIBM、そしてさまざまなオープンソース・コミュニティの開発者たちが含まれます。

ライブラリなど、カーネル以外のレイヤーにおける仲介は、それを回避することを可能にしてしまいます。仮に、最小権限によって動作が制限されたアプリケーションであっても、攻撃者が任意のコードを実行できる（バッファ・オーバーフローなどの手段によって）ならば、彼らはライブラリを使わず、仲介を回避して直接カーネルを呼び出すでしょう。さらに言うと、カーネルの奥深くで行われるAppArmorのような仲介は、システムコールの遮断よりも良いものです。安全な仲介はsyscall tableの置き換え（as is done in [http://www.citi.umich.edu/u/provos/systrace/linux.html Systrace]）により実現されます。ただし、それは3つの重大な問題を誘引します：
* ''コード詰まり（Code Embolism）''：カーネルは、基礎的な機能（インフラストラクチャー）をたくさん備えています。例えば、「foo」という名のファイルを開けという要求があった場合に、カレント・ディレクトリ（現在作業中のディレクトリ）などを考慮したうえで固有のinode番号に変換するような機能のことです。しかし、システムコールが遮断されているとその情報が利用できません。そこで、仲介システムは「foo」へのアクセスが許可されているかどうかについての重要な判断を行う前に、まず変換を行うためのコードを複製しなければなりません。なお悪いことに、この変換は現在2回行われるようになっており、パフォーマンスを悪化させています。

* ''SMP Safety'': The name of the file being requested is in user-accessable memory, and thus vulnerable to change between the time the mediation module checks the access and the time the kernel grants the access. So the mediation module might see an access request for the file "foo", and then after it is approved the requestor changes the request to "../bar". This attack is especially likely on SMP machines, which will become most machines as multicore chips proliferate.

* ''Linus''：Linusは、GPL絡みの理由でLinux Kernel 2.6からsyscall tableを再読み込みする機能を削除することに決めました。だから、システムコールの介入はkernelへのパッチの適用が必要だという問題があります。

So instead of system call mediation, LSM inserts hooks deep into the kernel. Wherever a request by a user level process leads to access to an important deep kernel data structure, such as task descriptors or inodes, the LSM hook makes an up-call to whatever LSM module is loaded, asking "is this ok?" The LSM module considers the situation, makes its access control decision, and sends back a "yes" or "no" answer to the kernel, which then either performs the access or returns an error to the requestor. Thus access control technologies like SELinux and AppArmor can do their work as loadable modules, without requiring constant patching of the kernel.