AppArmor

提供: ArchWiki
ナビゲーションに移動 検索に移動

関連記事

AppArmor は強制アクセス制御 (MAC) のシステムです。Linux Security Modules (LSM) 上に実装されています。

他の LSM と同じように、AppArmor はデフォルトの任意アクセス制御 (DAC) を置き換えるというよりも補完するものです。そのため、プロセスに最初から持っている権限よりも高い権限を与えることはできません。

Ubuntu や SUSE などのディストリビューションはデフォルトで AppArmor を使用しています。RHEL (とその派生) は正しく機能させるのにユーザー空間における設定が必要になる SELinux を使っています。SELinux は全てのファイル・プロセス・オブジェクトにラベルを貼るため非常に柔軟性があります。しかしながら SELinux の設定は非常に複雑で、ファイルシステムが SELinux に対応していなければなりません。それに比べて AppArmor はファイルパスを使用するため簡単に設定することができます。

AppArmor は外部・内部からの脅威に対してオペレーティングシステムやアプリケーションを防護します。アプリケーションごとにルールセットを決めることでゼロデイ攻撃からも身を守ることができます。セキュリティポリシーによって個々のアプリケーションがアクセスできるシステムリソースは厳格に定められます。何もプロファイルが設定されていない場合、デフォルトでアクセスは拒否されます。AppArmor に付属しているデフォルトポリシーは少ない数しかありません。高度な静的解析・学習ツールを使用することで、非常に複雑なアプリケーションでも問題なく動作するような AppArmor ポリシーを数時間で作成できます。

ポリシー違反が発生するとシステムログにメッセージが残ります。また、AppArmor ではデスクトップにポップアップを表示することで、リアルタイムにユーザーに通知するように設定することもできます。

インストール

AppArmor は公式でサポートしているカーネルで利用できます。

AppArmor を制御するためのユーザースペースツールやライブラリは apparmor パッケージでインストールできます。起動時に全ての AppArmor プロファイルをロードするには、apparmor.service を有効化してください。

起動時にデフォルトのセキュリティモデルとして AppArmor を有効にするには、以下のカーネルパラメータを設定: 

lsm=landlock,lockdown,yama,apparmor,bpf
ノート: lsm= カーネル・パラメータは、Linux セキュリティ・モジュールの初期化順序を設定します。カーネルに設定された lsm= 値は zgrep CONFIG_LSM= /proc/config.gz で、現在の値は cat /sys/kernel/security/lsm です。
  • apparmor がリストの最初の "major" モジュールであることを確認してください。[1] 有効な値とその順序の例については、 security/Kconfig を参照してください。
  • capability は常に自動的に含まれるため、lsm= では省略する必要があります。

カスタムカーネル

カーネルをコンパイルするとき、以下のオプションを設定する必要があります: 

CONFIG_SECURITY_APPARMOR=y
CONFIG_AUDIT=y

AppArmor Linux セキュリティモデルをデフォルトで有効にし、カーネルパラメータで設定する必要を無くすには、さらに CONFIG_LSM オプションを設定し、リストの最初の "major" モジュールとして apparmor を指定します。 

CONFIG_LSM="landlock,lockdown,yama,apparmor,bpf"

使用方法

現在の状態を表示

AppArmor が有効になっているか確認するには: 

$ aa-enabled
Yes

ロードされている状態を表示するには apparmor_status を使用: 

# apparmor_status
apparmor module is loaded.
44 profiles are loaded.
44 profiles are in enforce mode.
 ...
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

プロファイルの解析

プロファイルをロード・アンロード・リロード・確認するには apparmor_parser を使います。デフォルトでは enforce モードで新しいプロファイルをロードするようになっており (-a)、-C スイッチを使うことで complain モードでロードできます。既存のプロファイルを上書きするには -r オプションを、プロファイルを削除するには -R を使います。各操作では複数のプロファイルを指定できます。詳しくは apparmor_parser(8) の man ページを参照してください。

ロードの無効化

全てのプロファイルをアンロードすることで現在のセッションで AppArmor が無効化されます: 

# aa-teardown

次の起動時に AppArmor プロファイルがロードされないようにしたい場合は apparmor.service を無効化してください。カーネルが AppArmor をロードしないようにするには、カーネルパラメータから apparmor=1 security=apparmor を削除します。

設定

監査とプロファイルの作成

新しいプロファイルを作成するには、 Audit フレームワーク を実行する必要があります。これは、Arch Linux がデフォルトで systemd を採用し、ファイルへの kernel logging を行わないためです。AppArmor は、ユーザー空間の auditd デーモンからカーネル監査ログを取得し、プロファイルを構築できます。

新しい AppArmor プロファイルは、aa-genprof(8) または aa-autodep(8) を使用して作成できます。プロファイルは最初に complain mode で作成されます。このモードでは、ポリシー違反は報告されるだけで、強制されません。ルールは、apparmor パッケージの aa-logprof(8) ツールによってインタラクティブに作成されます。最後に、aa-enforce(8) を使用して、プロファイルを enforce mode に設定する必要があります。このモードでは、対応するプロファイルのルールによって定義されたポリシーが適用されます。必要に応じて、aa-logprof(8) を繰り返し実行してルールを追加したり、aa-apprait(8) を使用してプロファイルを警告モードに戻すことができます。これらのツールの使用方法の詳細については、 AppArmor wiki-Profiling with tools を参照してください。

