既定の AppArmor プロファイルは指定した名前のプログラムに対して適用されるもの であるため、プロファイル名は制限を行なうアプリケーションに対するパスを 指定しなければなりません。

/usr/bin/foo {
...
}

このプロファイルは、制限を受けていないプロセスが /usr/bin/foo を実行すると、自動的に使用されます。

独立プロファイルは、プロファイル名がファイルシステムのパス名では書かれて いないプロファイルのことで、これにより自動ではアプリケーションに割り当て られることがありません。独立プロファイルの名前は profile というキーワードで始まります。プロファイル名は自由に命名することができますが、 下記の制限に従う必要があります: 名前は : や . の文字で始まってはならないこと。名前に空白を含む場合は、 引用符を付けて記すこと。名前が / で始まる場合は 標準プロファイルとして扱われること。そのため、下記に示す 2 種類の プロファイルは、同じ意味になります:

profile /usr/bin/foo {
...
}
/usr/bin/foo {
...
}

独立プロファイルは自動では使用されることがありませんし、 px のルールを介して遷移することもありません。独立 プロファイルを使用するには、名前付きプロファイル遷移 (詳しくは 20.8.7項 「名前付きプロファイル遷移」 をお読み ください) または change_profile ルール (詳しくは 20.2.5項 「ルール変更」 をお読みください) を使用する必要があります。

独立プロファイルは、通常システム全体のプロファイルでは制限できないような システムユーティリティ (たとえば /bin/bash など) に対して、特殊なプロファイルを設定する際に使用します。また、役割やユーザを 制限する際にも使用することができます。

ローカルプロファイルは、制限下にあるアプリケーションから起動するユーティリティ プログラムに対して、特殊な制限を行なうための便利な方法です。標準プロファイル のような形でプロファイルを指定するものの、それらの制限は親となるプロファイルに 組み込まれて動作します。また profile というキーワードを 付けるのも特徴です:

/parent/profile {
   ...
   profile local/profile {
      ...
   }
}

ローカルプロファイルへの遷移を行なうには、 cx (詳しくは 20.8.2項 「独立ローカルプロファイル実行モード (cx)」 をお読みください) または名前付きプロファイル遷移 (詳しくは 20.8.7項 「名前付きプロファイル遷移」 をお読みください) を使用します。

AppArmor の "ハット" とは、ローカルプロファイルに対していくつかの制限を付けた もので、それらへの遷移時に change_hat と呼ばれる間接的な ルールを使用するものです。詳しくは 第24章 ハット変更を利用した Web アプリケーションのプロファイル作成 をお読みください。

AppArmor では change_hat (ハット変更) と change_profile (プロファイル変更) というルールが用意されていて、これらは領域の遷移を制御するのに使用します。 change_hat はプロファイル内でハットを定義することで 指定するもの、 change_profile ルールは他のプロファイルを 参照する際に使用し、 change_profile というキーワードで 書き始めます:

change_profile /usr/bin/foobar,

change_hat と change_profile のいずれ ともアプリケーション主導のプロファイル遷移機能を提供するもので、個別の アプリケーションを立ち上げたりする必要はありません。 change_profile は、既に読み込まれている任意のプロファイルから一方向の遷移機能を提供する のに対して、 change_hat は親子型で復帰可能な遷移機能を 提供し、アプリケーションが親のプロファイルから子のハットに遷移した後、 正しい機密鍵が提供されていれば、後から親のプロファイルに戻ってくることが できるようになっています。

change_profile はアプリケーションの設定段階では信頼して おき、あとから権限レベルを落としたいような場合にベストな選択です。起動 フェーズでマップされているか、もしくは開いている任意のリソースは、プロファイル 変更が発生しても変わらずアクセス可能ですが、新しいプロファイルではリソース を開く際の制限を規定することになるほか、切り替え前から開いていたいくつかの リソースを制限することも行ないます。特にメモリ資源については、機能設定や ファイルリソースが制限されていても (それらがメモリマップ型のものでない 限り) 、以前と変わらずアクセスできるようになります。

