LSMの実装に関する入門書を読んでいるので、最終的AppArmorにはSELinux。
わかりましたこの議論しかし、これは2つのLSMの実装に関する質問を明確に説明しません。
これは本当ですか？
- SELinuxはシステム全体に適用する必要があります（したがって、
auto-relabeling最初の起動プロセスはファイルシステムの検索と同じくらい時間がかかります）。 - AppArmorは、必要なプロセス/スクリプトに対してのみポリシーを定義できる柔軟性を提供します。 - インタラクティブレビュープロセスを通じて）
(?)
ベストアンサー1
他の質問に答えたように、AppArmorとSELinuxの主な違いはラベルです。 AppArmorはパスベースですが、SELinuxは各オブジェクトに追加のタグを追加します。これが、デフォルトのファイルラベルを適用するために最初に起動したときに自動ラベルのリダイレクトが発生する理由です。それ以外の場合は、すべてのファイルが同じように処理されるため（同じラベルを持つため）、ファイルアクセスの意味のあるポリシーを作成することはできません。
AppArmorとSELinuxはどちらも無制限のドメインを持ち、プロセスを制限しません。どちらのシステムにも、ポリシー違反のみを記録し、ポリシーを強制しない苦情モード（SELinuxでは特権ドメインと呼ばれる）もあります。 AppArmor と SELinux はどちらもシステム全体でアクティブになり、両方のシステムのセキュリティモジュールによって制限されないプロセスを実行できます。
自動ポリシー作成の観点から、両方のシステムには同様のツールとメカニズムがあります。
AppArmor 構成ファイルは、以下を使用して生成できます。aa-genprofそしてaa-logprof。aa-genprofデフォルトプロファイルを作成し、苦情モードに設定します。プログラムを実行した後、ログファイルからルールを生成できます。
SELinuxツールにはpolicygentoolそしてaudit2allow。主な違いはまだファイルタグですが、policygentoolプログラムデータ（var）、設定ファイル、およびログファイルのファイル形式は自動的に生成されることがあります。その後、ポリシーを許可モードでロードし、ログからルールを作成できますaudit2allow。