aa-logprof(8) には deny ルールも用意されていますが、これは基本的な AppArmor ロジックによれば、ルールによって明示的に許可されていないものはすべて禁止されているため、厳密には必要ではありません。ただし、deny 規則には2つの目的があります。

  1. deny ルールは allow ルールよりも優先されます。重要なフォルダやファイルへのアクセスをブロックするために、/etc/apparmor.d/abstractions にある多くの abstractions でよく使用されます。これにより、誤って作成された許可ルールによってプロファイルが過度に許可されることがなくなります。
  2. allow ルールは、logging を無効にし、以降の aa-logprof の実行ノイズを減らします。deny ルールは complain mode でも適用されることを覚えておくことが重要です。 アプリケーションが苦情モードでも適切に動作しない場合、プロファイルまたは拒否ルールをチェックしてください。

また、手動でプロファイルを作成することもできます。詳細については、 AppArmor wiki-Profiling by hand を参照してください。

プロファイルの構文

プロファイルは人間が読める形式のテキストファイルとなっており /etc/apparmor.d/ に保存されます。バイナリを実行時にどう扱うかを記述します。基本的なプロファイルは以下のようになります: 

/etc/apparmor.d/usr.bin.test
#include <tunables/global>

profile test /usr/lib/test/test_binary {
    #include <abstractions/base>

    # Main libraries and plugins
    /usr/share/TEST/** r,
    /usr/lib/TEST/** rm,

    # Configuration files and logs
    @{HOME}/.config/ r,
    @{HOME}/.config/TEST/** rw,
}

@ 記号が前に付くテキストは abstraction (/etc/apparmor.d/abstractions/) や tunable (/etc/apparmor.d/tunables/) あるいはプロファイルによって定義される変数を表します。#include は他のプロファイルふを直接読み込みます。後ろに文字がいくつか付いているパスは アクセス権限 です。AppArmor の globbing 構文 を使用したパターンマッチングが行われます。

ほとんどのユースケースは以下のステートメントで表すことができます:

  • r — read: データの読み込み。
  • w — write: ファイルの作成・削除・編集と拡張。
  • m — memory map executable: ファイルを実行可能とメモリマップ。
  • x — execute: ファイルを実行。修飾子 を付ける必要があります。

上記の権限は任意アクセス制御 (DAC) によって与えられる権限を上回ることはできません。

詳しいガイドは apparmor.d(5) の man ページや ドキュメント を見てください。

ヒントとテクニック

DENIED アクション時にデスクトップ通知を表示

通知デーモンは AppArmor によってプログラムのアクセスが拒否されたときにデスクトップ通知を表示します。aa-notify デーモンをログイン時に自動的に起動するには以下の手順に従ってください。

Audit フレームワークをインストール・有効化してください。audit ユーザーグループにユーザーを追加することで /var/log/audit の監査ログを読み込めるようにします: 

# groupadd -r audit
# gpasswd -a <username> audit

audit グループを auditd.conf に追加: 

/etc/audit/auditd.conf
log_group = audit
ヒント: wheel や adm など既存のシステムグループを使用することもできます。

python-notify2 と python-psutil を インストール します。

以下のコンテンツで デスクトップランチャー を作成します。 

~/.config/autostart/apparmor-notify.desktop
[Desktop Entry]
Type=Application
Name=AppArmor Notify
Comment=Receive on screen notifications of AppArmor denials
TryExec=/usr/bin/aa-notify
Exec=/usr/bin/aa-notify -p -s 1 -w 60 -f /var/log/audit/audit.log
StartupNotify=false
NoDisplay=true

再起動して aa-notify デーモンが稼働しているか確認: 

$ pgrep -ax aa-notify
ノート: システムの設定によっては多数の通知が表示されます。

詳しくは aa-notify(8) を参照。

プロファイルをキャッシュして AppArmor の起動を高速化

AppArmor は設定されたプロファイルをバイナリ形式に翻訳する必要があるため、プロファイルのロードにはしばらく時間がかかります。煩わしいことに起動時間がかなり伸びてしまいます。AppArmor の起動時間は以下のコマンドで確認できます: 

$ systemd-analyze blame | grep apparmor

AppArmor プロファイルのキャッシュを有効化するには、以下をアンコメント: 

/etc/apparmor/parser.conf
## Turn creating/updating of the cache on by default
write-cache

デフォルトのキャッシュ場所を変更するには以下を追加: 

/etc/apparmor/parser.conf
cache-loc=/path/to/location
ノート: 2.13.1 からデフォルトのキャッシュ保存場所は /var/cache/apparmor/ となっています。以前は /etc/apparmor.d/cache.d/ でした。

再起動して AppArmor の起動時間が変化したか確認してください: 

$ systemd-analyze blame | grep apparmor

トラブルシューティング

Samba SMB/CIFS サーバーを起動できない

Samba#AppArmor におけるパーミッションの問題 を参照

aa-logprof でイベントが捕捉されない

Audit フレームワーク のログに特殊文字 0x1d [2] が含まれる場合があります。AppArmor バグレポート がありますが、回避策として次を実行します。 

# aa-logprof -f <(sed 's/\x1d.*//' < /var/log/audit/audit.log)

参照

「https://wiki.archlinux.jp/index.php?title=AppArmor&oldid=31998」から取得