AppArmor Technical Documentation - 3 The Apparmor Security Model

When a file is accessed by name with open(2), mkdir(2), etc., the kernel looks up the location of the object associated with the specified pathname in the file system hierarchy. The lookup is relative to the root directory for pathnames starting with a slash, and to the current working directory otherwise. Different processes can have have different working directories as well as different root directories. See path resolution(2) for a detailed discussion of how pathname resolution works.
Either way, the result of the lookup is a pair of (dentry, vfsmount) kernel-internal objects that uniquely identify the location of the file in the file system
hierarchy. The dentry points to the object if the object already exists, and is a placeholder for the object to be created otherwise.
AppArmor uses the (dentry, vfsmount) pair to compute the pathname of the file within a process's filesystem namespace. The resulting pathname contains no relative pathname components (\." or \.."), or symlinks.
AppArmor checks if the current profile contains rules that match this pathname, and if those rules allow the requested access. Accesses that are not explicitly allowed are denied.

(略)
どちらの方法(各プロセスのルートディレクトリから始まるパスネーム、ないしは、作業ディレクトリからのそれ、からファイルをルックアップすること)でも、ルックアップの結果は(dentry,vfsmount)カーネル内部の、ファイルシステム階層内部のファイルの位置を固有に特定する、オブジェクトのペアです。 dentryは、オブジェクトがすでに存在すればそのオブジェクトを指し、さもなくば、生成される予定のオブジェクトのプレースホルダーです。
AppArmorは(dentry,vfsmountの)ペアを用いて、プロセスのファイルシステムのネームスペース内部のファイルのパスネームを特定します。結果として生じるパスネームには、一切の相対パスネームの部分("."ないしは"..")やシンボリックリンクは含まれません。AppArmorは現在のプロファイルが、このパスネームにマッチするルールを含んでいるかどうか、そして、それらのルールが要求されたアクセスを許可しているかどうかをチェックします。明示的に許可されていないアクセスは拒否されます。

AppArmor Technical Documentation - 2 Overview

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はラベルではなく、名前によりファイルを識別し、〜(略 例が示される。 大意としては、ファイルをリネームして新しいもので置き換えた場合、新しい方にプロファイルが適用される)

AppArmor Technical Documentation - 1 Introduction

In this paper we describe AppArmor from a technical point of view, introduce its concepts, and explain the design decisions taken. This text is intended for people interested in understanding why AppArmor works the way it does. You may be looking for less detailed, low-level, or kernel centric documentation; in that case, please refer to the AppArmor documentation web site [1].
Sections 2 and 3 discuss the AppArmor security model, while Section 4 shows how to use it from a low-level point of view. Please be aware that lots of details are discussed here which the higher-level tools hide from the average user.

この文書では、AppArmorを技術的な観点から示し、そのコンセプトを紹介、採用されているデザインの方向性を説明するものです。この文書はAppArmorがなぜそのように動くのかに関心のある方々に向けて書かれています。より大雑把な、低レベルな、ないしは、カーネル中心の文書を期待される方がいるかもしれません。その場合には、AppArmor関連文書のWebサイト[1]を参照願います。
第2節と第3節では、AppArmorのセキュリティモデルが論じられ、第4節では低レベルの観点からそれをどのように使うかを示します。ここでは細かいことがたくさん論じられ、それは、平均的なユーザーからは高度なレベルのツールが隠しているものであるということを覚えておいてください。