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

/usr/bin/foo {
...
}

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

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

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

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

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

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

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

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

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

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

change_profile -> /usr/bin/foobar,

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

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

change_hat はアプリケーションが仮想マシンやインタプリタを動作させるような場合に最適な仕組みで、それらの仮想マシンやインタプリタがアプリケーションのリソースへのアクセスを提供しないような場合に適切です (たとえば Apache の 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 に設定します。

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

/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 環境内からのパス名生成の制御) があります。

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 ツールでは、変数を利用するには、プロファイルを手作業で編集および管理しなければなりません。

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

下記の例は、 /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 というセクションをお読みください。

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

:childNameSpace://

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

:childNameSpace://apache

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

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

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

/** { ... }

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

profile default /** { ... }

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

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

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

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

別名ルールは、プロファイルパスのマッピングをサイト固有のレイアウトに変換するためのもう 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 ファイル内に設定してください。

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

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

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

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

リンクモードはハードリンクに対するアクセスを許可します。リンクを作成すると、ターゲットとなるファイルと元のファイルは同じアクセス許可になります (ただしリンク先のファイルにはリンクモードの指定は不要です) 。

リンクモードでは任意のファイルに対してリンクを作成する許可を与えますが、これはリンクがターゲットによって付与された許可のサブセットを持っている場合に限られます (サブセット許可テストと呼びます) 。

/srv/www/htdocs/index.html rl,

リンク元とリンク先を指定することで、リンク対ルールはハードリンクの作成方法に関して、より広い制御を提供します。リンク対ルールは、既定では標準ルールのリンク許可が必要とする、リンクのサブセット許可テストを強制しません。

link /srv/www/htdocs/index.html -> /var/www/index.html

テストを必要とするようルールを強制するには、 subset キーワードを指定します。下記の 2 つのルールは同じ意味になります:

/var/www/index.html l,
link subset /var/www/index.html -> /**,

注記

現時点では、リンク対ルールは YaST やコマンドラインツールでサポートしていません。この種類のルールを使用したい場合は、プロファイルを手作業で編集してください。なお、ツール側ではリンク対ルールを操作することはありませんので、それらを含むプロファイルをツールで操作しても問題はありません。

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

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

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

file /example/rule r,

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

/example/rule r,

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

file,

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

/** rwmlk,

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

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

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

owner /home/*/** rw

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

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

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

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

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

ヒント

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

owner /foo rw,
other /foo r,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

既定では、 px と cx (およびそれらのクリーン実行版) の遷移では、実行されるプログラム名に一致するプロファイルに遷移します。名前付きプロファイル遷移では、遷移先のプロファイル名を指定することができます。これは単一のプロファイルを複数のバイナリで共有する必要があるような場合や、名前以外の方法で異なるプロファイルを使用する必要があるような場合に有用です。名前付きプロファイル遷移は 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 として示されます。

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

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

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

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

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

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

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

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

PUx /path -> profile_name,

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

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

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

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

/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] ファイルルール