SUSE SLES 15でカスタムアプリケーション用のAppArmorプロファイルを設定する方法

バージョンに関する注記（2026年10月6日確認）：この手順は、AppArmorを使用するSUSE Linux Enterprise Server（SLES）15 SP7および互換性のあるSLE 15システムに適用されます。SUSEは、SLES 15 SP7にAppArmorがデフォルトでインストールされ、実行されていることを文書化しています。SUSE Linux 16.0ではAppArmorが削除され、代わりにSELinuxが使用されるため、以下のコマンドをバージョン16.0に適用しないでください。SUSEのSUSE Linux 16.0比較ガイドおよび当該リリースのSELinuxドキュメントを参照してください。

AppArmorは、プログラムがアクセスできる範囲を制限するLinuxセキュリティモジュールです。プロファイルとは、実行ファイルに適用されるポリシーであり、ファイル、機能、その他のリソースへのアクセスを許可または拒否することができます。このガイドでは、プラットフォームの確認からテスト済みのプロファイルの適用までを、慎重な学習フェーズを経て解説します。これにより、カスタムアプリケーションが予期せず動作しなくなる可能性を低減します。

プロフィールを作成する前に、どのような準備をしておくべきですか？

アプリケーションが重要な場合は、テストまたはメンテナンス期間を使用してください。管理者アカウントsudo、アプリケーションの実際の実行可能パス、およびアプリケーションが実行する通常のタスクの一覧が必要です。バックグラウンド処理、起動とシャットダウン、構成の再読み込み、アップロードまたはエクスポート、スケジュールされたジョブ、およびネットワーク接続機能を含めてください。1回の起動から学習したプロファイルでは、使用しない機能を推測することはできません。

アプリケーションがデータの読み書きを行う場所、実行アカウント、およびヘルパープロセスを開始するかどうかを把握してください。可能な限り、機密性の高い本番データに対するテストは避けてください。変更を加える前に、現在のサービスの状態を記録し、既存のプロファイルのコピーを保存してください。

このSUSEリリースでAppArmorが利用可能かどうかを確認するにはどうすればよいですか？

まず、オペレーティングシステムのリリースバージョンと現在のAppArmorの状態を確認してください。

cat /etc/os-release
sudo aa-status

システムが SLES 15 SP7 または AppArmor をサポートするドキュメントを持つ別のリリースを報告していることを確認してください。SLES 15 SP7 では、SUSE ガイドによると AppArmor はデフォルトでインストールされ、実行されています。インストールされていない場合は、SUSE は を使用したインストール方法をドキュメントにsudo zypper in -t pattern apparmor記載しています。サービスがインストールされているが実行されていない場合は、有効にする前にシステムの起動ポリシーとサービスの状態を確認してください。アプリケーションの問題を回避するためにセキュリティ モジュールを無効にしないでください。リリース固有の詳細については、 SLES 15 SP7 AppArmor 入門ガイドおよびSLES 15 SP7 AppArmor コマンドライン ツール ガイドを参照してください。

AppArmorがプロファイルする実行ファイルをどのように特定しますか？

AppArmorプロファイルはプログラムパスに関連付けられているため、ユーザーが入力したコマンドがバイナリであると想定するのではなく、実際の実行可能ファイルを特定してください。シェルパスからアクセスできるコマンドの場合は、以下を実行します。

command -v myapp

サービスについては、システムで利用可能なツールを使用して、そのユニット定義とプロセスの詳細を確認してください。ランチャースクリプト、シンボリックリンク、またはインタープリタによって、想定とは異なる実行可能ファイルが生成される場合があります。readlink -f /path/to/myapp適切な箇所で、既知のパスを解決してください。以下のすべてのコマンドで、検証済みの絶対パスを置き換えてください。/usr/local/bin/myappは単なる例です。

プロファイリングを行う前に、 の下にプロファイルが既に存在するかどうかを確認してください/etc/apparmor.d。SUSE はプロファイルをそこに保存し、ファイル名は通常、実行可能パスのスラッシュをドットに置き換えます。たとえば、/usr/local/bin/myappは のようなファイル名にマッピングされますusr.local.bin.myapp。既存のベンダープロファイルまたはローカルで管理されているプロファイルを、確認せずに上書きしないでください。SUSE は の下に追加のプロファイルもリストしています/usr/share/apparmor/extra-profiles。適切なプロファイルが開始点となる可能性がありますが、アプリケーションとリリースに合わせて確認する必要があります ( SUSE プロファイル リポジトリのドキュメント)。

安全に初期プロファイルを作成するにはどうすればよいですか？

プロファイル生成ツールを管理者として実行し、実行可能ファイルの完全なパスを指定してください。

sudo aa-genprof /usr/local/bin/myapp

aa-genprof起動プロファイルを作成し、実行中はプログラムをコンプリーモードにします。コンプリーモードではポリシー違反が記録されますが、拒否された操作はブロックされないため、強制適用前に動作を確認できます。ツールの指示に従ってください。アプリケーションの実行後、スキャンオプションを使用してログに記録されたイベントを確認してください。SUSE はこれを反復プロセスと説明しており、自動的に提案されたプロファイルが完全であることを保証するものではありません。

どのようなアクションをテストすべきか、また、拒否はどこで確認できるのか？

プロファイルが苦情モードになっている間は、通常のオペレーターと同じようにアプリケーションを使用してください。読み取り、書き込み、アップロード、レポート生成、サービス再起動、ヘルパージョブなど、通常のワークフローと、頻度は低いもののサポートされているタスクをテストしてください。テストは現実的なものにしてください。プログラムは、エクスポート時とホーム画面時で異なるファイルや子プロセスを使用する場合があります。

