ソースを表示

== AppArmorの目指すところ ==

誤った挙動をする可能性のあるソフトウェアからシステムを守るためには、アプリケーションに最小権限という原則を適用しなくてはなりません。これは、アプリケーションの動作中つねに、動作に必要最小限のリソースにだけアクセスを許可するという制限をかけるというものです。したがって、もしアプリケーションが不正に利用されてしまった場合でも、被害を最小限に食い止めることができます。しかし、同時に、安全を確保するための特権の制限（訳注：たとえroot権限が奪取されても、最小権限という制限を回避できないようにすること）や透過性、高速性も必要です。
* ''安全性'' - アプリケーションがこの制限を回避することができないこと。

* ''高速性'' - パフォーマンスのオーバーヘッドはごくわずかであること。

* ''透過性'' - ごくわずかな変更だけで、ソフトウェアやユーザーがこれまでどおりに稼働／行動できること。
安全性は、セキュリティがまやかしのものにならないようにするために重要です。また、面倒で使いづらいためにセキュリティ機能をオフ（無効）にされてしまうのは、セキュリティ上最悪ですから、透過性や高速性も大切です。続いて、AppArmorがどのように安全性、パフォーマンス、そして透過性を実現しているのかを説明します。

=== 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.

=== Performance Through Simplicity ===

To achieve speed, AppArmor uses a very simple security model so that checking can be done quickly. In particular, security policies are very small, so that they can be fully loaded into kernel memory, eliminating the need for a 2-level caching architecture of policy storage.

=== Transparancy Through Familiarity ===

To achieve transparency, AppArmor uses all-classical UNIX security semantics, but applies them to programs. An AppArmor policy specifies the set of POSIX.1e capabilities that a program can have, and specifies the set of files it can access. The POSIX.1e capabilities are specified by name. The files are specified by absolute path names, including embedding shell-syntax wild cards, followed by access modes (R, W, and X, with a bit of embellishment). So an AppArmor policy to confine ntpd (the network time protocol daemon) looks like this:

 /usr/sbin/ntpd {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <program-chunks/ntpd>
  capability ipc_lock,
  capability net_bind_service,
  capability sys_time,
  capability sys_chroot,
  capability setuid,
  /etc/ntp.conf             r,
  /etc/ntp/drift*           rwl,
  /etc/ntp/keys             r,
  /etc/ntp/step-tickers     r,
  /tmp/ntp*                 rwl,
  /usr/sbin/ntpd            rix,
  /var/log/ntp              w,
  /var/log/ntp.log          w,
  /var/run/ntpd.pid         w,
  /var/lib/ntp/drift        rwl,
  /var/lib/ntp/drift.TEMP   rwl,
  /var/lib/ntp/var/run/ntp/ntpd.pid w,
  /var/lib/ntp/drift/ntp.drift      r,
  /drift/ntp.drift.TEMP     rwl,
  /drift/ntp.drift          rwl,
 }


From here, it would be relatively straightforward to hand-craft security policy for applications through a combination of expert knowledge and trial and error. However, that would be so tedious that the vast majority of developers and users would refuse to put in the work. To further improve transparency, AppArmor includes a "learning mode" to allow policy to be built by running the application and observing what it does. In learning mode, the rules are not actually enforced, but violations are logged, and process forking is tracked, so that the log of an application's execution builds up a characteristic description of the application's activities. AppArmor includes a log analysis program that scans the log, prompts the user with questions, and automatically creates a program profile. Learning mode and the log analyzer are also capable of incremental improvement of the profile if one already exists, but omits some necessary rules.