Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

31 プロファイルのコンポーネントと文法

アプリケーションに対する AppArmor のプロファイル作成は非常にわかりやすく、直感的な仕組みになっています。 AppArmor にはプロファイル作成を支援するツールが添付されているため、プログラミングの知識もスクリプトの処理も必要とはなりません。管理者に対して求められる作業は、セキュリティを強化する目的で、各アプリケーションに対して最も厳格なアクセス制御とプログラム実行のポリシーを設定することだけです。

アプリケーションに対するプロファイルの更新や修正は、ソフトウエアの設定を変更したり、必要な機能範囲の変化が起こった場合のみです。 AppArmor には、プロファイルの更新や修正に対応した、直感的なツールが用意されています。

プロファイルを作成したいプログラムを選択したあとは、実際に AppArmor のプロファイルを作成するだけです。プロファイルの作成を行うにあたっては、コンポーネントやその文法の理解を深める必要があります。 AppArmor には、シンプルで再利用性の高いプロファイルを作成するための、さまざまな機能が用意されています:

ファイル取り込み

include と呼ばれるステートメントを使用することで、他の AppArmor プロファイル内の一部分を取り込むことができます。これにより、新しいプロファイルの構造を単純化することができます。

抽象

抽象機能は、一般的なアプリケーションの処理をまとめて取り込む機能を提供します。

プログラムチャンク

プログラムチャンクとはファイル取り込み機能の一部で、特定のプログラムスイートに固有として設定されているプロファイルの一部を、取り込むことができる機能です。

ケーパビリティ項目