AppArmorイベントに関するカーネルメッセージと監査ログを確認してください。

sudo journalctl -k | grep -i apparmor

システムのログ設定によっては、SUSE は/var/log/audit/audit.log、journalctl | grep -i apparmor、 も参照しますdmesg -T。いずれかのログ ビューで一致が見つからなくても、プロファイルが正しいとは限りません。アプリケーションが実行されたことを確認し、ログ サービスやその他の文書化されたログの場所を確認してください。アプリケーションが一度起動したというだけで、生成されたプロファイルがテスト済みであるとみなさないでください。

プロフィールの見直しと改善はどのように行うべきでしょうか？

root権限で、aa-logprofログに記録されたイベントを処理し、プロンプトに応答するには、以下を使用します。

sudo aa-logprof

各イベントについて、そのアクセスが文書化されたアプリケーションタスクに必要かどうかを判断してください。プログラムが必要とする狭いパス、アクセスモード、または機能のみを許可してください。設定ファイルの読み取りは想定内の動作ですが、無関係なディレクトリへの予期せぬ書き込みは、エラーまたは調査が必要な別のコンポーネントの存在を示している可能性があります。ルールが広すぎると制限が弱まり、狭すぎると有効なタスクが中断される可能性があります。

• すべてのプロンプトを自動的に承認したり、すべてのファイルに一律のアクセス権を追加したりしないでください。
• 広範囲なワイルドカードや不要な機能は避け、明確なパスと必要最小限の権限を優先してください。
• プロファイル編集後、ワークロードとログレビューのサイクルを繰り返してください。サービス操作とバックグラウンドタスクは個別に処理してください。
• 変更は対象アプリケーションに限定し、ノイズを抑えるために無関係なプロファイル編集を行わないでください。

プロファイルはアクセス制御の境界であるため、プロンプトはログに表示されたという理由だけでなく、アプリケーションの動作と運用要件に基づいて回答する必要があります。SUSE SLES 15 SP7 AppArmor コマンドラインツールガイドでは、コマンドラインツールについて説明しており、SUSE AppArmor サポートのリファレンスaa-genprofには、、、aa-logprofなどの関連する man ページへのリンクがありますapparmor_parser。

プロファイルを強制モードに切り替えるべきタイミングはいつですか？

代表ワークフローが成功し、正当なイベントを確認した後でのみ、ポリシーの適用を開始してください。アプリケーションプロファイルを1つ適用し、AppArmorのプロファイルセットを再読み込みして、アプリケーションまたはサービスを再起動し、実行中のプロセスが更新されたポリシーを使用するようにします。

sudo aa-enforce /usr/local/bin/myapp
sudo systemctl reload apparmor

SUSEは、リロードによってプロファイルが再読み込みされるため/etc/apparmor.d、既に実行中のプログラムは更新されたプロファイルが有効になる前に再起動が必要になる場合があると指摘しています。再起動についてはサービス所有者と調整し、アプリケーションに適したサービス管理コマンドを使用してください。その後、主要なワークフローは、苦情モードでの成功が変更なしで動作することを証明すると考えるのではなく、強制モードで再度実行してください。

結果の検証方法と、回帰バグからの復旧方法を教えてください。

テスト後、プロファイルの状態を確認し、新たな拒否がないか調べてください。

sudo aa-status
sudo journalctl -k | grep -i apparmor

目的のプロファイルがロードされ、強制モードになっていること、サービスが正常な状態を維持していること、および必要なタスクがすべて正常に動作していることを確認してください。強制によって正当な操作がブロックされた場合は、関連するイベントを収集し、アクセスが本当に必要かどうかを確認し、プロファイルをより厳密に絞り込んでください。短時間で制御された診断を行うには、sudo aa-complain /usr/local/bin/myappそのプログラムのプロファイルを苦情モードにすることができます。調査、更新、再テストを行った後、強制モードに戻してaa-enforceください。必要に応じて、再ロードと再起動を行ってください。一時的な解決策として、AppArmor を全体的に無効にしたり、広範な権限を付与したりすることは避けてください。

避けるべきよくある間違いは何ですか？

• リリース手順が間違っています。ここでのワークフローはSLES 15 AppArmor用です。SUSEの比較ガイドによると、SUSE Linux 16.0では代わりにSELinuxが使用されます。
• 実際のプログラムではなくラッパーをプロファイリングする：特にサービスやスクリプトの場合、実際に実行される実行可能ファイルを検証する。
• 学習不足：テストされていない機能は観測されたアクセスを生成しないため、不完全なプロファイルは後で失敗する可能性があります。
• 文脈を無視した承認プロンプト：追加されるすべての権限は、必要なアプリケーションタスクに役立つものでなければなりません。
• 再起動を忘れた場合：プロファイルを再読み込みし、必要に応じて実行中のアプリケーションを再起動することで、プロセスがポリシーを採用します。
• ロールバックパスなしで編集する場合：ローカルで管理されているプロファイルをバックアップし、バージョン管理システムまたはシステムの構成管理プロセスで変更を追跡してください。

SUSE公式リファレンス

• SLES 15 SP7 AppArmor入門ガイド
• SLES 15 SP7 AppArmor コマンドラインツールガイド
• SUSEプロファイルリポジトリのドキュメント
• SUSE AppArmor サポートリファレンス
• SUSE Linux 16.0 比較ガイド

これらの情報は2026年10月6日に確認されました。コマンドやパッケージの詳細は製品リリースによって異なる場合があります。変更を加える前に、インストールされているSLESサービスパックのドキュメントを確認してください。