Ubuntu 26.04 講座 / AppArmor ログとプロファイルの確認

Ubuntu

AppArmorは、プログラムごとのプロファイルでファイル・実行・ネットワークなどの動作を制限する追加アクセス制御です。権限エラーを調査する際には、一般的なファイル権限と実際に適用されているプロファイル・拒否ログを併せて確認し、AppArmorを全面的に無効化することを最初の解決策としません。

一般権限とプロファイルの違い

ユーザーのUID・グループ・ファイルモードが許可していても、AppArmorが当該プログラムへのアクセスを遮断することがあります。逆に、AppArmorのログがなくても、ディレクトリ権限・読み取り専用マウント・サービスアカウントに問題がないとは限りません。実際に失敗したパスと実行アカウントを最初に記録します。

現在のプロファイルとモードを確認する

sudo aa-status
systemctl status apparmor --no-pager

プロファイルのenforceとcomplainは動作が異なります。enforceはポリシーを適用し、complainは学習・調査に利用できますが、保護範囲を減らす場合があります。サービスの状態だけで全てのプロセスが制限されていると判断せず、aa-statusで実際にプロファイルと関連するプロセスを確認します。

Ubuntuのセキュリティドキュメントは、AppArmorのポリシー適用とプロファイルモード・権限範囲について説明しています。

失敗直後のログとリクエストを照合する

sudo journalctl -k -b --since '10 minutes ago' --no-pager | grep 'apparmor="DENIED"'

失敗を一度再現した時間を記録し、profile・operation・name・pid・requested_mask・denied_maskを照合します。ログの例を実際のデバイスの結果のように装わず、現在の出力で該当プログラムとリクエストが一致するか確認します。内部パスやユーザー情報が含まれる場合があるため、共有する際は必要な部分だけ残します。

出力がない場合は、現在のブート・時間範囲・ログ収集パスおよび実際のプロファイルを再確認します。明示的なdenyルールなどは期待した方式でログに出ない場合があるため、ログがないことをポリシー許可の証拠とは見なしません。

拒否記録のフィールドを例として読む

次の一行はフィールド説明のために作った仮想例であり、特定のUbuntu端末で収集した結果ではありません。profileは制限されたプログラムポリシー、operationは試みた動作、nameは対象パスであり、requested_maskとdenied_maskのrは読み取り要求および拒否を示します。

apparmor="DENIED" operation="open" profile="/usr/sbin/example-app" name="/srv/example-data/settings.ini" requested_mask="r" denied_mask="r"

実際の調査では、失敗時刻・プロセス・実行アカウント・パスをログと照合します。例示されたパスに読み取り権限を追加する指示ではありません。誤ったアプリデータの場所を元のサポートされている位置に戻すことが適切な場合もあり、ログにあるすべての要求を許可するわけではありません。

プロファイルと設定の管理主体を探す

一般的なプロファイルは/etc/apparmor.dで該当する名前と実行パスを探します。Snapのようにポリシーが生成されるアプリは、生成されたファイルを直接編集するよりもSnapインターフェースおよびプロバイダー設定を確認します。ファイル名を推定して新しいプロファイルを作成したり、他のプログラムのポリシーをコピーしたりしません。

パス変更が原因である場合、まずアプリがサポートするデータ位置に戻す方法を検討します。ポリシー修正が必要であれば、実際に要求される動作・正確なファイルパス・読み取り/書き込みの範囲を設定し、元のファイルと含まれるローカル設定をバックアップします。広範なワイルドカードでディスク全体を許可しません。

カーネルポリシーを変更せずにプロファイルを検査する

一般プロファイルの実際のファイルを1つ確認し、下のプロンプトに入力します。Snapが自動生成したポリシーはこの編集実習の対象から除外します。-Q はカーネルのロードをスキップし、-K はキャッシュの使用・記録を行わないようにします。検査に合格しても、アプリの実際のアクセス許可・拒否の試験が終わったわけではありません。

(
set -eu
read -r -p 'Actual ordinary profile path under /etc/apparmor.d/: ' profile
case "$profile" in
    /etc/apparmor.d/*) ;;
    *) printf 'Choose the verified profile source.\n' >&2; exit 1 ;;
esac
sudo test -f "$profile"
sudo apparmor_parser -Q -K "$profile"
)

実際のポリシーを狭く修正する必要がある場合は、元のファイルと local を含むファイルをまずバックアップし、上記の検査に合格した後に sudo apparmor_parser -r 実際のプロファイルファイルでそのプロファイルを再読み込みします。失敗した場合は同じファイルのバックアップのみを復元して検査・再適用し、aa-status と元の enforce 状態を確認します。この記事で状態の調査だけを行う場合、reload コマンドは実行しません。

AppArmor 5.0公式マニュアルで検査・キャッシュ・カーネル再適用の違いを確認してください。

狭い変更と検証・復元基準

変更したプロファイルは公式ツールで構文を確認し、該当プロファイルのみを再読み込みした後、許可すべき動作と引き続きブロックすべき動作をそれぞれ試験します。診断ツールが提案した許可ルールも、ログのすべてのリクエストを無条件で承認せず、必要性を検討します。

失敗した場合は、今回のポリシー変更だけを元に戻し、元の enforce 状態とアプリの動作を再確認します。全体の AppArmor サービスやユーザーネームスペース保護を無効にするコマンドで結果を合わせることはありません。完了記録には、原因・ポリシーのパス・変更範囲・許可および拒否のテスト・復元方法を残します。

Ubuntu