ケーパビリティ項目とは、 POSIX.1e (http://ja.wikipedia.org/wiki/POSIX) として定められている Linux ケーパビリティ向けのプロファイル項目で、制限されたプロセスが権限の必要なシステムコールを行う際、より細かい制御を行うことのできる仕組みを指します。

ネットワークアクセス制御項目

ネットワークアクセス制御項目とは、アドレスの種類とファミリをベースにして、ネットワークへのアクセスを制御するための項目です。

ローカル変数定義

ローカル変数を定義することで、パスのショートカットを設定することができます。

ファイルアクセス制御項目

ファイルアクセス制御項目とは、アプリケーション側からのアクセスを許可するファイルの一覧を表わす項目です。

rlimit 項目

rlimit 項目は、アプリケーションに対するリソース制限を設定し、制御するための項目です。

プロファイルを作成すべきプログラムの判断については 30.2項 「予防接種を行うプログラムの決定」 を、 YaST を利用して AppArmor のプロファイルを作成する方法については 第33章 「YaST を利用したプロファイルの構築と管理 を、 AppArmor のコマンドラインインターフェイスを利用したプロファイルの作成については 第34章 「コマンドラインからのプロファイル構築 を、それぞれお読みください。

AppArmor のプロファイルに関する詳細については、 man 5 apparmor をお読みください。

31.1 AppArmor プロファイル内の各部の意味

プロファイルに何が含まれているのか、およびプロファイルを作成するにはどうしたらよいのかを説明するにあたって、もっとも簡単な方法は例を挙げる方法です。たとえば /usr/bin/foo という架空のアプリケーションに対して、下記のようなプロファイルが存在する場合を例にします:

#include <tunables/global>1

# a comment naming the application to confine
/usr/bin/foo2 {3
   #include <abstractions/base>4

   capability setgid5,
   network inet tcp6,

   link /etc/sysconfig/foo -> /etc/foo.conf,7
   /bin/mount            ux,
   /dev/{,u}8random     r,
   /etc/ld.so.cache      r,
   /etc/foo/*            r,
   /lib/ld-*.so*         mr,
   /lib/lib*.so*         mr,
   /proc/[0-9]**         r,
   /usr/lib/**           mr,
   /tmp/                 r,9
   /tmp/foo.pid          wr,
   /tmp/foo.*            lrw,
   /@{HOME}10/.foo_file   rw,
   /@{HOME}/.foo_lock    kw,
   owner11 /shared/foo/** rw,
   /usr/bin/foobar       Cx,12
   /bin/**               Px -> bin_generic,13

   # a comment about foo's local (children) profile for /usr/bin/foobar.

   profile /usr/bin/foobar14 {
      /bin/bash          rmix,
      /bin/cat           rmix,
      /bin/more          rmix,
      /var/log/foobar*   rwl,
      /etc/foobar        r,
   }

  # foo's hat, bar.
   ^bar15 {
    /lib/ld-*.so*         mr,
    /usr/bin/bar          px,
    /var/spool/*          rwl,
   }
}

1

ここでは、変数定義を含むファイルを読み込んでいます。

2

制限対象となるプログラムに対して、正規化されたパスを指定しています。

3

この中括弧 ( {} ) は、ステートメントやサブプロファイル、パス項目やケーパビリティ項目、ネットワーク項目などのコンテナとして機能するものです。

4

このディレクティブにより、 AppArmor プロファイルのコンポーネントを取り込んでいます。これにより、プロファイルを単純化できるようになっています。

5

capability (ケーパビリティ) 項目のステートメントでは、 POSIX.1e ドラフトで規定されたケーパビリティを有効化しています。

6

アプリケーションに対して、どの種類のネットワークアクセスを許可するかを指定しているディレクティブです。詳しくは 31.5項 「ネットワークアクセス制御」 をお読みください。

7

リンク対ルールでは、リンクの元と宛先をそれぞれ指定することができます。詳しくは 31.7.6項 「リンク対」 をお読みください。

8

この中括弧 ( {} ) は、カンマ区切りで複数の項目を列挙するための仕組みです。この場合、 u があるものと無いものに展開されます。

9

プログラム側から、ファイルシステム内のどの領域にアクセスを許可するのかを設定する、パス項目です。この項目では、最初に絶対パス表記でのファイル名 (ワイルドカード可) を記述し、次に許可されるアクセスモード (たとえば r であれば読み込み、 w であれば書き込み、 x であれば実行など) をそれぞれ指定します。スペースやタブなど、任意の種類のホワイトスペースをパス名の前に指定することができますが、パス名とアクセスモードの指定は区切らなければなりません。また、アクセスモードと行末のカンマとの間は、スペースを入れても入れなくてもかまいません。利用可能なアクセスモードに関する詳細は、 31.7項 「ファイルアクセス許可のアクセスモード」 をお読みください。

10

この変数は、プロファイル本体を変更することなく内容を変更したい場合に使用するものです。

11

所有者条件ルールと呼ばれるルールで、自分自身で所有しているファイルに対して、読み込みや書き込みの権限を許可することができます。詳しくは 31.7.8項 「所有者条件ルール」 をお読みください。

12

この項目は、 /usr/bin/foobar という名前のローカルプロファイルに遷移させるためのものです。利用可能な実行モードに関する概要は、 31.12項 「実行モード」 をお読みください。

13

グローバルスコープ内に位置する bin_generic というプロファイルへの遷移を表わす、名前付きプロファイル遷移です。詳しくは 31.12.7項 「名前付きプロファイル遷移」 をお読みください。

14

ここでは、ローカルプロファイル /usr/bin/foobar を定義しています。

15

ここでは、アプリケーションに対する ハット と呼ばれるサブプロファイルを参照しています。 AppArmor のチェンジハット機能について、詳しくは 第35章 「チェンジハット機能による Web アプリケーションのプロファイル作成 をお読みください。

プログラムに対してプロファイルを作成する際、プログラムはプロファイル内に指定されたファイルやモード、 POSIX ケーパビリティにのみアクセスが許可されます。これらの制限は、 Linux の標準的なアクセス制御に付加する形で動作します。

例: プログラム側でケーパビリティ CAP_CHOWN を使用できるようにするには、通常の Linux アクセス制御で CAP_CHOWN に対するアクセス許可を持つ (通常は root が所有するプロセスである必要があります) だけでなく、プロファイル内に chown のケーパビリティが設定されていなければなりません。また、プログラムが /foo/bar というファイルに書き込む場合、ファイルの所有者やパーミッションの設定で書き込みできる権限を持つだけでなく、プロファイル内に /foo/bar w という設定がなければなりません。

AppArmor のルールへの違反は、 audit パッケージがインストールされていれば /var/log/audit/audit.log に、インストールされていない場合は /var/log/messages に記録されます (syslog パッケージさえもインストールされていない場合は、 journalctl にのみ記録されます) 。このような AppArmor の仕組みにより、実際に攻撃を受けた場合であっても、攻撃による被害を軽減することができるようになっています。

31.2 プロファイルの種類

AppArmor ではプロファイルが 4 種類に分けられています。それぞれ標準プロファイルと未接続プロファイル、ローカルプロファイルとハットと呼ばれます。標準プロファイルと未接続プロファイルは単独で動作するプロファイルであり、 /etc/apparmor.d/ ディレクトリ内にファイルとして配置されます。ローカルプロファイルとハットは、親プロファイル内に組み込まれる子プロファイルで、アプリケーションのサブタスクに対してより厳しい、もしくは別途の制限を提供するために使用します。

31.2.1 標準プロファイル

既定の AppArmor プロファイルは、プログラムに対して名前で接続される仕組みであるため、プロファイル名は制限対象のアプリケーションパスに一致していなければなりません。

/usr/bin/foo {
...
}

上記のようなプロファイルが存在すると、制限を受けていないプロセスが /usr/bin/foo を実行すると、自動的に読み込まれて制限が適用されます。

31.2.2 未接続プロファイル

未接続プロファイルは、ファイルシステムのネームスペース内に存在しておらず、そのためにアプリケーションの実行時に自動的に読み込まれ適用されるものではありません。未接続プロファイルの場合、プロファイル名の前に profile というキーワードを指定します。プロファイル名には自由な名前を設定することができますが、:. で始まる名前は指定できません。また、プロファイル名にはスペースを入れることもできますが、この場合は正しく引用符を指定しなければなりません。また、名前が / で始まる場合、そのプロファイルは標準プロファイルとして扱われます。たとえば下記の 2 つのプロファイルは、同じ名前の標準プロファイルを意味するものになります:

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

上述のように、未接続プロファイルは自動的に読み込まれませんし、 Px ルールで遷移することもありません。この未接続プロファイルを使用するには、名前付きプロファイル遷移の機能 (詳しくは 31.12.7項 「名前付きプロファイル遷移」 をお読みください) を使用するか、もしくは change_profile ルール (詳しくは 31.2.5項 「ルール変更」 をお読みください) で適用する必要があります。

未接続プロファイルは一般に、システム全体のプロファイルとしては制限を加えるべきではないシステムユーティリティ (例: /bin/bash) などに対して、特別なプロファイルを割り当てるために使用します。また、役割の設定やユーザへの制限などを設定する際にも使用します。

31.2.3 ローカルプロファイル

ローカルプロファイルは、制限を受けているアプリケーションがユーティリティプログラムを起動する際、そのユーティリティに対する特殊な制限を設定する際に便利な機能です。この種類のプロファイルは標準プロファイルと同様に指定することができますが、親プロファイル内に組み込まれて使用され、かつ profile キーワードで始める点が異なります。

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

ローカルプロファイルに遷移させたい場合は、 cx ルール (詳しくは 31.12.2項 「専用ローカルプロファイル実行モード (cx)」 をお読みください) もしくは名前付きプロファイル遷移 (詳しくは 31.12.7項 「名前付きプロファイル遷移」 をお読みください) を使用します。

31.2.4 ハット

AppArmor では、 "ハット" とは追加の制限を提供するローカルプロファイルを意味するほか、 change_hat を利用して遷移することのできる、暗黙のルールを意味します。詳しくは 第35章 「チェンジハット機能による Web アプリケーションのプロファイル作成 をお読みください。

31.2.5 ルール変更

AppArmor では、 change_hat および change_profile と呼ばれるルールを利用して、制御ドメインの遷移を行うことができます。 change_hat がプロファイル内で定義したハットに遷移するのに対して、 change_profile は他のプロファイルを参照する処理を行います。 change_profile では、下記のように change_profile キーワードを明記します:

change_profile -> /usr/bin/foobar,

change_hatchange_profile のいずれも、個別のアプリケーションを起動することなく、アプリケーション内でのプロファイル遷移を実現します。 change_profile は一般に、読み込まれたプロファイル間で一方向の遷移を行います。それに対して、 change_hat は戻ってくることを前提とした遷移となり、後から正しい機密鍵を指定することで、親プロファイルに戻ってくることができます。

change_profile は、アプリケーションが特定の設定フェーズを経由して起動し、後から権限レベルを落とすような仕組みである場合に、最適な仕組みです。起動フェーズ内でマッピングしたり開いたりしたリソースについては、プロファイルが変更されてもアクセスが許可され続けますが、新しいプロファイルでは新しいリソースを開く処理が制限されたり、リソースによっては切り替え前よりも制限を厳しくしたりするような動作に適切な仕組みです。特に、ケーパビリティやファイルのリソースについては制限ができる (ただしメモリマップされていなければ) ものの、メモリについては以前と同じく利用できるようになります。

change_hat はアプリケーションが仮想マシンやインタプリタを動作させるような場合に最適な仕組みで、それらの仮想マシンやインタプリタがアプリケーションのリソースへのアクセスを提供しないような場合に適切です (たとえば Apache の mod_php などがそれにあたります) 。なお change_hat は、元のプロファイルに戻るための機密鍵をアプリケーションのメモリ内に保存しますので、権限を縮小したフェーズではメモリに直接悪性できる権限を持つべきではありません。また、ハットではファイルハンドルへのアクセスを制限することはできますが、閉じることはできませんので、ファイルアクセスが正しく分離されていることも重要となります。もしもアプリケーションがバッファリングを行っていて、バッファを利用したファイルアクセスの機能を提供している場合、これらのファイルへのアクセスはカーネルからは検出することができず、新しいプロファイルでも制限がされないことがありうることにも注意してください。

警告
警告: ドメイン遷移の安全性について

change_hatchange_profile によるドメイン遷移は、プロセスのメモリマッピングに影響を与えることができませんし、既に開いているリソースを閉じることもしませんので、 exec によるドメイン遷移よりはずっと安全性が低いことに注意してください。

31.3 include ステートメント

include ステートメントは、プロファイルを単純化するため、他の AppArmor プロファイルのコンポーネントを取り込むことができるディレクティブです。一般に、プログラムからファイルへのアクセス許可を設定するための仕組みで、ファイルやディレクトリへのアクセスを別ファイルに切り出すことができますので、他のプログラムでも同様に必要となるようなファイルやディレクトリを列挙することができます。これにより、プロファイルのサイズも小さくすることができます。

include ステートメントは通常、ハッシュ ( # ) 記号から書き始めます。ただし、ハッシュ ( # ) 記号はプロファイル内のコメント文を記述する際にも使用するものであるため、プロファイルが少しわかりにくくなってしまいます。このような問題から、 #include はその前にハッシュ記号がある場合には効果を失うように作られている (##include はコメントとして扱われます) ほか、 #include の間にスペースを入れた場合も、同様に効果を失うように作られています (# include もコメントとして扱われます) 。

このほか、冒頭のハッシュ記号を省略して、 include だけで記述することもできます。

include "/etc/apparmor.d/abstractions/foo"

上記は、下記と同じ意味になります:

#include "/etc/apparmor.d/abstractions/foo"
注記
注記: 末尾に ',' を付けてはならない件について

include ステートメントは C 言語のプリプロセッサの文法に従って作られているため、その他の AppArmor ルールのように、文末に ',' を入れることはありません。

また、文法を少し変えることで、 include の動作を変更することができます。たとえばパスの指定の際、 "" で括って指定すると、絶対パスや相対パスとして読み込ませることができます。

include "/etc/apparmor.d/abstractions/foo"   # 絶対パス表記
include "abstractions/foo"   # 現在のディレクトリからの相対パス表記

なお相対パス表記の場合、現在読み込んでいるファイルからの相対パスとして扱われることに注意してください。たとえば現在のプロファイルが /etc/apparmor.d/bar である場合、下記のように include を記述したとします:

include "abstractions/foo"

すると、 /etc/apparmor.d/abstractions/foo というファイルを取り込むことになります。また、

include "example"

のような include ステートメントが /etc/apparmor.d/abstractions/foo プロファイル内に存在したとすると、 /etc/apparmor.d/abstractions/example というファイルを取り込むことになります。

また、 <> を使用してファイルパスを指定すると、インクルードパス (-I で指定することができます。既定では /etc/apparmor.d ディレクトリです) 内を検索することができます。たとえばインクルードパスが下記のように指定されているものとします:

-I /etc/apparmor.d/ -I /usr/share/apparmor/

この場合、下記のような include ステートメントを実行したとします:

include <abstractions/foo>

すると、まずは /etc/apparmor.d/abstractions/foo にファイルが存在していないかどうかを調べ、存在していない場合は /usr/share/apparmor/abstractions/foo のファイルが存在していないかどうかを調べる動作になります。

ヒント
ヒント

既定のインクルードパスは、 apparmor_parser-I オプションを指定するか、もしくは /etc/apparmor/parser.conf 内に指定することで、上書きすることができます:

Include /usr/share/apparmor/
Include /etc/apparmor.d/

このファイル内でも複数の項目を設定することができます。ただし、複数の項目を設定した場合は、 apparmor_parser に対して、順序通りに -I--Include を指定したものとして扱われます。

include ステートメントのパス指定が '/' で終わるものであった場合、これはディレクトリ内にある全てのファイルを取り込むものとして処理されます。

お使いのアプリケーションのプロファイル作成を支援する目的で、 AppArmor には 3 種類の include ステートメント (抽象/プログラムチャンク/チューナブル) が用意されています。

31.3.1 抽象

抽象とは一般的なアプリケーション処理をまとめた include ファイルで、たとえば認証機構やネームサービスルーチンへのアクセス、一般的なグラフィック要件やシステムアカウンティングなどが含まれます。これらの抽象内に記述されたファイルは、それぞれの処理で必要となるファイルであり、これらのうちのどれか 1 つにでもアクセスが必要となった場合、同じ抽象内の他のファイルに対しても、おそらくアクセスが必要となるものとして作られています (もちろん設定内容やプログラム側の要件にも依存します) 。抽象は /etc/apparmor.d/abstractions ディレクトリ内に配置されています。

31.3.2 プログラムチャンク

プログラムチャンクディレクトリ ( /etc/apparmor.d/program-chunks ) には、プログラムスイートごとに固有のプロファイルのチャンクのほか、スイート外では一般に必要とされないチャンクが含まれています。そのため、プロファイルウイザード ( aa-logprof および aa-genprof ) では、使用するよう提案することはありません。現時点では、プログラムチャンクは postfix プログラムスイート向けにのみ提供されています。

31.3.3 チューナブル

チューナブルのディレクトリ ( /etc/apparmor.d/tunables ) には、グローバル変数の定義が含まれています。プロファイル内で使用すると、これらの変数は処理時に展開され処理されますので、プロファイルそのものを変更することなく、値を変更することができるようになります。全てのプロファイルで使用される全てのチューナブル定義を追加するには、 /etc/apparmor.d/tunables/global に設定します。

31.4 ケーパビリティ項目 (POSIX.1e)

ケーパビリティルールは、単純に capability の後ろに、 capabilities(7) のマニュアルページに書かれた POSIX.1e のケーパビリティ名を記述するだけです。単一のルール内に複数のケーパビリティを記述したり、全てのケーパビリティを指定 (capability とだけ記述する) することもできます。

capability dac_override sys_admin,   # 複数のケーパビリティ
capability,                          # 全てのケーパビリティ

31.5 ネットワークアクセス制御

AppArmor では、アドレスの種類とファミリをベースにして、ネットワークアクセスの制限を行うことができます。下記にネットワークアクセス制御ルールの書式を示します:

network [[<ドメイン>1][<種類2>][<プロトコル3>]]

1

指定できるドメイン: inet , ax25 , ipx , appletalk , netrom , bridge , x25 , inet6 , rose , netbeui , security , key , packet , ash , econet , atmsvc , sna , pppox , wanpipe , bluetooth , unix , atmpvc , netlink , llc , can , tipc , iucv , rxrpc , isdn , phonet , ieee802154 , caif , alg , nfc , vsock

2

指定できる種類: stream , dgram , seqpacket , rdm , raw , packet

3

指定できるプロトコル: tcp , udp , icmp

AppArmor ツールではファミリと種類の指定にのみ対応しています。また、 AppArmor モジュールは ACCESS DENIED (アクセス拒否) メッセージ内に network ドメイン 種類 のみを書き込みます。さらに、これらのメッセージはプロファイル生成ツール (YaST およびコマンドライン) のみに出力されます。

下記の例は、 AppArmor プロファイル内で使用されるネットワーク関連のルール例を示しています。ただし、後ろの 2 つの書式は、現時点での AppArmor ツールでは対応していないことに注意してください。

network1,
network inet2,
network inet63,
network inet stream4,
network inet tcp5,
network tcp6,

1

全てのネットワーク処理を許可します。ドメインや種類、プロトコルでの制限を適用しません。

2

IPv4 のネットワーク処理を許可します。

3

IPv6 のネットワーク処理を許可します。

4

IPv4 TCP のネットワーク処理を許可します。

5

IPv4 TCP のネットワーク処理を許可します (1 行上のルールと同じ意味です) 。

6

IPv4 と IPv6 の TCP ネットワーク処理を許可します。

31.6 プロファイル名/フラグ/パス/グロブ

プロファイルは通常、プログラムの実行ファイルのフルパスを指定することで、プログラムに割り当てられます。たとえば標準プロファイル (31.2.1項 「標準プロファイル」) の場合、プロファイルは下記のように記述します:

/usr/bin/foo { ... }

下記では、プロファイルの命名の際や他の既存のコンテキスト内にプロファイルを配置する際、そして単純にファイルパスを指定する際に、便利なテクニックを紹介しています。

AppArmor ではディレクトリパスとファイルパスを明示的に区別して扱います。ディレクトリとして明示したい場合は、末尾に / を指定します:

/some/random/example/* r

/some/random/example 内のファイルに対して、読み込みアクセスを許可します。

/some/random/example/ r

ディレクトリにのみ読み込みアクセスを許可します。

/some/**/ r

/some 以下の任意のディレクトリに対して、読み込みアクセスを許可します (ただし /some/ 自身には許可しません) 。

/some/random/example/** r

/some/random/example 以下の任意のファイルとディレクトリに対して、読み込みアクセスを許可します (ただし /some/random/example/ 自身には許可しません) 。

/some/random/example/**[^/] r

/some/random/example 以下のファイルに対して、読み込みアクセスを許可します。このとき、明示的にディレクトリを除外します ( [^/] ) 。

グロブ (もしくは正規表現マッチング) はワイルドカードなどを利用して、ファイルやサブディレクトリをまとめて指定するための仕組みです。一般的なシェル、たとえば csh, Bash, zsh などで使用されるグロブ書式を利用して指定することができます。

*

任意の長さの文字列にマッチします (ただし / は含まないものとします) 。

例: 複数のファイルの一括指定。

**

任意の長さの文字列にマッチします (/ を含みます) 。

例: サブディレクトリを含む全ファイルの一括指定。

?

1 文字にマッチします (ただし / は含まないものとします) 。

[abc]

a , b , c のいずれかの文字にマッチします。

例: /home[01]/*/.plan のように指定すると、 /home0 および /home1 のディレクトリ内にある .plan ファイルにアクセスを許可します。

[a-c]

a , b , c のいずれかの文字にマッチします。

{ab,cd}

ab という文字列、もしくは cd という文字列のいずれかにマッチします。

例: /{usr,www}/pages/** のように指定すると、 /usr/pages 以下の全てのファイルと、 /www/pages 以下の全てのファイルに対して、アクセスを許可します。

[^a]

a を除く全ての 1 文字にマッチします。

31.6.1 プロファイルフラグ

プロファイルフラグは、対応するプロファイルの動作を制御するためのものです。プロファイルの定義内に手作業で指定することで、フラグを追加することができます。プロファイルフラグは下記の書式で設定します:

/path/to/profiled/binary flags=(フラグ) {
  [...]
}

複数のフラグを指定したい場合は、カンマ ',' またはスペース ' ' で区切って指定します。プロファイルフラグには 3 種類のものがあります。モードフラグ、相対フラグ、接続フラグです。

モード フラグには complain フラグ (不正なアクセスが記録されるだけで、拒否はされない) があります。このフラグを指定しない場合、プロファイルは enforce フラグ (実際にポリシーを強制する) が指定されたものとして扱われます。

ヒント
ヒント

プロファイル全体を complain (不平) モードに設定する場合、より柔軟な方法として、 /etc/apparmor.d/force-complain/ ディレクトリ内にシンボリックリンクを作成する方法があります。

ln -s /etc/apparmor.d/bin.ping /etc/apparmor.d/force-complain/bin.ping

相対 フラグには chroot_relative フラグ (ネームスペースではなく chroot に対する相対として扱う) のほか、 namespace_relative フラグ (こちらが既定値で、 chroot の外側で相対として扱う) があります。これらは相互排他です。

接続 フラグには相互排他関係にある 2 対のフラグがあります。 attach_disconnected フラグと no_attach_disconnected フラグ (パス名がネームスペース外に解決された場合、ルートに割り当てるかどうか (つまり、冒頭に '/' があるかどうか)) と、 chroot_attach フラグと chroot_no_attach フラグ (chroot 環境外に存在していて、同じネームスペース内に存在するファイルに対して、 chroot 環境内からのパス名生成の制御) があります。

31.6.2 プロファイル内での変数の使用

AppArmor ではプロファイル内でパスを指定するために変数を使用することができます。グローバル変数を使用することで、作成するプロファイルに可搬性を持たせたり、パスに対するショートカットを定義したりすることができます。

グローバル変数が便利になる例としては、たとえばユーザのホームディレクトリが異なる場所にマウントされるような環境があります。この場合、変数を使用すれば、影響する全てのプロファイルのホームディレクトリを書き換える代わりに、変数の値を書き換えるだけで済みます。グローバル変数は /etc/apparmor.d/tunables 内で定義し、 include ステートメントを利用して参照してください。ホームディレクトリであれば、 /etc/apparmor.d/tunables/home ファイル内に @{HOME}@{HOMEDIRS} の変数定義が存在しています。

一方のローカル変数は、プロファイルの冒頭部に記述します。これは chroot されたパスのベースディレクトリを指定するような場合に有用です。たとえば下記のようになります:

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

下記の例では、 @{HOMEDIRS} でユーザのホームディレクトリが存在するディレクトリを設定し、 @{HOME} ではホームディレクトリの一覧を設定しています。その後、 @{HOMEDIRS} に対して、ホームディレクトリとして使用するディレクトリを追加しています。

@{HOMEDIRS}=/home/
@{HOME}=@{HOMEDIRS}/*/ /root/
[...]
@{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/
注記
注記

現在の AppArmor ツールでは、変数を利用するには、プロファイルを手作業で編集および管理しなければなりません。

31.6.3 パターンマッチ

プロファイル名にグロブ表記を使用することで、複数のバイナリにマッチするプロファイルを作成することができます。

下記の例は、 /usr/bin もしくは /bin 内にある foo というバイナリに対するプロファイル例です。

/{usr/,}bin/foo { ... }

下記の例では、 /bin/foo という実行ファイルの場合、正確にマッチする /bin/foo というプロファイルを選択します。それ以外の、たとえば /bin/fat というプログラムの場合は、 /bin/foo にマッチしませんので、 /bin/f* という名前の、 /bin/** よりも厳密にマッチするプロファイルを選択します。

/bin/foo { ... }

/bin/f*  { ... }

/bin/**  { ... }

プロファイル名におけるグロブの使用例について、詳しくは man 5 apparmor.d で表示されるマニュアルページ (英語) 内の Globbing というセクションをお読みください。

31.6.4 ネームスペース

ネームスペースは異なるプロファイルセットを提供するために使用します。一方をシステム、他方を chroot 環境やコンテナなどに適用するためのものです。また、ネームスペースは階層構造を持っていて、親は子を参照できるものの、子は親を参照できなくなっています。また、ネームスペースは : で始まり、その後ろに英数字の名前を指定したあと、末尾に : と、必要に応じてダブルスラッシュ // を付けます。具体的には下記のようになります:

:childNameSpace://

子ネームスペースに読み込まれたプロファイルには、ネームスペースの指定が冒頭に付与されます (親側からの見た目):

:childNameSpace://apache

ネームスペースは change_profile API のほか、名前付きプロファイル遷移でも指定することができます:

/path/to/executable px -> :childNameSpace://apache

31.6.5 プロファイル名と接続仕様

プロファイルには名前のほか、接続仕様を指定することができます。この仕組みにより、ユーザや管理者にとって分かりやすいプロファイル名を指定しながら、同時に複雑なパターンマッチング (詳しくは 31.6.3項 「パターンマッチ」 をお読みください) を設定することができます。たとえば下記のような既定のプロファイルがあるとします:

/** { ... }

上記のようなプロファイルに対して、下記のように名前を設定することができます:

profile default /** { ... }

パターンマッチングに対しても名前を設定することができます。たとえば:

/usr/lib64/firefox*/firefox-*bin { ... }

上記のようなプロファイルに対して、下記のように名前を設定することができます:

profile firefox /usr/lib64/firefox*/firefox-*bin { ... }

31.6.6 別名ルール

別名ルールは、プロファイルパスのマッピングをサイト固有のレイアウトに変換するためのもう 1 つの方法です。これらは変数を利用してパスを書き換える方式の代替となるものであるほか、変数解決よりも後に動作する仕組みです。別名ルールでは、ルールがターゲットのプレフィクス内に存在するかのように、同じソースプレフィクスを持つルールを扱うよう指定することができます。

alias /home/ -> /usr/home/

上記のように指定すると、 /home/ に対するマッチングが、 /usr/home/ に対しても作用するようになります。たとえば:

/home/username/** r,

上記のような設定が存在すると、下記の意味として使用されるようになります:

/usr/home/username/** r,

別名ルールは、プロファイル自身を書き換えることなく、ルールのマッピングを素早く変更する機能も提供します。もちろん元のパスも従来通り許可されます。上述の例では、別名ルールを設定した後でも、 /home/ は許可され続けます。

また alias ルールを複数指定することで、同時に複数のターゲットを指定することもできます。

alias /home/ -> /usr/home/
alias /home/ -> /mnt/home/
注記
注記

現在の AppArmor ツールでは、別名を利用するには、プロファイルを手作業で編集および管理しなければなりません。

ヒント
ヒント

グローバルな別名を設定したい場合は、 /etc/apparmor.d/tunables/alias ファイル内に設定してください。

31.7 ファイルアクセス許可のアクセスモード

ファイルのアクセス許可モードを指定する場合、下記の中から組み合わせて指定してください:

r

読み込みモード

w

書き込みモード (a とは互いに排他関係にあります)

a

追記モード (w とは互いに排他関係にあります)

k

ファイル施錠 (ロック) モード

l

リンクモード

link ファイル -> ターゲット

リンク対ルール (他のアクセスモードとは共存不可)

31.7.1 読み込みモード (r)

指定したリソースに対して、プログラムからの読み込みアクセスを許可します。読み込みアクセスはシェルスクリプトなどのインタプリタ型のコンテンツで必要となるほか、コアダンプを実施できるかどうかの判断としても使われます。

31.7.2 書き込みモード (w)

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

31.7.3 追記モード (a)

指定したリソースに対して、プログラムからファイルの末尾への書き込みを許可します。 w モードとは異なり、追記モードではファイル内容の上書きが許可されないほか、ファイル名の変更や削除なども行うことができなくなります。追記の許可は通常、アプリケーション側からログファイルへの書き込みを行うような場合に指定すべきもので、これにより既に記録されているログコンテンツの上書きを禁止することができます。追記の許可は書き込みモードのサブセットとして規定されているため、 wa のフラグの両方を指定することはできませんし、相互に排他関係にあるフラグとなります。

31.7.4 ファイル施錠 (ロック) モード (k)

指定したリソースに対して、プログラムからファイル施錠 (ロック) を許可します。従来のバージョンの AppArmor では、アプリケーション側からアクセスができれば、施錠も許可されていました。新しいバージョンの AppArmor では、個別のモードとして規定されるようになっていますので、どうしても施錠が必要なファイルにのみ許可を与えることができますので、サービス拒否攻撃 (DoS; Denial of Service) のような攻撃シナリオを防ぐことができるようになっています。

31.7.7 任意指定の allow および file ルール

プロファイル内では通常、許可するファイルを列挙する仕組みであるため、 allow キーワードを指定する必要はありません。逆に特定のファイルに対して明示的に禁止を設定したい場合にのみ、 deny キーワード (詳しくは 31.7.9項 「拒否ルール」 をお読みください) を指定してください。

allow file /example r,
allow /example r,
allow network,

同様に、 file キーワードも指定不要です。これは、 networkmount などのルール種類のキーワードが現われない限り、自動的に file が指定されたものとして扱われるためです。

file /example/rule r,

上記は、下記と同じ意味になります。

/example/rule r,

下記のルールは全てのファイルに対するアクセスを許可します:

file,

上記は、下記と同じ意味になります。

/** rwmlk,

ファイルルールの場合、アクセス許可を先に記述することもできますが、基本的にはこれを使用すべきではありません。もしもこの方式を使用する場合は、ルールの冒頭で記述してください。これは特に、他の種類のルールと混在させるような場合に重要です。

/path rw,            # 古い形式
rw /path,            # 許可を先に記述した例
file rw /path,       # 明示的に 'file' キーワードを指定した例
allow file rw /path, # 明示的に 'allow' キーワードを指定した例

31.7.8 所有者条件ルール

ファイルルールでは、ファイルの所有者であった場合の特例を設定することができます (fsuid がファイルの uid と一致している必要があります) 。所有者である場合のルールを設定するには、ルールの前に owner キーワードを指定します。所有者条件ルールでも、通常のファイルルールと同様に設定を行うことができます。

owner /home/*/** rw

所有者条件ルールとリンクルールの両方を使用した場合、テストはターゲットのファイルに対して行われ、リンクができるようになるためには、ユーザがファイルを所有していなければならなくなります。

注記
注記: 通常のファイルルールの優先順位について

所有者条件ルールは通常のファイルルールに対するサブセットとして扱われます。通常のファイルルールと所有者条件ルールが重複した場合、それらは一括で扱われます。たとえば下記のようなルールが存在したものとします:

/foo r,
owner /foo rw,  # もしくは単に "w,"

この場合ルールが合成され、全てのユーザに対して r が許可され、所有者にのみ w が許可されます。

ヒント
ヒント

ファイルの所有者 以外の ユーザを明示的に指定したい場合は、 other キーワードを指定してください。

owner /foo rw,
other /foo r,

31.7.9 拒否ルール

拒否ルールは既知のオブジェクトに対して明示的な禁止を設定するための仕組みです。プロファイル生成ツールでは、拒否ルールによる既知の拒否については問い合わせを行いません。また、監査ログにもこの拒否は記録されなくなりますので、ログファイル内に不要な出力を行わないようにすることができます。なお、拒否ルールで拒否された内容も監査ログに出力したい場合は、拒否ルールの指定の前に audit を指定してください。

拒否ルールと許可ルールを混在させることもできます。この場合、幅広く許可ルールを設定しておいて、特定のファイルにのみ明示的な拒否を設定することができるようになります。拒否ルールは所有者条件ルールと組み合わせることもできます。この場合、ユーザが所有するファイルへのアクセスを拒否することができます。下記の例では、ユーザのディレクトリ内にある全てに対して許可を与えるものの、 .ssh/ 以下のファイルについては書き込みを禁止しています:

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

ただし、拒否ルールを数多く設定してしまうようなことは避けてください。これは、プロファイルの可読性を損なうことになってしまうためです。しかしながら、拒否ルールを賢く使用することで、プロファイルを単純化することができます。そのため、ツールでは特定のファイルのみを生成し、グロブを伴う拒否ルールは作成しないようになっています。グロブを利用した拒否ルールを作成したい場合は、手作業でプロファイルを編集してください。ツール側では拒否ルールを操作することはありませんので、それらを含むプロファイルをツールで操作しても問題はありません。

31.8 マウントルール

AppArmor では、マウントやマウント解除の操作を制限することもできます。この制限では、ファイルシステムの種類やフラグなどを設定することもできます。ルールの書式は mount コマンドの書式をベースにしていて、 mount (マウント時), remount (再マウント時), umount (マウント解除時) のキーワードのいずれかを指定します。その他の条件指定は任意で、指定しない場合は全てに対してマッチするものとして扱われます。たとえばファイルシステムを指定しなかった場合、全てのファイルシステムに対してルールが適用されることになります。

条件指定は options= もしくは options in で条件を指定します。

options= では、厳密に一致すべきオプションを指定します。

mount options=ro /dev/foo -E /mnt/,

上記は下記にマッチします:

root # mount -o ro /dev/foo /mnt

ただし、下記にはマッチしません:

root # mount -o ro,atime /dev/foo /mnt
root # mount -o rw /dev/foo /mnt

options in では、使用されているマウントオプションが、ルール内で指定された値のうちのいずれかにマッチすることを求めます。

mount options in (ro,atime) /dev/foo -> /mnt/,

上記は下記にマッチします:

root # mount -o ro /dev/foo /mnt
root # mount -o ro,atime /dev/foo /mnt
root # mount -o atime /dev/foo /mnt

ただし、下記にはマッチしません:

root # mount -o ro,sync /dev/foo /mnt
root # mount -o ro,atime,sync /dev/foo /mnt
root # mount -o rw /dev/foo /mnt
root # mount -o rw,noatime /dev/foo /mnt
root # mount /dev/foo /mnt

複数の条件を設定したい場合は、 options を複数並べて記述してください。

mount options=ro options=atime

上記は下記にマッチします:

root # mount -o ro /dev/foo /mnt
root # mount -o atime /dev/foo /mnt

ただし、下記にはマッチしません:

root # mount -o ro,atime /dev/foo /mnt

複数の指定を行った場合、それらは個別に扱われます。

mount options=ro,
mount options=atime,

上記は下記とは異なります:

mount options=(ro,atime),
mount options in (ro,atime),

下記のルールでは、 /dev/foo デバイスを /mnt/ にマウントすることを許可し、その際に読み込み専用か、 inode のアクセス日時のオプションの指定を許すと共に、 'nodev' と 'user' のオプションの指定も許可しています:

mount options=(ro, atime) options in (nodev, user) /dev/foo -> /mnt/,

上記を指定すると、下記が許可されるようになります:

root # mount -o ro,atime /dev/foo /mnt
root # mount -o nodev /dev/foo /mnt
root # mount -o user /dev/foo /mnt
root # mount -o nodev,user /dev/foo /mnt

31.9 ピボットルートルール

AppArmor ではルートファイルシステムの変更を制限することもできます。書式は下記のとおりです:

pivot_root [oldroot=古いルート] 新しいルート

'pivot_root' 内で指定するパスはディレクトリであるため、 '/' で終わらなければなりません。

# 任意のルートディレクトリを許可する
pivot_root,

# 新しいルートディレクトリは任意で、古いルートディレクトリのみ
# /mnt/root/old/ に制限する
pivot_root oldroot=/mnt/root/old/,

# 新しいルートディレクトリのみ /mnt/root/ に制限する
pivot_root /mnt/root/,

# 古いルートディレクトリを /mnt/root/old/ に、
# 新しいルートディレクトリを /mnt/root/ に制限する
pivot_root oldroot=/mnt/root/old/ /mnt/root/,

# 古いルートディレクトリを /mnt/root/old/ に、
# 新しいルートディレクトリを /mnt/root/ に制限し、
# /mnt/root/sbin/init のプロファイルに遷移する
pivot_root oldroot=/mnt/root/old/ /mnt/root/ -> /mnt/root/sbin/init,

31.10 PTrace ルール

AppArmor では ptrace のシステムコールを制限することもできます。 ptrace ルールは蓄積型のルールで、 ptrace に対する許可は全ての ptrace ルールの和集合となります。ルール内でアクセスリストを指定していない場合は、暗黙に許可が発行されるようになります。

trace および tracedby の許可では ptrace(2) の制御を、 read および readby の許可では proc(5) ファイルシステムへのアクセスや kcmp(2), futexes (get_robust_list(2)), パフォーマンストレースイベントの制御を、それぞれ行うことができます。

ptrace が許可されるようにするには、 ptrace する側とされる側の両方のプロセスに対して、必要な許可を設定する必要があります。つまり、 ptrace する側のプロセスには trace の許可が、 ptrace される側のプロセスには tracedby の許可が必要となります。

AppArmor における PTrace ルールの例:

# 全ての ptrace アクセスを許可する
ptrace,

# 明示的に全ての ptrace アクセスを許可する
ptrace (read, readby, trace, tracedby),

# ptrace(2) の使用を明示的に禁止する
deny ptrace (trace),

# 無制限のプロセス (例: デバッガ) から自身に対する ptrace を許可する
ptrace (readby, tracedby) peer=unconfined,

# /usr/bin/foo 以下のプロファイルを利用している実行中プロセスに対して、 ptrace を許可する
ptrace (trace) peer=/usr/bin/foo,

31.11 シグナルルール

AppArmor ではプロセス間シグナルを制御することもできます。 AppArmor の signal ルールは蓄積型のルールで、シグナルに対する許可は全ての signal ルールの和集合となります。ルール内でアクセスリストを指定していない場合は、暗黙に許可が発行されるようになります。

なお、シグナルの送信側と受信側のプロセスは、両方とも必要な許可を得る必要があります。

signal ルールの例:

# 全てのシグナルへのアクセスを許可する
signal,

# HUP と INT のシグナルのみ明示的に禁止する
deny signal (send) set=(hup, int),

# 無制限プロセスから自分自身へのシグナルを許可する
signal (receive) peer=unconfined,

# /usr/bin/foo 以下のプロファイルで動作するプロセスに対して、
# シグナルの送信を許可する
signal (send) peer=/usr/bin/foo,

# PID の存在チェックを許可する
signal (receive, send) set=("exists"),

# 組み込みの @{profile_name} 変数を使用して、自分自身へのシグナル送信を許可する
signal peer=@{profile_name},

# 2 種類のリアルタイムシグナルを許可する
signal set=(rtmin+0 rtmin+32),

31.12 実行モード

実行モードとは名前付きプロファイル遷移とも呼ばれ、下記のモードが用意されています:

Px

専用プロファイル実行モード

Cx

専用ローカルプロファイル実行モード

Ux

無制限実行モード

ix

継承実行モード

m

mmap(2) コールによる PROT_EXEC の許可

31.12.1 専用プロファイル実行モード (px)

このモードでは、特定のリソースを実行する際の AppArmor のドメイン遷移で、専用のセキュリティプロファイルを求めるようになります。プロファイルが何も定義されていない場合、リソースへのアクセスは拒否されます。

Ux , ux , px , ix とは非互換です。

31.12.2 専用ローカルプロファイル実行モード (cx)

Px と同様に専用のプロファイルを求めますが、 Cx ではグローバルなプロファイルセットを検索するのではなく、現在のプロファイル内にあるローカルのプロファイルを検索します。このプロファイル遷移は、ヘルパーアプリケーションなどに対して個別のプロファイル設定を必要とするような場合に利用します。

注記
注記: 専用ローカルプロファイル実行モード (cx) の制限について

現時点では Cx による遷移はトップレベルのプロファイルに限定され、ハットや子プロファイル内では使用できません。この制限は将来的に撤廃される予定です。

Ux , ux , Px , px , cx , ix とは非互換です。

31.12.3 無制限実行モード (ux)

プログラムに対して、実行時にどの AppArmor プロファイルも適用せずに実行することを指示します。このモードは、プログラム側からマシンの再起動など、特権処理を実行する必要がある場合に有用です。他の実行ファイル内に特権操作の機能を配置し、そこに対して実行権限を与えることで、制限を受けている全てのプロセスに課された制限を迂回できるようになります。なお、ルートプロセスに対して無制限処理を適用すると、 AppArmor のポリシー自身も変更できることになります。制限の内容について、詳しくは apparmor(7) のマニュアルページをお読みください。

ux , px , Px , ix とは非互換です。

31.12.4 安全ではない実行モード

実行モードのうち、小文字版 (具体的には px , cx , ux がそれに該当します) は、非常に限られた条件下でのみお使いください。これらの実行モードでは LD_PRELOAD などの環境変数の洗浄処理を行いませんので、呼び出す側のドメインは呼び出された側のリソースに対して、影響を与えすぎてしまうことがあります。これらのモードは、LD_PRELOAD などの変数を使用しなければならないため、子プロファイル側でどうしても制限を取り外さなければならない場合に のみ 使用すべきです。これらのモードを指定したプロファイルでは、セキュリティが弱くなることに注意してください。また、ご自身の責任のもとお使いください。

31.12.5 継承実行モード (ix)

ix は指定されたプログラムを execve(2) で実行する際、 AppArmor ドメイン遷移を防止する仕組みです。その代わり、現在のプロファイルを継承して実行するようになります。

このモードは、制限を受けているプログラムが他の制限付きのプログラムを呼び出していて、そのプログラム側で追加の許可を設定して欲しくない場合や、現在持っている許可を失いたくない場合に指定します。なお、 ix の実行モードでは権限を変更しないため、環境変数の洗浄を行う版はありません。

cx , ux , px とは非互換です。また、 m の許可を内包します。

31.12.6 実行可能なマッピングの許可 (m)

このモードはファイルをメモリにマッピングする際、 mmap(2) の呼び出しで PROT_EXEC フラグを付けることを許可します。このフラグにより、メモリ内容を実行できるようにします。これはいくつかのアーキテクチャ向けに用意されている、実行不可データページの機能を利用するものです。これにより、ファイルを経由した不正なコード実行を防ぐことができます。 AppArmor ではこのモードを利用し、行儀のよいプログラム (もしくは実行不可メモリへのアクセス制御を強制するアーキテクチャ上の全てのプログラム) に対して、ライブラリとして使用できるファイルを制限し、 ld(1) , LD_PRELOAD , LD_LIBRARY_PATH に対して設定される、無効な -L フラグの効果を制限することができます。詳しくは ld.so(8) のマニュアルページをお読みください。

31.12.7 名前付きプロファイル遷移

既定では、 pxcx (およびそれらのクリーン実行版) の遷移では、実行されるプログラム名に一致するプロファイルに遷移します。名前付きプロファイル遷移では、遷移先のプロファイル名を指定することができます。これは単一のプロファイルを複数のバイナリで共有する必要があるような場合や、名前以外の方法で異なるプロファイルを使用する必要があるような場合に有用です。名前付きプロファイル遷移は cx , Cx , px , Px と併用することができます。現時点では、プロファイルごとに 20 種類までの名前付きプロファイル遷移を設定することができます。

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

/usr/bin/foo
{
  /bin/** px -> shared_profile,
  ...
  /usr/*bash cx -> local_profile,
  ...
  profile local_profile
  {
    ...
  }
}
注記
注記: 通常の遷移と名前付き遷移の違いについて

グロブ機能を利用することで、通常型のプロファイルでは 一対多 の関係を設定することができます。たとえば /bin/** px のように指定すると、 /bin/ping , /bin/cat などのプログラムに対応したプロファイルに遷移することになります。

一方の名前付きプロファイル遷移では、 多対一 の関係を設定することができます。ルールに該当するものであれば、その名前にかかわらず常に同じプロファイルに遷移することになります。

名前付きプロファイル遷移は、ログ内では Nx モードとして記録されます。また、遷移先のプロファイル名は name2 として示されます。

31.12.8 プロファイル遷移に対するフォールバックモード

pxcx はいずれも、強い依存関係を指定していることになります。つまり、指定したプロファイルが存在しない場合、実行は失敗することになります。継承フォールバックの場合は実行が成功しますが、現在のプロファイルを継承して動作することになります。継承フォールバックを指定するには、 cx , Cx , px , Pxix を加えて、 cix , Cix , pix , Pix のように指定してください。

/path Cix -> プロファイル名,

もしくは、下記のように指定してもかまいません:

Cix /path -> プロファイル名,

なお、 -> プロファイル名 の指定は任意です。

同じことが無制限実行モードである ux にも適用できます。これらを組み合わせると、 cux , CUx , pux , PUx になります。これらのモードは、指定したプロファイルが見つからない場合、 無制限に 実行するモードにフォールバックすることになります。

/path PUx -> プロファイル名,

もしくは、下記のように指定してもかまいません:

PUx /path -> profile_name,

なお、 -> プロファイル名 の指定は任意です。

フォールバックモードは、名前付きプロファイル遷移でも使用することができます。

31.12.9 実行モード内での変数設定

Px, Cx, Ux の実行モードのうちのいずれかを選択した場合、子プロセスが継承する環境変数のうち、下記の変数の内容が削除されることに注意してください。そのため、これらの変数に依存して動作するアプリケーションやプロセスが存在した場合、 Px, Cx, Ux のフラグを指定すると、正しく動作しなくなってしまいます:

  • GCONV_PATH

  • GETCONF_DIR

  • HOSTALIASES

  • LD_AUDIT

  • LD_DEBUG

  • LD_DEBUG_OUTPUT

  • LD_DYNAMIC_WEAK

  • LD_LIBRARY_PATH

  • LD_ORIGIN_PATH

  • LD_PRELOAD

  • LD_PROFILE

  • LD_SHOW_AUXV

  • LD_USE_LOAD_BIAS

  • LOCALDOMAIN

  • LOCPATH

  • MALLOC_TRACE

  • NLSPATH

  • RESOLV_HOST_CONF

  • RES_OPTIONS

  • TMPDIR

  • TZDIR

31.12.10 safe キーワードおよび unsafe キーワード

実行モードの修飾子を使用する代わりに、 safeunsafe のキーワードを使用することもできます。たとえば、

/example_rule Px,

上記は下記のいずれかと同じ意味になります:

safe /example_rule px,
safe /example_rule Px,
safe px /example_rule,
safe Px /example_rule,

また、

/example_rule px,

上記は、下記のいずれかと同じ意味になります:

unsafe /example_rule px,
unsafe /example_rule Px,
unsafe px /example_rule,
unsafe Px /example_rule,

safe / unsafe のキーワードは相互に排他なキーワードであり、ファイルルールの owner の後ろに指定することもできます。書式として記述すると、下記のようになります:

[audit] [deny] [owner] [safe|unsafe] ファイルルール

31.13 リソース制限制御

AppArmor では、アプリケーションのリソース制限 (rlimits/ulimits としても知られています) を設定したり制御したりすることができます。既定では AppArmor はアプリケーションの rlimits を制限せず、プロファイル内に書かれた制限にのみ従うようになっています。リソース制限に関する詳細については、 setrlimit(2) , ulimit(1) , ulimit(3) の各マニュアルページをお読みください。

AppArmor ではシステム側に用意された rlimits を活用しているだけであり、通常発生するような追加の監査を提供するものではありません。また、システム側で設定された rlimits の値を増やすこともできず、 AppArmor ではアプリケーションに対して設定されたリソース制限を減らす設定のみを適用することができます。

設定された値は子プロセスに対しても引き継がれ、新しいプロファイルに遷移した場合であっても、アプリケーションの制限がなくなった場合でも、制限が残ります。そのため、アプリケーションが新しいプロファイルに遷移した場合、遷移先のプロファイルではアプリケーションの rlimits をさらに減らすことしかできなくなります。

AppArmor の rlimit ルールでは、アプリケーションのハードリミットの仲介処理も行っています。アプリケーション側では、プロファイル内で指定された値よりもハードリミットを増やすことはできませんが、新しいプロファイル内で制限を増やすように設定しておいて、そのプロファイルに遷移するように設定することは自由に行うことができます。

AppArmor での rlimit の制御においてソフトリミットは、ハードリミットと同じか、より小さい値に設定されているようにするだけで、それ以外の制御は行いません。

AppArmor のハードリミットルールは下記のような書式で指定します:

set rlimit リソース <= ,

リソース には、それぞれ下記のものを指定することができます:

cpu

CPU 時間の制限 (秒単位) 。

fsize , data , stack , core , rss , as , memlock , msgqueue

バイト単位での数値、もしくは K/KB (キロバイト), M/MB (メガバイト), G/GB (ギガバイト) の接尾辞付きの数値を指定することができます。例:

rlimit data <= 100M,
fsize , nofile , locks , sigpending , nproc * , rtprio

0 以上の数値を指定することができます。

nice

-20 から 19 までの数値を指定することができます。

* nproc のリソース制限は、その他のリソース制限とは異なる動作になっています。標準的なプロセス制限ではなく、任意の時点でのプロファイル内の最大プロセス数を意味します。新しいプロセスを作成する際、プロファイルで指定された制限に引っかかると、現在実行中のプロセス数が減らない限り、処理が失敗することになります。

注記
注記

現時点では、ツールを利用してプロファイル内に rlimit のルールを追加することはできません。 rlimit の制御を追加する唯一の方法は、手作業でテキストファイルを利用してプロファイルを編集する方法です。なお、 rlimit を含むプロファイルをツールで編集しても、 rlimit の項目を削除することはありませんので安全です。

31.14 監査ルール

AppArmor では、特定のルールに監査を設定して、監査ログ内にメッセージを出力するようにすることができます。指定したルールに対して監査メッセージを出力するように設定するには、ルールの前に audit キーワードを指定します:

audit /etc/foo/*        rw,

特定の処理時にのみ監査メッセージを出力させたい場合は、ルールを 2 つに分割することをお勧めします。下記の例では、ファイルを書き込み用に開いた場合は監査メッセージを出力するものの、読み込み用に開いた場合は出力しません:

audit /etc/foo/*  w,
/etc/foo/*        r,
注記
注記

監査メッセージはそれぞれの読み込みや書き込み処理で生成されるのではなく、ファイルが読み込み用や書き込み用に開いた際に出力されます。

監査ルールには owner / other の条件付きファイルルールを追加することもできます。これにより、ユーザが所有するファイルである場合や、ユーザが所有していないファイルである場合にのみ、監査メッセージを出力することができるようになります:

audit owner /home/*/.ssh/**       rw,
audit other /home/*/.ssh/**       r,
このページを印刷