AppArmor protects systems from insecure or untrusted processes by running them in con nement, still allowing them to share les with other parts of the system, exercising privilege, and communicating with other processes, but with some restrictions. These restrictions are mandatory; they are not bound to identity, group membership, or object ownership. In particular, the restrictions also apply to processes running with superuser privileges. AppArmor achieves this by plugging into the Linux Security Module (LSM) framework. The protections provided are in addition to the kernel's regular access control mechanisms.
The AppArmor kernel module and accompanying user-space tools are available under the GPL license. (The exception is the libapparmor library, available under the LGPL license, which allows change hat(2) to be used by non-GPL binaries.)
At the moment, AppArmor knows about two types of resources: les, and POSIX.1e (draft) capabilities. By controlling access to these resources, AppArmor can effectively prevent con ned processes from accessing les in unwanted ways, from executing binaries which they are not meant to execute, and from exercising privileges such as acting on behalf of another user (which are traditionally restricted to the superuser).
One use case for this kind of protection is a network daemon: even if the daemon is broken into, the additional restrictions imposed by AppArmor will prevent the attacker from attaining additional privileges beyond what the daemon is normally allowed to do. Because AppArmor controls which files a process can access in which ways down to the individual file level, the potential damage is much limited.
There is work going on for teaching AppArmor about additional resources like ulimits, and interprocess and network communication, but at this time, these resource types are not covered. This is less severe than it might initially seem: in order to attack another process from a broken-into process like a network daemon, that other process has to actively listen. The set of actively listening processes is relatively small, and this sort of interprocess communication is a natural security boundary, so listening processes should be validating all their input already. For protection against bugs in the input validation of those processes, they should also be confined by AppArmor though, thus further limiting the potential damage.
AppArmor protection is selective: it only confines processes for which policies (referred to as profiles) have been de ned. All other processes will continue to run unrestricted by AppArmor.
To confine a process, all it takes is to write a pro le for it, take an existing profile, or automatically generate a profile: for the latter, the process can be run in learning or complain mode in which AppArmor allows all accesses, and logs all accesses that are not allowed by the current profile already. This log can then be used to automatically generate a suitable new profile, or refine an existing one. The application does not need to be modified.
An example pro le together with a complete low-level walk-through of AppArmor can be found in Section 4. The apparmor.d(5) manual page contains further details.
AppArmor is not based on labeling or label-based access and transition rules, so it does not stick a label on each each file in the file system (or more generally, on each object). It identifies files by name rather than by label, so if a process is granted read access to /etc/shadow and the system administrator renames /etc/shadow to /etc/shadow.old and replaces it with a copy (that may have an additional user in it, for example), the process will have access to the new /etc/shadow, and not to /etc/shadow.old.
AppArmorはシステムを安全ではない、あるいは、信頼のされないプロセスから守ります。それは、それらのプロセスを一定の制限のもとで走らせることで行われ、システムの他の部分とのファイルの共有や特権の行使、他のプロセスとのコミュニケーションをそれらのプロセスにいくつかの条件を付して認めます。これらの制限は強制的なもので、個人やグループのメンバーシップ、ないしは、オブジェクトの所有者には結びついていません。とりわけ、これらの制限は、スーパーユーザの権限により実行されるプロセスにも適用されます。[訳注:この2文は、AppArmorがスーパーユーザだから制限を緩くする一方、一般ユーザだと制限をきつくなるという働きはせず、どんなユーザでも(その人がどんなユーザグループに属していても、その人が制限対象のオブジェクトの所有者であっても)制限を強制するという意味でしょう。]AppArmorはこれをLinuxセキュリティモデル(LSM)のフレームワークに接続することで達成します。提供される保護はカーネルの一般的なアクセスコントロールのメカニズムに加えて行われます。
(略)
さて、AppArmorは、ファイルとPOSIX.1e(draft)機能との2つのリソースについて関知します。これらのリソースへのアクセスをコントロールすることにより、AppArmorは効果的に制限されたプロセスが喜ばしくない方法によりアクセスしたり、実行する必要のないバイナリを実行したり、他のユーザとしてアクションを行うような特権を行使(これは伝統的にスーパーユーザに制限されています)したりすることを防ぎます。
(略)
AppArmorの保護は選択的です。AppArmorはそのプロセス用にポリシー(プロファイルとして参照される)の定義されたプロセスを制限するのみです。[ポリシーの定義されていない]すべての他のプロセスは、AppArmorにより制限されないまま走り続けます。
あるプロセスを制限するためにAppArmorの行うことの全ては、そのプロセス用にプロファイルを書くこと、あるいは、すでに存在するプロファイルを適用すること、自動的にプロファイルを生成することです。3つのうち最後のために、そのプロセスは、ラーニングモードないしはコンプレインモードで動作し、そのモードでは、AppArmorはすべてのアクセスを許可し、現在のプロファイルですでに許可されていないすべてのアクセスを記録します。そして、このログは新しくふさわしいプロファイルの自動生成や既存のプロファイルの再定義に利用されます。そのアプリケーションは修正する必要はありません。
(略 大意は、例は第4節で説明するし、もっと細かいことをしりたい人は、apparmor.d(5)manページを参照してね。)
AppArmorはラベリングないしはラベルをベースとしたアクセス及びトランザクションルールには基づいていませんので、ファイルシステム上の各々のファイルに(より一般的に言えば、各々のオブジェクトに)ラベルを付すことはしません[よく分からないけど、AppArmorはこれとは違うらしいから、ここではこの程度で妥協]。AppArmorはラベルではなく、名前によりファイルを識別し、〜(略 例が示される。 大意としては、ファイルをリネームして新しいもので置き換えた場合、新しい方にプロファイルが適用される)
