アプリケーションの動作が奇妙なものになってしまった場合や、アプリケーション を利用していて何らかの問題が発生した場合、まずは AppArmor がアプリケーションを 制限しすぎていないかどうかを調べるため、ログファイル内の拒否メッセージを 確認してください。 アプリケーションに対する AppArmor での制限が厳しすぎることによって拒否メッセージが 生成されていた場合は、プロファイルを更新して正しく制限されるようにする必要が あります。これを行なうには、 YaST から プロファイルの更新ウイザード を利用して行ないます。詳しくは 22.5項 「ログ項目からのプロファイル更新」 を お読みください。

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

以前のバージョンの AppArmor をお使いの場合で、お使いのシステムを更新した 場合 (ただしプロファイルは従来のまま) は、以前にきちんと動作していた アプリケーションが正しく動作しなくなってしまったり、場合によっては 全く動作しなくなってしまったりする場合があります。

このバージョンの AppArmor では、プロファイルの文法に対して新しい機能が導入 されているため、古いバージョンの AppArmor プロファイルでは、 AppArmor のツールを 利用するにあたって、問題が発生する場合があります。対象となる機能は下記の とおりです:

現在のバージョンの AppArmor では、ファイルロック (施錠) を取り扱うことができる ようになっていて、 (k) という許可モードが用意されています。 ファイルロックを必要とするアプリケーションが、古いバージョン向けのプロファイル で制限されている場合、ファイルロックの許可が設定されていないために誤った 動作をしてしまったり、失敗してしまったりする場合があります。このような場合は、 /var/log/audit/audit.log ファイル内に下記のような項目が 出力されているはずです:

type=APPARMOR_DENIED msg=audit(1188913493.299:9304): operation="file_lock" requested_mask="::k" denied_mask="::k" fsuid=1000 name="/home/tux/.qt/.qtrc.lock" pid=25736 profile="/usr/bin/opera"

上記のような項目を確認したら、あとは YaST のプロファイル更新ウイザードや aa-logprof コマンドを利用し、プロファイルを更新してください。

また、新しいネットワークアクセス制御文法は、ネットワークのファミリと種類を ベースにしているため (詳細は 20.5項 「ネットワークアクセス制御」 をお読みください) 、アプリケーションが誤動作してしまったり、全く動作 しなかったりする場合があります。ネットワーク関連のアプリケーションが 正しく動作しない場合は、 /var/log/audit/audit.log ファイル内に下記のような項目が出力されていることを確認してください:

type=APPARMOR_DENIED msg=audit(1188894313.206:9123): operation="socket_create" family="inet" sock_type="raw" protocol=1 pid=23810 profile="/bin/ping"

上記のログ項目は /bin/ping というコマンドでの例ですが、 ネットワークの接続を開くにあたって AppArmor の許可が得られなかったことを示して います。許可はアプリケーションがネットワークにアクセスするにあたって、 明示的に設定されていなければなりません。 YaST のプロファイル更新 ウイザードや 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/**  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 文字で、最後の文字がスラッシュである 場合もあります) 。新しい文法では、 1 つめのルールはファイルにのみ該当する ルールになります (最後のスラッシュが無いため) 。また、 2 つめのルールは 古い文法ではいずれにも該当しないルールですが、新しい文法ではディレクトリ にのみ該当するルールになります。最後のルールは /proc/net/foo? 内にある bar ファイルにのみ該当するルールですが、 古い文法ではファイルとディレクトリの両方に該当するルールになります:

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

文法の仕様変更に関連する問題を発見して解決するには、更新作業後にしばらく 時間をかけてプロファイルを確認し、各アプリケーションに対して下記の手順を 行ないます:

AppArmor のコマンドラインツールを使用する場合、下記の手順で行ないます:

現時点では、 KDE は独自のプロセス管理方法をとっているため、他のアプリケーション と同じ方法では KDE アプリケーションを制限することができません。

KDE アプリケーションを制限したい場合は、下記に示すいずれかのアプローチで 制限を行なってください。ただし、下記に示すものはいずれも、標準のセットアップには 適しません:

Apache に対して新しいモジュールをインストールしたり、設定を変更したりした 場合には、 Apache が正しく起動しなかったり Web ページを正しく提供しなかったり する場合があります。追加のモジュール (たとえば apache2-mod_apparmor など) をインストールした場合や、 Apache の設定を変更した場合は、プロファイルに 追加すべき項目を判断させるため、プロファイルを作成し直してください。

特定のプログラムに対するプロファイルを無効化するには、 aa-disable PROGRAMNAME を実行します。 ここで、 PROGRAMNAME にはプログラムの名前を 指定します。 このコマンドは /etc/apparmor.d/disable/ 内にシンボリック リンクを作成することで無効化しますので、無効化を解除したい場合は単純に シンボリックリンクを削除してください。

AppArmor でプロファイルを管理するには、アプリケーションが動作しているシステム のログファイルに対して、アクセスを行なう必要があります。ログファイルにさえ アクセスできれば、プロファイルを利用してアプリケーションを起動させる必要は ありません。一方のシステムでアプリケーションを動作させ、ログ (audit がインストールされていれば /var/log/audit.log 、インストールされていなければ /var/log/messages) をプロファイル構築側のホストに 転送し、 aa-logprof -f path_to_logfile を実行してください。

AppArmor を手作業で修正した場合、文法エラーが発生する場合があります。お使いの プロファイル内に文法エラーがある状態で AppArmor を起動したり再起動したりすると、 エラーが表示されます。たとえば下記のように文法エラーが表示されます。

localhost:~ # rcapparmor start
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 で端末ウインドウを開いて、そこから プロファイルを開いて修正してください。プロファイル集の再読み込みは、 rcapparmor reload で行なうことができます。

	vi での AppArmor 文法ハイライト表示
openSUSE での vi には、 AppArmor プロファイルの 文法ハイライト表示機能が備わっています。文法エラーの行は、赤い背景で表示 されます。