この章では、メンテナンス関連の作業について説明しています。たとえば AppArmor® の更新方法のほか、 AppArmor が提供する各種コマンドラインツールの使用方法に ついてマニュアルページを読む方法などが書かれています。また、トラブル シューティングの章では、 AppArmor を使用するにあたってよく発生する問題と、 それらの解決策について説明しています。それ以外にも、 AppArmor に対する 不具合や機能拡張リクエストなどの説明もあります。
AppArmor パッケージに対する更新は、その他の openSUSE 向け更新パッケージと同じ方法で提供されます。そのため、他のパッケージと同様に 取得し適用してください。
ヘルプの一部としてマニュアルページが用意されています。端末ウインドウから man apparmor と入力すると、 apparmor のマニュアルページを 表示することができます。マニュアルページには 1 から 8 までのセクションが存在して いて、それぞれ下記のような分類になっています:
表27.1 マニュアルページ: セクションと分類
セクション |
分類 |
---|---|
1 |
ユーザ向けのコマンド |
2 |
システムコール |
3 |
ライブラリ関数 |
4 |
デバイスドライバの情報 |
5 |
設定ファイルの書式 |
6 |
ゲーム類 |
7 |
高レベルなコンセプト説明 |
8 |
管理者向けコマンド |
このセクション番号は、それぞれのマニュアルページを区別するために使用します。
たとえば exit(2)
というマニュアルページは、 exit
という名前のシステムコールを説明していますが、 exit(3)
というマニュアルページでは、 exit という名前の C 言語のライブラリ関数を
説明しています。
AppArmor におけるマニュアルページは下記のとおりです:
unconfined(8)
autodep(1)
complain(1)
enforce(1)
genprof(1)
logprof(1)
change_hat(2)
logprof.conf(5)
apparmor.conf(5)
apparmor.d(5)
apparmor.vim(5)
apparmor(7)
apparmor_parser(8)
AppArmor 製品について、より詳しい情報は http://wiki.apparmor.net をお読みください。
また、この文書を含む AppArmor 製品の文書をお読みになりたい場合は、
インストール済みシステムで /usr/share/doc/manual
ディレクトリを開いてください。
AppArmor について、開発者とユーザの間で対話できるよう開設されている メーリングリストがあります。 詳しくは https://lists.ubuntu.com/mailman/listinfo/apparmor をお読みください。 なお、いずれのメーリングリストとも英語によるものであることにご注意ください。
この章では、 AppArmor でよく発生する問題やエラーメッセージについて説明 しています。
アプリケーションの動作が奇妙なものになってしまった場合や、アプリケーション を利用していて何らかの問題が発生した場合、まずは AppArmor がアプリケーションを 制限しすぎていないかどうかを調べるため、ログファイル内の拒否メッセージを 確認してください。 アプリケーションに対する AppArmor での制限が厳しすぎることによって拒否メッセージが 生成されていた場合は、プロファイルを更新して正しく制限されるようにする必要が あります。これを行なうには、 YaST から 22.5項 「ログ項目からのプロファイル更新」 を お読みください。
を利用して行ないます。詳しくは
AppArmor の保護無しでアプリケーションやサービスを動作させたい場合は、
/etc/apparmor.d
ディレクトリ内にあるアプリケーションの
プロファイルを削除するか、別の場所に移動させてください。
以前のバージョンの AppArmor をお使いの場合で、お使いのシステムを更新した 場合 (ただしプロファイルは従来のまま) は、以前にきちんと動作していた アプリケーションが正しく動作しなくなってしまったり、場合によっては 全く動作しなくなってしまったりする場合があります。
このバージョンの AppArmor では、プロファイルの文法に対して新しい機能が導入 されているため、古いバージョンの AppArmor プロファイルでは、 AppArmor のツールを 利用するにあたって、問題が発生する場合があります。対象となる機能は下記の とおりです:
ファイルロック (施錠)
ネットワークアクセス制御
SYS_PTRACE
機能 (ケーパビリティ)
ディレクトリパスへのアクセス
現在のバージョンの 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 が動作していて、アプリケーションのプロファイルが読み込まれている ことを確認します。
YaST の AppArmor コントロールパネルを起動し、アプリケーションのプロファイル を不平モードに切り替えます。現在のプロファイルに対する違反事例に対して ログが効くされるものの、プロファイルは強制されることはなく、アプリケーション の動作が阻害されることはありません。
そのアプリケーションに対して期待する、すべての処理を実行します。
YaST のプロファイル更新ウイザードを起動し、アプリケーションの起動中に 生成されたログ項目をプロファイルに反映させます。
プロファイルを更新したら、再度 YaST の AppArmor コントロールパネルから 強制モードに切り替えます。
AppArmor のコマンドラインツールを使用する場合、下記の手順で行ないます:
まずはアプリケーションのプロファイルを不平モードに切り替えます:
aa-complain /path/to/application
アプリケーションを実行します。
アプリケーションの起動中に生成されたログ項目をプロファイルに反映させます:
aa-logprof /path/to/application
プロファイルを強制モードに戻します:
aa-enforce /path/to/application
現時点では、 KDE は独自のプロセス管理方法をとっているため、他のアプリケーション と同じ方法では KDE アプリケーションを制限することができません。
KDE アプリケーションを制限したい場合は、下記に示すいずれかのアプローチで 制限を行なってください。ただし、下記に示すものはいずれも、標準のセットアップには 適しません:
すべての KDE プロセスは特定の親に対する子プロセスであるため、 AppArmor では 個別のアプリケーションプロセスを識別することができません。そのため、 巨大な 1 つのプロファイルを作成して、一括でデスクトップを制限する必要が あります。このアプローチは用途が限定されている (キオスク型の) ような場合 にのみ有用なものであり、標準的な KDE デスクトップ (アプリケーション類を 含む) に対してプロファイルを管理するのは不可能です。
KDE_EXEC_SLAVES=1
と KDE_IS_PRELINKED=1
の変数を指定することで、 KDE に対して個別のアプリケーションプロセスを
識別できるようにする方法です。このアプローチを利用すると、お使いの
デスクトップ環境が目に見えて遅くなってしまうため、速度面の要件が厳しい
場合には不適です。なお上記の環境変数は、 KDM/XDM/GDM や startx を起動
する前に設定する必要があります。これを設定するための方法として、
/etc/security/pam_env.conf
内にそれらを記述する
方法があります。
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 での |
AppArmor の開発者は AppArmor がもっとも高品質な製品であり続けることを望んで います。フィードバックやバグレポートは品質を高めるための支援となるもので あるため、 AppArmor 内にバグと思われる事象を発見した場合は、下記の手順で バグをご報告ください。 なお、バグ報告はすべて英語での対応となります。あらかじめご了承ください。
Web ブラウザを起動し、 https://bugzilla.novell.com/index.cgi を開きます。
Novell アカウントに関する情報を入力し、
を押します。Novell アカウントをお持ちでない場合:
下記の手順で Novell アカウントを作成します:
ページにある を押します。
ユーザ名とパスワードをそれぞれ入力し、追加のアドレスデータを入力した あと、
を押すと、ログインを即時に作成 することができます。もしくは、下記の手順を実施します
すべてのアカウントを一括で管理したい場合は、管理者のアカウント情報を 入力します。
を押して、既に類似の問題が報告されて いないかどうかを確認します。製品名やキーワードを入力して簡易検索するか、 もしくは を使用します。
既に報告済みの問題であった場合は、そのバグ報告を確認し、もしも追加できる 情報があればそれを記入します。
まだ報告されていない問題であった場合は、上部のナビゲーションバーから
を押し、 ページに 入ります。バグを報告する対象製品を選択します。この場合は、お使いの製品リリースを 選択します。選択したら
を押します。次に製品のバージョンとコンポーネント (この場合は AppArmor) 、ハードウエア プラットフォームとバグの重大度を選択します。
問題点の概要を入力し、ログファイルなどの詳細説明を記述します。 スクリーンショットやログファイル、テスト手順などの添付ファイルをバグに 追加するとよりわかりやすくなります。
すべての詳細を記入したら
を押します。すると、 記入した報告が開発者に送信されます。