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

38 サポート

本章では、メンテナンスに関連する作業を説明しています。 AppArmor® の更新方法のほか、 AppArmor が提供するコマンドラインツールを使用するための基礎情報となる、マニュアルページの一覧取得方法などを説明しています。また、トラブルシューティングの章では、 AppArmor で一般的に直面する様々な問題や、その解決方法を説明しています。このほか、 AppArmor に対する欠陥報告や機能拡張のリクエスト方法などについても、説明しています。

38.1 AppArmor のオンライン更新

AppArmor 自身の更新は、 openSUSE Leap での他のパッケージの更新と同様の形態で提供されます。 openSUSE Leap に同梱されているその他のパッケージと同様の手段で取得し、適用を行ってください。

38.2 マニュアルページの使用

様々なコマンドに対してマニュアルページが用意されています。 AppArmor のマニュアルページをお読みになりたい場合は、端末を開いて man apparmor と入力し、実行してください。マニュアルページはセクション 1 から 8 までに分類され、セクションはマニュアルページの分類として機能しています:

表 38.1: マニュアルページ: セクションと分類

セクション

分類

1

ユーザコマンド

2

システムコール

3

ライブラリ関数

4

デバイスドライバの情報

5

設定ファイルの書式

6

ゲーム

7

高レベルな考え方の説明

8

管理者向けコマンド

セクション番号は、同じ名前のマニュアルページを識別する方法として使用されています。たとえば exit(2) であれば exit という名前のシステムコールに関する説明を、 exit(3) であれば exit という名前の C 言語ライブラリ関数に関する説明が書かれています。

AppArmor のマニュアルページは下記のとおりです:

  • aa-audit(8)

  • aa-autodep(8)

  • aa-complain(8)

  • aa-decode(8)

  • aa-disable(8)

  • aa-easyprof(8)

  • aa-enforce(8)

  • aa-enxec(8)

  • aa-genprof(8)

  • aa-logprof(8)

  • aa-notify(8)

  • aa-status(8)

  • aa-unconfined(8)

  • aa_change_hat(8)

  • logprof.conf(5)

  • apparmor.d(5)

  • apparmor.vim(5)

  • apparmor(7)

  • apparmor_parser(8)

  • apparmor_status(8)

38.3 さらなる情報

AppArmor に関して更に詳しい情報を見つけたい場合は、 http://wiki.apparmor.net にある AppArmor の Wiki (英語) をご覧になることをお勧めします。また、 AppArmor に関する製品ドキュメンテーションをお読みになりたい場合は、パッケージをインストールしたあと /usr/share/doc/manual ディレクトリ内をお探しください。

このほか、ユーザが投稿できる AppArmor 向けメーリングリストや、開発者と対話するためのメーリングリストも用意されています。詳しくは https://lists.ubuntu.com/mailman/listinfo/apparmor (英語) をお読みください。

38.4 トラブルシューティング

本章では、 AppArmor を利用していてよく発生する問題やエラーメッセージについて説明しています:

38.4.1 おかしなアプリケーション動作に対する対応

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

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

38.4.2 プロファイルが期待通りに動作しない場合の対応

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

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

  • ファイルロック (施錠) 関連

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

  • SYS_PTRACE のケーパビリティ

  • ディレクトリパスへのアクセス

現在のバージョンの 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 を使用し、プロファイルを更新してください。

また、新しいネットワークアクセス制御の書式では、ネットワークファミリと種類の指定を行うようになっています (詳しくは 31.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 はアスタリスク (*) でマッチしますが、 foodir 以下のファイルもしくはディレクトリであるため、アクセスを与えられていないことになります。

/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,

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

  1. まずはアプリケーションのプロファイルを不平モードに切り替えます:

    tux > sudo aa-complain アプリケーションのパス

    このように設定することで、プロファイルへの違反は記録されるものの、プロファイルが強制されることはなく、アプリケーションの動作も阻害されなくなります。

  2. アプリケーションの動作を一通り試して、必要なリソースに一通りアクセスさせます。

  3. あとはアプリケーションの実行時に生成されたログ項目にあわせて、プロファイルを更新します:

    tux > sudo aa-logprof アプリケーションのパス
  4. 最後にプロファイルを強制モードに戻します:

    tux > sudo aa-enforce アプリケーションのパス

38.4.3 Apache での問題解決

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

38.4.4 使用するプロファイルの一覧から特定のプロファイルを除外する方法

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

38.4.5 システムにインストールされていないアプリケーションのプロファイル管理方法

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

38.4.6 AppArmor の文法エラーの検出および修正方法

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

root #  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 Leapvi エディタを使用すると、 AppArmor のプロファイル編集時に文法ハイライト機能を使用することができます。この文法ハイライト機能では、書式エラーは赤い背景色で示されます。

38.5 AppArmor のバグ報告

AppArmor の開発者は、この製品を最高の品質に仕上げたいと考えています。フィードバックやバグ報告などがあれば、この品質を更に高めることになります。 AppArmor で何らかのバグを見つけた場合は、この製品に対してバグ報告を行ってください 。なお、やり取りはすべて英語にてお願いいたします:

  1. Web ブラウザを開いて http://bugzilla.opensuse.org/ に移動し、 Log In を押します。

  2. SUSE アカウントのデータを入力して Login を押します。 SUSE のアカウントをお持ちでない場合は、 Create Account を押して、必要な情報を入力してください。

  3. 既に同じ問題が報告されている場合は、そのバグレポートを開いて、補足できる情報があれば情報提供を行ってください。

  4. これまでに同じ問題が報告されていない場合は、上部のナビゲーションバーから New を押して、 Enter Bug のページに移動してください。

  5. バグ報告の対象となる製品を選択します。

  6. 製品のバージョン、コンポーネント (この場合は AppArmor) 、ハードウエアプラットフォーム、重要度をそれぞれ指定します。

  7. 次に問題点の概要を Summary 欄に、詳細や再現手順などを Description 欄にそれぞれ入力します。ログファイルの内容などを貼り付けてもかまいません。また、スクリーンショットやログファイル、テストケースなどの添付を行うこともできます。

  8. 必要な項目を入力したら、 Submit を押すと、レポート内容が開発者に送信されます。

このページを印刷