web-dev-qa-db-ja.com

「ティアダウン」を使用したAppArmorのトラブルシューティングは安全ではありませんか？

サービスを完全に停止してAppArmorプロファイルを破棄するよりも、問題に対するAppArmorの貢献の可能性をトラブルシューティングする、より安全でターゲットを絞った方法があることを理解しています。誰かが詳細と、より良いアプローチの利点を教えてもらえますか？

securityapparmor
6
belacqua

ここに私が考えていたものがあります（from https://wiki.ubuntu.com/DebuggingApparmor ）-"complain mode"。これは、他のデバッグ方法と比較した場合の相対的なメリットまたは結果の問題に対処していません。

デバッグするときは、apparmorを「苦情」モードにすることも役立ちます。これにより、apparmorがプロファイルにないアクセスを報告する間、アプリケーションは正常に機能します。 「苦情」モードを有効にするには、次を使用します。

Sudo aa-complain /path/to/bin

「/ path/to/bin」は、「audit」エントリの「profile = ...」の部分で報告されているバイナリへの絶対パスです。例えば：

Sudo aa-complain /usr/sbin/slapd

強制モードを再度有効にするには、代わりに「aa-enforce」を使用します。

Sudo aa-enforce /path/to/bin

プロファイルを無効にするには：

Sudo touch /etc/apparmor.d/disable/path.to.bin
Sudo apparmor_parser -R /etc/apparmor.d/path.to.bin

トラブルシューティングを行うときに、不気味なアクセス許可の問題に関連していると思われる壊れたものがある場合（「うーん、アクセス制御のように見えますが、Unixのアクセス許可の問題、NFSの問題、PAMの問題、またはメディアマウントグーフではありませんなど、おそらくAppArmorです。 '）、Kees Cookが、システムログを確認するのが最善策だと指摘しています。特に、Kees Cookによれば、「dmesgの出力はすべてのAppArmor拒否を報告し、プロファイルを含みます。」

6
belacqua