不審なアプリケーションの動作が見つかった場合や、何らかの問題が見つかった場合、まずはログファイル内を調査して、 AppArmor がアプリケーションの動作を阻害していないかどうかを調べてください。お使いのアプリケーションでの正常な動作で、 AppArmor のプロファイルが厳しく制限しすぎていることが判明した場合は、アプリケーションの動作にあわせてプロファイルを更新し、適切に動作できるように設定してください。この作業は aa-logprof ( 33.7.3.9項 「aa-logprof: システムログのスキャン」 ) で実施することができます。

AppArmor の保護を外してアプリケーションやサービスを動作させたい場合は、 /etc/apparmor.d ディレクトリ内にあるアプリケーションのプロファイルを削除するか、別の場所に移動させてください。

以前のバージョンの AppArmor を使用していて、プロファイルを維持したままシステムを更新すると、以前は完璧に動作していたにもかかわらず、正しく動作しなくなってしまったり、全く動作しなくなったりすることがあります。

本バージョンの AppArmor では、プロファイルの書式に影響する新しい機能と、古いバージョンの AppArmor プロファイルでは問題が発生する可能性のある AppArmor ツールが含まれています。具体的には下記のとおりです:

現在のバージョンの AppArmor ではファイルロックの権限についても制限を行うことができるようになり、対応する許可モードとして ( k ) が新設されています。ファイルロックを要求するアプリケーションがある場合、古いプロファイルをそのまま実行してしまうと、明示的な許可が無いことから、正しく動作しなかったり、エラーが発生したりすることがあります。このような現象に直面した場合は、まず /var/log/audit/audit.log をご覧ください。この問題であれば、下記のような項目が出力されているはずです:

type=AVC msg=audit(1389862802.727:13939): apparmor="DENIED" \
operation="file_lock" parent=2692 profile="/usr/bin/opera" \
name="/home/tux/.qt/.qtrc.lock" pid=28730 comm="httpd2-prefork" \
requested_mask="::k" denied_mask="::k" fsuid=30 ouid=0

この場合は、上述の手順で aa-logprof を使用し、プロファイルを更新してください。

また、新しいネットワークアクセス制御の書式では、ネットワークファミリと種類の指定を行うようになっています (詳しくは 30.5項 「ネットワークアクセス制御」 をお読みください) 。この機能追加により、アプリケーションの動作が阻害されたり、全く動作しなくなったりすることがあります。ネットワーク関連のアプリケーションの動作が不審である場合は、まず /var/log/audit/audit.log をご確認ください。この問題であれば、下記のような項目が出力されているはずです:

type=AVC msg=audit(1389864332.233:13947): apparmor="DENIED" \
operation="socket_create" family="inet" parent=29985 profile="/bin/ping" \
sock_type="raw" pid=30251 comm="ping"

上記のログ項目は /bin/ping での出力例ですが、このログによると AppArmor のネットワーク接続機能の許可獲得に失敗しています。アプリケーションがネットワークアクセスを行う場合、この許可は明示的に設定しなければなりません。新しい書式にあわせてプロファイルを更新するには、上述のとおり aa-logprof を利用して更新してください。

現在のカーネルでは、 /proc/PID/fd/* 内のファイルにアクセスする場合、 SYS_PTRACE のケーパビリティを必要とするようになっています。新しいプロファイルではファイルとケーパビリティの両方を設定しますが、古いプロファイルではファイルの設定しか行っていません。たとえば下記のようになっているはずです:

/proc/*/fd/**  rw,

新しいカーネルを使用する場合は、下記のように修正してください:

capability SYS_PTRACE,
/proc/*/fd/**  rw,

新しい書式にあわせてプロファイルを更新するには、 YaST のプロファイル更新ウイザードを使用するか、上述の aa-logprof コマンドをお使いください。

このバージョンの AppArmor では、プロファイル内のルール書式に対していくつかの変更が加えられています。これにより、ディレクトリとファイルの各アクセスを区別しやすくなっています。そのため、以前のバージョンではファイルとディレクトリの両方にマッチするルールであっても、現在のバージョンではファイルにのみマッチするようになっていることがあります。このような理由により、 AppArmor が必要なディレクトリへのアクセスを拒否してしまい、アプリケーションが正しく動作しなくなってしまうことがあります。下記の例では、パスの書式に関する変更点の概要を説明しています。

古い書式では、下記のルールは /proc/net 以下のファイルとディレクトリの両方に対してアクセスを許可していました。またディレクトリに対しては、ディレクトリ内のファイルの読み込みアクセスのみが許可され、その中のファイルやディレクトリへのアクセスは与えられていませんでした。たとえば /proc/net/dir/foo はアスタリスク (*) でマッチしますが、 foo は dir 以下のファイルもしくはディレクトリであるため、アクセスを与えられていないことになります。

/proc/net/*  r,

新しい書式で同じような許可を設定したい場合は、 2 つの項目に分けて設定する必要があります。 1 つめのルールで /proc/net 以下のファイルに対するアクセス許可を設定し、 2 つめのルールで /proc/net 以下のディレクトリに対してアクセス許可を設定します。ディレクトリへのアクセスは、その中にある項目の一覧を取得するために使用するもので、ディレクトリ内にあるファイルやディレクトリに対する許可にはなりません。

/proc/net/*  r,
/proc/net/*/  r,

