AppArmorでアプリケーションのファイアウォールを構築
一見すると、アプリケーションを保護することは、ネットワーク接続されたコンピュータ上の全サービスを保護するのと難易度の点では変わらないように見えるかもしれない。しかし、最近のアプリケーションは複雑で入り組んでおり、ディスクのあちこちに散らばったライブラリやファイルを共有する仕組みになっている。さらに重要なことに、Discretionary Access Control（DAC）によって、プログラムがその実行ユーザの権限で動作することが可能になったため、攻撃者がアプリケーションの弱点を悪用してスーパーユーザ権限を取得する可能性が出てきた。
AppArmorの基本的な考え方は、個々のアプリケーションのアクセスを必要なファイルとライブラリのみに制限することで、アプリケーションをこのような脅威から保護するというものである。簡単に言えば、AppArmorはアプリケーションをロックダウンし、アプリケーションに必要なファイルについては、一般的な読み取り/書き込みアクセスモードに従って絶対パス名でアクセスするようにする。
AppArmorはLinux Security Model（LSM）カーネルインタフェースにプラグインされる。LSMは、セキュリティモデルが使用するインタフェースであり、Linuxカーネルの事実上の標準APIである。このインタフェースはストックカーネルにパッチとして適用できる。
また、AppArmorはLinux下のファイルアクセスに関してはDACモデルを利用している。まず、アプリケーションを実行するユーザは、そのプログラムを実行しファイルにアクセスするための権限を持たなければならない。その後で、AppArmorがMandatory Access Control（MAC）のメカニズムを適用し、各プログラムにその仕事を行うのに必要な権限だけを与える。したがって、プログラムXがライブラリYへのアクセスを必要とする場合は、まず、そのために必要な権限を持っているかどうかがDACによって確認される。その後、ようやくAppArmorが登場して、権限をより細かくロックダウンする。
AppArmorの使用
AppArmorは、もともとはImmunix（2005年5月にNovellに買収）で開発されたものである。その後、Novellはこのクローズドソースアプリケーションの開発を続け、2006年1月にGNU General Public License（GPL）の下でフリーソフトウェアとしてリリースした。Novellにはサブスクリプション版のSUSE Enterprise LinuxとフリーのopenSUSE Linuxディストリビューションがあるが、AppArmorはその両方に統合されている。インストール時にAppArmorのインストールを選択しなかった場合でも、SUSEのセットアップツールであるYaSTを使って後からインストールできる。
AppArmorをインストールすると、YaST内にAppArmor用の管理セクションができる。ここからAppArmorを有効または無効にすることができ、さらにアプリケーションプロファイルの追加、削除、更新ができる。AppArmorを有効にすると、/etc/apparmor.dディレクトリ内にあるセキュリティプロファイルが自動的に適用される。
SUSEには、代表的なサービス（ntp、netstat、ping、tracerouteなど）とアプリケーション（Firefoxなど）についてのプロファイルが付属している。また、/etc/apparmor/profiles/extras/ディレクトリには、さまざまなアプリケーション（Gaim、Evolution、RealPlayerなど）といくつかのコマンドおよびサービス（useradd、userdel、Squid、Sendmail、MySQLなど）についてのプロファイルが用意されている。ただし、このディレクトリ内のREADMEには、これらのプロファイルは十分なテストが行われておらず、修正してから使う必要があるという注意が書かれている。
プロファイルを自作するときのために、AppArmorには、コンソールベースのツールとグラフィカルベースのツールがいくつか用意されている。このアプリケーションを実行するには、まずプロファイリングが必要である。AppArmorは、最初にプロファイリング対象となるアプリケーションの場所を尋ねてくる。その後、分析ツールを実行して、そのアプリケーションが使用するすべてのライブラリ参照を検出し、記録する。分析が完了すると（通常は数分で済む）、「学習モード」に切り替わり、対象アプリケーションを起動して使用するようユーザに求めてくる。そこでユーザは、対象アプリケーションを使用して、必要な機能をすべて実行する。操作を終えると、AppArmorがシステムログを走査して、対象アプリケーションをロックダウンするために必要な情報を質問してくる。
サンプルプロファイルの例を紹介しておこう。
#include <tunables/global>
/usr/bin/ldd {
#include <abstractions/consoles>
/dev/log w,
/dev/urandom r,
/usr/lib64/locale/** r,
/lib/lib*.so* r,
/dev/null rw,
/dev/zero rw,
}
ご覧のとおり、プロファイルの大部分は、対象アプリケーションが必要とするファイルやライブラリを、絶対パスとアクセスモードの情報と一緒に列挙したものにすぎない。#includeステートメントでは、AppArmorの外部定義済みコンポーネントをプロファイルに読み込んでいる。プロファイルの先頭には、対象アプリケーションの絶対パスが記述される（この例では/usr/bin/ldd）。
また、この例ではワイルドカード文字（*）を使用して、名前が「lib」で始まり、拡張子の最初が「so」となっているすべてのファイルに読み取りアクセスを与えている。これは、将来的にライブラリに変更が生じた場合に備えての安全対策である。二重アスタリスク（**）は、rsyncからの借用である。これはすべてのファイルを表し、サブディレクトリとその下のファイルも含まれる。
作成されたプロファイルは自動的に適用される。対象アプリケーションや、それが使用するライブラリおよびファイルに変更を加えた場合は、それに応じてプロファイルを更新しなければならない。プロファイルの作成、更新、管理の手順は、『AppArmor Administration Guide』で図を交えて詳しく説明されている。
プロファイルを作成および編集するには、ルート権限が必要である。だが、AppArmorの第一の目的は、攻撃を受けたアプリケーションが自身をルートとして実行するのを防ぐことである。もしもあなたが神経質な性格で、ルートパスワードを持つ新しいシステム管理者を信頼できないと考えているならば、AppArmorを使用して、制限付きのログインシェルを作成するとよいだろう。たとえば、AppArmor FAQのこの項目では、ルートの権限のうち、システムログへのアクセスに必要な権限をユーザに与えつつ、サーバを再起動する権限は与えないでおく方法が紹介されている。
AppArmorの面白い機能の1つは、プロファイルによって保護されているプログラムの一部を、それぞれ独自のセキュリティコンテキストにおいて実行できるというものである。必要に応じてアプリケーションの「帽子を取り替え」て、特定のサブプロセスを閉じ込めることができる。ただし、この機能を使用するには、アプリケーションが「帽子の取り替え」を認識するようにしなければならない。Novellが提供するApache Webサーバには、mod_change_hatと呼ばれる特殊なモジュールが付属している。このモジュールを使用すると、Apacheの完全な権限がなくても、個々のPHPページやCGIスクリプトをそれぞれのセキュリティドメインで実行することができる。
長所と短所
AppArmorの導入はごく簡単であり、少なくともSUSEユーザならば苦労しないだろう。インストール時にカーネルやアプリケーションを再コンパイルする必要はなく、Novellのどちらのディストリビューションにもインストールが統合されている。SUSE Linuxのホームユーザでも、比較的簡単に、GaimインスタントメッセンジャーやFirefox Webブラウザといった重要なネットワークアプリケーションを保護するプロファイルを設定できるだろう。
だが、AppArmorの機能を最大限に活用するためには、対象アプリケーションの仕組みを細部までよく知る必要がある。いったんプロファイルを設定すると、そのプロファイルに含め忘れた機能にはアクセスできなくなる。慎重に設定しないと、AppArmorの柔軟性が困った事態をもたらすおそれがあるのだ。これを回避するには、さまざまなファイルとライブラリに対する参照を1つ1つ確認し、すべての参照について適切な権限を選択するようにする。ワイルドカード文字を使用するときは特に注意する。
Novellは、AppArmorに関して詳細な『Administrators Guide』と簡単な『Quick Start Guide』の2種類のマニュアルを用意している。さらに、FAQといくつかのメーリングリストもある。前にも述べたとおり、叩き台となるプロファイルもいくつか用意されている。エンタープライズユーザならば、SUSE Linuxサブスクリプションを通じて保守アップデートを入手できる。
予定されている機能拡張
AppArmorは今なお開発中である。AppArmorはNovellの2種類のディストリビューションに統合されているが、Slackwareで使用することもできる。Ubuntuポートも計画中である。AppArmorの機能をより洗練させるために、現在の、単にlddを繰り返し実行して共有ライブラリ呼び出しの一覧を作成するアナライザに代えて、もっと良い静的アナライザを使用する計画もある。また、管理者の時間を節約するために、報告済みのアクションは報告しないという、より賢い学習モードを導入する計画も進んでいる。
AppArmorで保護されるのは、プロファイルのあるアプリケーションだけである。将来的には、専用のプロファイルを持たないすべてのアプリケーションに対応するグローバルプロファイルの実装が計画されている。このプロファイルでは、ブラックリスト方式に従い、ディストリビューション内の重要ファイル（/etc/sudoers、/etc/shadow）に対するアクセスを基本的にすべて拒否し、特別に許可されたプロファイルを持つアプリケーションのアクセスだけを例外として認めるようにする。
まとめ
AppArmorは非常に完成度の高いツールだが、Novellはさらに改良を続けている。ここまで一貫して述べてきたように、これは500ページのマニュアルがないと使えないという類のものではない。しかし、どんなセキュリティツールでもそうであるように、正しい使い方を学ぶ必要がある。現時点では、2種類のSUSEディストリビューションからごく簡単に使用できるが、広く普及するためには、他のディストリビューションでもサポートされる必要がある。ただ、最近のNovellとMicrosoftのパートナーシップについては何かと批判的な声があるので、AppArmorも他のディストリビューションベンダに素直には受け入れられない可能性がある。
| AppArmorかSELinuxか |
|---|
|
オープンソースセキュリティに関しては、少なくとも2つの陣営がある。1つはAppArmorの使いやすさを支持するグループで、もう1つはより包括的なSELinuxを支持するグループである。AppArmorとSELinuxは同じゴールを目指しているが、アプローチが異なっている。AppArmorは、個々のアプリケーションに焦点を当て、各アプリケーションが必要不可欠なライブラリやファイルのみにアクセスするよう制限している。 一方のSELinuxは、オペレーティングシステム全体を制御しており、ディストリビューション内の情報のフローまでも管理している。SELinuxのアプローチはArmorよりも対象範囲が広く、MACやMulti-Level Security（MLS）といった強力なセキュリティ技術に基づいている。ただし、そのぶんだけセットアップは難しくなっている。 どちらの製品もオープンソースだが、Novellは今でも単独でAppArmor開発を行っている。対するSELinuxは、Red Hat、Tresys、NSA、IBM、HPなど複数のベンダに加えて、個人のオープンソース開発者が開発を進めている。それぞれのツールの発展経過を比較するのは不公平だろう。なぜなら、AppArmorはつい最近オープンソース界にデビューしたばかりだからだ。SELinuxは2000年の後期にオープンソース化されて以来、新しいグラフィカルツールやユーティリティに助けられながら、セットアップと保守を簡便化するという方向に向かって着実に進歩を遂げてきた。 どちらのソリューションも、ローカルコンピュータと外界との境界領域で動作しているアプリケーションを保護することを目的としている点は同じである。では、どちらを使用するべきだろうか。現時点の状況では、どのディストリビューションを使用しているかによって答えは異なる。AppArmorを最大限に活用するためには、フリーのopenSUSEディストリビューションか、エンタープライズ用のSUSE Linuxを使用する必要がある。同様に、SELinuxを最大限に活用できるのは、FedoraおよびRed Hat Enterprise Linuxのユーザである。 |
