SUSE LinuxでカスタムAppArmorプロファイルを作成する

SUSEは2025年11月4日にSLES 16.0を発表し、デフォルトの必須アクセス制御フレームワークとしてAppArmorに代わってSELinuxを採用しました。サーバーがSLES 16を実行している場合、AppArmorがインストール済みまたはアクティブになっているとは限りません。これらのコマンドを使用する前に、そのデプロイメントでサポートされているフレームワークを確認してください。以下の手順は、AppArmorがデフォルトでインストールされ実行されているSUSEのSLES 15 SP7 AppArmorドキュメントに基づいています。

SLES 15 SP7 では、カスタム アプリケーションを作成する際の実際的な手順は、まずaa-genprof開始プロファイルを作成し、アプリケーションをコンプライム モードで実行し、ログに記録された各リクエストを確認してから、プロファイルが正しく適用されていることを確認することです。この例では、架空の実行可能ファイルを使用しています。/usr/local/bin/report-worker実際のアプリケーションの実行可能ファイルのパスに置き換えてください。

始める前に

AppArmor プロファイルは、. に格納されるテキスト ポリシーです/etc/apparmor.d。このapparmor-utilsパッケージはプロファイリング ツールを提供します。ホストをチェックし、実際の実行可能ファイルを特定します。これには、systemd ユニットがラッパーまたは子プロセスを起動するかどうかも含まれます。

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

SUSE では、SLES 15 のインストール時に AppArmor がデフォルトで有効になっていると記載されています。ツールまたは完全な AppArmor パターンが見つからない場合は、パターンをインストールしてくださいsudo zypper in -t pattern apparmor。AppArmor がアクティブでない場合は、プロファイル ファイルだけで保護が提供されると想定するのではなく、プロファイリングを行う前にその理由を解決してください。プロファイルは実行可能ファイルのパスに添付されます。実際のワークロードが別のバイナリとして実行されている場合にラッパーをプロファイリングすると、重要なプロセスが制限されない可能性があります。

プロフィールの作成と改善

1. ジェネレーターを起動します。アプリケーションが既に実行中の場合は停止してから、プロファイル生成を開始します。

   sudo systemctl stop report-worker
   sudo aa-genprof /usr/local/bin/report-worker

   

   サービス名は例です。実際のユニット名を使用するか、プログラムが実行されていない場合は停止コマンドを省略してください。プロファイルがaa-genprof存在しない場合は近似プロファイルを作成し、それを苦情（学習）モードにして再読み込みし、ログにマークを付けます。苦情モードでは、ポリシー外の要求が記録されますが、それらは許可されます。これは一時的な学習状態であり、強制ではありません。

2. 実際のアプリケーションの動作を検証してください。ジェネレーターは開いたままにしてください。別のターミナルでサービスを開始し、代表的なジョブまたは機能を実行してください。

   sudo systemctl start report-worker
   sudo journalctl -f

   

   通常の起動、想定される入出力パス、スケジュールされたタスク、エラー処理、およびアプリケーションが起動するヘルパープログラムをすべて網羅してください。プロファイルは、テスト中に生成されたリクエストのみを学習できます。イベントを生成するためだけに、本番環境に影響を与えるワークロードを使用しないでください。安全なテスト環境と代表的なテストデータを使用することが望ましいです。

3. アクセス要求を一つずつ確認してください。戻ってキーをaa-genprof押すと、Sマークされたログ範囲がスキャンされます。プロンプトが表示されるたびに、アプリケーションがそのファイル、機能、または子プログラムの遷移を本当に必要としているかどうかを判断してください。最も狭義の有用なパスと権限のみを許可してください。抽象化が一般的なタスクを正確にカバーしている場合は、抽象化を受け入れてください。一致するファイルが同じ信頼とアクセス要件を共有している場合にのみ、グロブを使用してください。偶発的または説明のつかない要求は拒否またはスキップしてください。

   

   実行要求には特に注意してください。制約のない遷移は、子プロセスが親プロセスのポリシーから逸脱する可能性があるため、正当な設計上の必要性がある場合にのみ使用してください。正当なルールを追加した後、演習とスキャンサイクルを繰り返してください。プロファイルがテスト対象の動作を網羅したら、ジェネレーターを終了してください。SUSE は、新しいaa-genprof学習サイクルを完了すると、通常プロファイルが強制モードになると述べています。

4. 生成されたポリシーを検査してください。この例のパスでは、SUSE の命名規則により、実行可能パス内のスラッシュがピリオドに変換され、 が生成されます/etc/apparmor.d/usr.local.bin.report-worker。生成されたルールを自動的に安全とみなすのではなく、結果を確認してください。

   sudo less /etc/apparmor.d/usr.local.bin.report-worker

   

   プロファイルが意図した実行可能ファイルの名前を指定し、必要なインクルードを使用し、アプリケーションが実際に必要とする構成、データ、ログ、ソケット、およびヘルパープログラムのみにアクセスを許可していることを確認してください。/拒否を黙らせるためだけに、無制限のアクセスや書き込み可能なツリー全体など、広範なルールは避けてください。アプリケーションは依然として通常のUnixの所有権とパーミッションに依存しており、AppArmorは別の制限レイヤーを追加します。

5. 目的のモードを明示的に設定してください。確認後、カスタムプログラムにプロファイルを適用してください。

   sudo aa-enforce /usr/local/bin/report-worker

   

   ジェネレーターの終了後にプロファイルを手動で編集した場合は、プロファイルセットを再読み込みしてくださいsudo systemctl reload apparmor。SUSE ドキュメントは、実行中のプロセスを制限解除せずにプロファイルを再スキャンして再読み込みします。アプリケーションサービスを再起動して、新しいポリシーがそのプロセスに適用されるようにしてください。

執行中のアプリケーションを確認する

プロファイルが強制モードの状態で、同じ代表的なタスクを再度実行します。サービスが起動し、意図した入力を読み取り、期待される出力を書き込み、必要なヘルパー操作またはネットワーク操作を実行できることを確認します。次に、プロファイルの状態と最近のカーネルメッセージの両方を調べます。

sudo aa-status
sudo journalctl -k -g apparmor --since today

カスタム実行ファイルは、ロード済みで強制モードになっているはずです。カーネルジャーナルの AppArmor 拒否ログは、ポリシーによってブロックされたリクエストを示します。これらは、実際のアプリケーション障害を診断するために使用し、ログに記録されたすべてのパスを許可する理由として使用しないでください。正当な権限不足の場合は、 を実行しsudo aa-logprof、提案内容を確認し、ルールを厳密に更新し、手動で編集した場合は再ロードし、影響を受けるアプリケーションパスを再実行してください。

再起動後もプロファイリングを継続したり、より長期間の監視が必要な、継続的に実行されるサービスの場合、SUSE はaa-autodep、、、aa-complainおよび繰り返しaa-logprofスキャンを使用した別のシステムワークフローを文書化しています。学習実行をテスト全体にわたって開いたままにできる場合は、スタンドアロンaa-genprof方式の方が簡単です。どちらのワークフローも、実行されていないアプリケーションの動作を推測することはできないため、ソフトウェアや構成が変更された場合は、プロファイルを継続的に確認してください。

ソース

• SUSE：SUSE Linux Enterprise Server 16.0の新機能
• SUSE SLES 15 SP7: AppArmor の利用開始
• SUSE SLES 15 SP7: コマンドラインからプロファイルを作成する
• SUSE SLES 15 SP7: プロファイルコンポーネントと構文