なお、下記のルールは古い書式でも新しい書式でも同じように動作するルールで、 /proc/net 以下のファイルとディレクトリの両方に対してアクセス許可を設定しています (ただし、 /proc/net/ 自身の内容一覧は許可していません):

/proc/net/**  r,

上述の新しい書式でファイルとディレクトリのアクセスを区別したい場合は、下記のように 2 つのルールに分割してください。 1 つめのルールは /proc/net 以下のディレクトリに対するアクセス許可を再帰的に設定していて、 2 つめのルールはファイルに対するアクセス許可を再帰的に設定しています。

/proc/net/**/  r,
/proc/net/**[^/]  r,

また、下記の例は古い書式でも新しい書式でも同じように動作するルールで、 /proc/net 以下の foo で始まるファイルやディレクトリに対して、許可を設定しています:

/proc/net/foo**  r,

新しい書式でファイルアクセスとディレクトリアクセスを区別し、 ** というグロブパターンを使用したい場合は、下記のように 2 つのルールに分割してください。 1 つめのルールでは古い書式でファイルとディレクトリの両方にマッチしますが、新しい書式では末尾にスラッシュがないことから、ファイルにのみマッチします。 2 つめのルールは、古い書式ではファイルにもディレクトリにもマッチしませんが、新しい書式ではディレクトリにのみマッチします:

/proc/net/**foo  r,
/proc/net/**foo/  r,

また、下記のルールでは ? のグロブパターンを使用していますが、こちらの使用方法についても変更がされています。古い書式では、 1 つめのルールはファイルとディレクトリの両方にマッチします (4 文字で末尾がスラッシュ以外のもの) 。ですが新しい書式では、ファイルにのみマッチします (末尾にスラッシュがないため) 。 2 つめのルールは古い書式では何にもマッチしませんが、新しい書式ではディレクトリにのみマッチします。最後のルールは /proc/net/foo? 以下の bar というファイルにマッチしますが、古い書式ではファイルだけでなく、ディレクトリにもマッチしてしまいます:

/proc/net/foo?  r,
/proc/net/foo?/  r,
/proc/net/foo?/bar  r,

書式の変更に伴う問題を検出および解決するには、システムの更新後にそれぞれのアプリケーションに対して下記の手順でプロファイルの確認を行います:

Apache に対して新しいモジュール (例: apache2-mod_apparmor) を追加したり、設定を変更したりした場合は、 Apache のプロファイルを必要に応じて更新する必要があるかもしれません。 Apache のプロファイルを更新しないと、正しく起動しなくなってしまったり、正しく Web ページを提供できなくなったりすることもあります。

プログラム名 に対するプロファイルを無効化したい場合は、 aa-disable プログラム名 と入力して実行してください。このコマンドは、プロファイルに対するシンボリックリンクを /etc/apparmor.d/disable/ 内に作成します。プロファイルを再度有効に戻したい場合は、シンボリックリンクを削除して systemctl reload apparmor を実行してください。

AppArmor でプロファイルを管理するにあたっては、お使いのシステム内で動作していた際のログファイルにアクセスする必要があります。そのため、実際にアプリケーションの動作しているマシンからログを採取できる環境であれば、プロファイル構築用のマシンを動作させる必要はありません。このほかにも、一方のシステムでアプリケーションを動作させておいて、ログ (audit がインストールされていれば /var/log/audit.log 、インストールされていなければ journalctl | grep -i apparmor > ログファイルのパス) をプロファイル構築用のホストに転送して、 aa-logprof -f ログファイルのパス のように実行する方法もあります。

AppArmor のプロファイルを手作業で編集していると、書式のミスを起こす可能性があります。 AppArmor のプロファイル内に文法エラーがあると、 AppArmor の起動時や再起動時にエラーが発生します。下記の例では、全体的なパーサーエラーが発生している様子を示しています:

#  systemctl start apparmor.service
Loading AppArmor profiles AppArmor parser error in /etc/apparmor.d/usr.sbin.squid \
 at line 410: syntax error, unexpected TOK_ID, expecting TOK_MODE
Profile /etc/apparmor.d/usr.sbin.squid failed to load

AppArmor の YaST ツールを使用することで、プロファイル内に含まれているエラーの詳細と、その修正を促すメッセージをグラフィカルに表示することができます。

文法エラーを修正するには、端末ウインドウで root になり、プロファイルを開いてエラーを修正します。修正が終わったら、 systemctl reload apparmor と入力して実行することで、プロファイルセットを再読み込みさせることができます。

ヒント: vi による AppArmor の文法ハイライト機能について

openSUSE Leap で vi エディタを使用すると、 AppArmor のプロファイル編集時に文法ハイライト機能を使用することができます。この文法ハイライト機能では、書式エラーは赤い背景色で示されます。