change_hat は対象のアプリケーションを仮想マシンで動作 させるような場合や、アプリケーション資源に対する直接アクセスを提供しない ようなインタプリタ (たとえば mod_php など) を動作させる ような場合にベストな選択です。 change_hat はアプリケーション のメモリ内に戻り用の機密鍵を保存するので、制限された権限のもとではメモリへの 直接アクセスを行なうことができなくなります。ファイルアクセスについても、 ハットは閉じられていないファイルハンドルに対して制限を行なうことができるので、 同様に適切に区切ることができます。なお、アプリケーションが何らかのバッファ 処理を行なっていたり、バッファリング機能のあるファイルアクセス機能を提供 していたりするような場合は、これらのバッファリングされたファイルへのアクセスは カーネル側では検知できず、新しいプロファイルでは制限できないことに注意して ください。

	領域遷移の安全性について
change_hat と change_profile の 領域遷移は、 exec を利用した領域遷移ほど安全性が高くないことに注意して ください。これは、これらの領域遷移はメモリマッピングに対して作用することが できないほか、既に開いているリソースを閉じることもできないためです。

アブストラクトは一般的なアプリケーション処理を #include でまとめたものを指します。これらの処理には、認証機構へのアクセスやネーム サービスへのアクセス、一般的なグラフィック環境の使用やシステムアカウンティング などの処理が含まれます。これらアブストラクト内に一覧表示されているファイルは、 いずれも特定の処理に固有のものです。アブストラクトのうちの 1 つを必要とする プログラムでは、通常は他のアブストラクトファイルに書かれた他のファイルへの アクセスも必要となります (ローカル側の設定のほか、プログラムの要件に依存します) 。 アブストラクトは /etc/apparmor.d/abstractions 内に配置されて います。

プログラムチャンクのディレクトリ (/etc/apparmor.d/program-chunks) には、プログラムスイート固有の複数のプロファイル部品 (チャンク) が含まれて いて、スイートの外側では有益ではないものになっています。そのため、プロファイル ウイザード (aa-logprof や aa-genprof) などから、この中にあるプロファイルの使用は提案されることはありません。現時点では postfix プログラムスイート向けのプログラムチャンクのみ利用できます。

チューナブル (/etc/apparmor.d/tunables) のディレクトリ には、いくつかのグローバル変数定義が書かれています。プロファイル内で使用する 場合、これらの変数はプロファイル全体を変更することなく値を変更できる仕組みに なっています。すべてのプロファイルから利用できるチューナブル定義は、 /etc/apparmor.d/tunables/global に配置します。

AppArmor では、プロファイル内でパスを保持するのに変数を使用することができます。 グローバル変数はお使いのプロファイルに対して可搬性を与えるのに、ローカル 変数はパスに対するショートカットとして使用できます。

グローバル変数が便利になる一例として、ユーザのホームディレクトリが 異なる場所にマウントされるネットワークシナリオを考えてみます。影響する すべてのプロファイルに対してホームディレクトリのホームディレクトリを 書き換える代わりに、変数の値だけを書き換えれば作業が終わります。 グローバル変数は /etc/apparmor.d/tunables ディレクトリ以下で定義し、 #include ステートメント 経由で利用します。この使用例 (@{HOME} と @{HOMEDIRS}) での変数定義は、 /etc/apparmor.d/tunables/home ファイル内に 書かれています。

対して、ローカル変数はプロファイルの冒頭で定義します。これはたとえば、 chroot 環境下のパスに対して、ベースを設定する際に便利です:

@{CHROOT_BASE}=/tmp/foo
/sbin/syslog-ng {
...
# chrooted applications
@{CHROOT_BASE}/var/lib/*/dev/log w,
@{CHROOT_BASE}/var/log/** w,
...
}

現在の AppArmor ツールでは、変数は手作業でのプロファイル編集および管理でのみ 使用することができます。

別名ルールは、プロファイルパスをサイト固有のレイアウトにマッピングする ための代替手段です。変数を使用してパスの書き換えを行なう方法もありますが、 こちらは変数を値に置き換えた後に作用します:

alias /home/ -> /mnt/users/

現在の AppArmor ツールでは、変数は手作業でのプロファイル編集および管理でのみ 使用することができます。また、無効化するとルールが適用されなくなります。 別名ルールの定義は、 /etc/apparmor.d/tunables/alias ファイルを編集して行ないます。

プログラムに対して、特定のリソースへの読み込みアクセスを許可します。読み込み アクセスは、シェルスクリプトやその他のインタプリタ型言語を利用する場合に 必要となるほか、実行中のプロセスがコアダンプを出力できるかどうかを判断する 際にも必要となります。

プログラムに対して、特定のリソースへの書き込みアクセスを許可します。 ファイルをアンリンク (削除) する場合、この許可が必要となります。

プログラムに対して、特定のファイルへの追記を許可します。 w モードとは異なり、追記モードではデータの上書きやファイル名の変更、ファイルの削除を 行なうことができません。追記のアクセス許可は一般に、ログファイルへの書き込み 許可が必要なアプリケーションに対して付与されるもので、既存のログ情報を 操作させたくない場合に設定します。追記のアクセス許可は単純に書き込み モードのサブセットであるため、 w と a の許可フラグを同時に指定することはできません (相互に排他の関係です) 。

アプリケーションがロック (施錠) を行なうことができるようにします。 AppArmor の従来バージョンでは、アプリケーションから特定のリソースへアクセスする許可が あれば、ロックは特に何もすることなく許可されてきました。個別のファイルロック モードを使用することで、 AppArmor はロックを行なう必要のあるファイルに対してのみ ロックを許可し、サービス拒否攻撃 (DoS) のような状況に陥らないようにしています。

リンクモードはハードリンクへのアクセスを制御するものです。リンクを作成すると、 リンク先のファイルと作成したリンクは同じアクセス許可を持つことになります (ただし、リンク先でリンクアクセスの許可が必要になることはありません) 。

リンクモードは、任意のファイルに対してリンクを作成する許可を与えるもので、 リンクはリンク先のアクセス許可に対するサブセットの形になります (アクセス 許可テストのサブセット) 。リンク対では、リンク元とリンク先を指定すること で、どのような形でハードリンクの作成を許可するのかを制御することができます。 リンク対ルールは既定では、標準のリンク許可モードが必要とするようなアクセス 許可テストのサブセットを実施しません。このテストを強制するには、 subset キーワードを使用します。それぞれ下記に示す ルールは等価な意味を持ちます:

/link    l,
link subset /link -> /**,

現時点では、リンク対ルールは YaST やコマンドラインツールで利用することは できません。これらを使用する際は、プロファイルを手作業で編集してお使い ください。リンク対ルールのあるプロファイルでも、これらのツールを利用した 更新であれば問題なく動作します。これは、リンク対ルールについてはツール側で 一切処理されず、そのままにされるためです。

ファイルルールを拡張して、対象のファイルに対して所有者であった場合 (fsuid がファイルの uid と一致した場合) のルールを設定することができます。これを 設定するには、ルールの前に owner というキーワードを設定 します。所有者条件ルールは通常のファイルルールとして動作します。

owner /home/*/** rw

リンクルールと所有者条件ルールを同時に利用すると、所有者の確認はリンク先と なるファイルに対して実施され、リンクを行なうには、リンク先のファイルに対して 所有者でなければならなくなります。

	通常のファイルルールとの関係性について
所有者条件ルールは、通常のファイルルールに対するサブセットとして扱われます。 通常のファイルルールが所有者条件ルールと重複すると、結果として適用される ルールは通常のファイルルールと同じものになります。

拒否ルールは通知を行なう拒否を設定することができるほか、通知を行なわない 拒否を設定することもできます。プロファイル生成ツールでは、拒否ルールの 取り扱いとして既知の拒否かどうかを尋ねることはありません。このような拒否 を設定したい場合は、拒否時の監査ルールについても表示されることはなく、 ログファイルの肥大化を防いでいます。このような動作がお望みのものでない 場合は、拒否項目に対して audit というキーワードを追加 してください。

拒否ルールは、許可ルールと混在させて使用することもできます。これにより、 幅の広い許可ルールを設定しておいて、その中から部分的に許可されないファイル だけを除外するような使い方ができます。拒否ルールは所有者ルールとも混在させ、 自分自身が所有するファイルに対して、アクセスを拒否させることができます。 たとえば下記の例では、ユーザのディレクトリにあるすべてのファイルに対して 読み書きアクセスを許可するが、 .ssh/ 以下にあるファイルに対しては例外的に アクセスを拒否するルールです:

deny /home/*/.ssh/** w,
/home/*/** rw,

拒否ルールを多用すると、プロファイルの動作を理解するのが難しくなってしまう ことから、お勧めできません。ただし、拒否ルールを賢く使用することで、 プロファイルを単純化することができます。そのため、ツール類では特定のファイル に対する拒否ルールのみを生成し、グロブを利用した拒否ルールは作成しないように なっています。グロブを利用して拒否ルールを記述したい場合は、手作業でプロファイル を編集し、設定してください。これは、拒否ルールについてはツール側で一切処理 されず、そのままにされるためです。

このモードは AppArmor の領域遷移の際、実行中のリソースに対して独立した セキュリティプロファイルを必要とします。プロファイルが定義されていない 場合は、アクセスが拒否されます。

	独立プロファイル実行モードの使用について
px は LD_PRELOAD のような環境変数を 取り除く処理は行ないません。そのため、呼び出し側の領域は呼び出された 領域からの影響を大きく受けることになります。

なお、 Ux, ux, Px, ix とはそれぞれ互換性がありません。

px のようにグローバルのプロファイルセットを検索する 代わりに、 cx では現在のプロファイルが属するローカル プロファイルのみを検索対象とします。このプロファイル遷移は、ヘルパー アプリケーション向けに代替プロファイルを設定するのに使用することができます。

	独立ローカルプロファイル実行モード (cx) の制限について
現時点では cx の遷移はトップレベルのプロファイルに限定されていて、ハットや 子プロファイル内で使用することはできません。この制限は将来取り除かれる予定 です。

Ux, ux, Px, px, Cx, ix とは それぞれ互換性がありません。

プログラムに対して、 AppArmor プロファイルを全く適用せずにリソースを 実行できるようにします。このモードは、制限を受けているプログラムが コンピュータの再起動など、特権操作を必要となる場合に便利な機能です。 他の実行ファイル内で特権付きのセクションを用意して、そこに対して無制限の 実行権利を与えると、すべての制限付きプロセスに対して設定されていた、 必須の制限を迂回することができるようになります。制限内容について、 詳しくは apparmor(7) のマニュアルページを お読みください。

	無制限実行モード (ux) の使用について
ux は特別な理由がある場合にのみ利用してください。 これにより、子プロセスが AppArmor の保護無しで動作することになってしまいます。 また、 ux は LD_PRELOAD のような環境 変数を取り除く処理も行ないません。そのため、呼び出し側の領域は呼び出された 領域からの影響を大きく受けることになります。さらに、このモードは無制限 での実行をどうしても必要とする状況で、 LD_PRELOAD の環境 変数を使用しなければならない場合に限って使用してください。このモードを 使用したプロファイルは、ほとんどセキュリティが担保されないため、ご自身の 責任範囲のもとでご利用ください。

このモードは、 Ux, px, Px, ix とそれぞれ互換性がありません。

クリーン実行モードは指定した名前のプログラムを px, cx, ux の各モードで実行できるように するためのものですが、 AppArmor が Linux カーネルの機能である unsafe_exec ルーチンを呼び出す仕組みになっていて、 setuid プログラムを実行するときのように環境変数を取り除く処理を行ないます。 クリーン実行モードはそれぞれ大文字 (Px, Cx, Ux) で表わします。 setuid, setgid での環境変数の取り除きについて、詳しくは ld.so(8) の マニュアルページをお読みください。

ix モードは、プロファイルが用意されているプログラムが 特定の名前のプログラムを実行する際、 execve(2) による 通常の AppArmor 領域遷移を阻害するためのものです。通常の領域遷移の代わりに、 実行されたリソースは現在のプロファイルを継承します。

このモードは、制限付きのプログラムが他の制限付きプログラムを呼び出す際、 呼び出し先のプロファイルの許可を得たり、現在のプロファイルの許可を失ったり することなく実行する必要がある場合に、有用なモードです。 ix での実行は特権を変更することはないので、環境変数を取り除く機能は用意されて いません。

それぞれ cx, ux, px との互換性がありません。また、 m の機能を包含します。

このモードは、 mmap(2) の PROT_EXEC フラグを介してファイルをメモリ内にマッピングできるようにします。このフラグは 対象のページに対して実行許可を与えるものです。この機能は、いくつかの アーキテクチャで実行不可能なデータページを提供する際に使用されている もので、不正なコードを実行しにくくするために使用します。 AppArmor では、 このモードを ld(1) での無効な -L フラグのほか、 ld.so(8) での無効な LD_PRELOAD, LD_LIBRARY_PATH 設定の効果を 制限するために使用し、正しい振る舞いをするプログラム (または実行不可能な メモリアクセス制御を強制するアーキテクチャでの全プログラム) を制限する のに使用します。

既定では、 px と cx (および左記の クリーン実行モード) のプロファイル遷移を行なう際、実行ファイルの名前で プロファイルを探します。名前付きプロファイル遷移では、遷移先のプロファイル 名を指定することができるようになります。これは、複数のバイナリで単一の プロファイルを共有する必要がある場合に便利な機能であるほか、名前以外の 方法で異なるプロファイルに遷移したほうが都合がいい場合に便利です。名前 付きプロファイル遷移は、それぞれ cx, Cx, px, Px と同時に指定することができます。なお、現時点では 1 プロファイルあたり 12 個までの名前付きプロファイル遷移までしか使用できません。

名前付きプロファイル遷移では -> を使用し、移行先の プロファイル名を指定します:

/usr/bin/foo 
{
  /bin/** px -> shared_profile,
  ...
  /usr/*bash cx -> local_profile,
  ...
  profile local_profile 
  {
    ...
  }
}

	通常の遷移と名前付き遷移の違いについて
グロブとともに利用した場合、通常の遷移は 「一対多」 の関係を 構築することになります。つまり /bin/** px は、 プログラムが実行されている環境に依存して /bin/ping や /bin/cat などの遷移を指定することになります。 名前付き遷移の場合は、 「多対一」 の関係を構築することに なります。つまり、その名前とは関係なく、条件に該当したすべてのプログラムが 指定したプロファイルに遷移することになります。 名前付きプロファイル遷移は、ログでは Nx というモードで 表示されます。また、遷移先のプロファイル名は name2 という項目で表示されます。

px や cx の遷移には 「強力な 依存関係」 が存在していて、指定したプロファイルが存在しない場合は 実行が失敗します。これに対して、継承フォールバックを利用すると、現在の プロファイルが適用された状態のまま実行を続けることができるようになります (つまりプロファイルを継承することになります) 。継承フォールバックを指定 するには、それぞれ cx, Cx, px, Px に対して ix を組み合わせて指定します。これにより、それぞれ cix, Cix, pix, Pix の各モードになります。フォールバックモードは名前付きプロファイル遷移でも 使用することができます。

Px, Cx, Ux のいずれかの実行モードを選択した場合、子プロセスが環境を引き継ぐ にあたり、下記の環境変数が取り除かれます。その結果、プロファイルに対して Px, Cx, Ux のいずれかの実行モードを設定すると、下記の環境変数に依存して 動作するアプリケーションやプロセスは動作しなくなります: