【2026年】Linux AppArmor vs SELinux 設定ガイド｜強制アクセス制御の選択

はじめに：2026 年の Linux セキュリティ環境における強制アクセス制御の重要性

現代の IT インフラストラクチャにおいて、Linux サーバーは Web サービス、データベース、クラウド基盤の中核を担っており、そのセキュリティリスクも年々複雑化しています。特に 2025 年から 2026 年にかけて、AI システムとの連携や IoT デバイスからのデータ処理が増加したことで、従来のユーザーベースの権限管理（DAC）だけでは不十分なケースが目立ってきています。例えば、Web サーバーのプロセスが何らかの脆弱性を突かれて外部から乗っ取られた際、ファイルシステム内の機密データや他のサービスへのアクセスまで制限されないような設定では、被害が甚大になります。このような脅威に対抗するために必須となるのが「強制アクセス制御（MAC：Mandatory Access Control）」です。

この MAC を実現する主要なメカニズムとして、Linux カーネル上で動作する AppArmor と SELinux が存在します。両者は目的とする機能は同じですが、アプローチや設定方法、そして採用されているディストリビューションにおいて大きな違いがあります。本記事では、2026 年時点の最新情報を元に、Ubuntu 24.04 LTS、Fedora 41、RHEL 9、openSUSE Tumbleweed、Debian 12 といった主要な Linux ディストリビューションにおける AppArmor と SELinux の違いを徹底的に比較解説します。

読者対象は Linux システム管理者やセキュリティエンジニアですが、初心者でも理解できるよう専門用語には初出時に簡潔な注釈を付与しています。具体的には、強制アクセス制御の基本概念から始まり、各システムのプロファイル構造、設定コマンド、トラブルシューティング手順までを網羅します。特に Docker や Podman といったコンテナ環境における実装の違いや、セキュリティポリシーの自動生成ツールの使い方についても詳細に言及します。最終的に、貴社の運用環境に最適な強制アクセス制御を選択し、堅牢なセキュリティ基盤を構築するための指針を提供することを目的としています。

MAC（強制アクセス制御）の基礎知識と DAC との決定的違い

まず、なぜ Linux 上で強制アクセス制御（MAC）が必要なのかという根本的な疑問から解き明かす必要があります。Linux の基本となる権限管理モデルは「DAC：Discretionary Access Control（任意アクセス制御）」と呼ばれるものです。これは、ファイルに付与されている所有者（User）、グループ（Group）、およびパーミッション（rwx）に基づいてアクセスを判断する仕組みです。例えば、root ユーザーが作成したファイルに対して、他のユーザーが読み書きできるかどうかは、root ユーザー自身が設定することで決定されます。

しかし、DAC には重大な欠陥があります。それは、「信頼されたプロセス」や「特権を持ったユーザー」が誤って設定を変更したり、悪意のある攻撃者が特権を奪取したりした場合、セキュリティ境界が簡単に突破されるという点です。2026 年現在の脅威環境では、脆弱性を突いてシステム特権を得ることは珍しくありません。そのため、DAC の上層に「MAC：Mandatory Access Control（強制アクセス制御）」という絶対的なルールを敷くことが標準的なセキュリティベストプラクティスとなっています。

MAC は、ユーザーやプロセスの属性に基づいてアクセスを強制的に制御します。ここで重要になるのが、AppArmor と SELinux の設計思想の違いです。AppArmor は「パスベース」のアプローチを採用しており、「このファイルへのアクセスは許可する」というルールを書きます。一方、SELinux は「ラベルベース（タイプベース）」のアプローチで、「このタイプのファイルにはこのプロセスがアクセスできる」というルールを設定します。

この二つのアプローチの違いは、システム管理者にとっての学習コストと柔軟性に直結します。

• パスベース (AppArmor): 具体的なファイルパス（例：/etc/passwd）を指定するため、設定が直感的で理解しやすいです。ただし、OS のアップデートやディストリビューションごとのファイル配置の違いにより、ポリシーの移植性が低くなる傾向があります。
• ラベルベース (SELinux): ファイルの内容や用途（例：httpd_config_t）を指定するため、特定のファイルパスに依存しません。そのため、他のディストリビューションへ移行しても設定が生き残る可能性が高く、柔軟性が高い反面、概念の理解に深い知識が必要です。

また、最小権限の原則を MAC で実現する際にも違いが生じます。DAC では「root ユーザーなら何でもできる」という前提があるため、プロセスが root として実行された場合、制限されません。MAC を適用することで、「Nginx プロセスは root として動いているが、Web コンテンツの読み出しのみ許可し、システムファイルへの書き込みは禁止する」といった制御が可能になります。

2026 年時点での主要な Linux ディストリビューションにおけるデフォルト設定の違いを下表にまとめました。この表を見ると、どのディストリビューションがどの MAC システムを採用しているかが一目でわかります。Ubuntu や Debian は AppArmor を採用しており、Fedora や RHEL では SELinux が標準です。

このように、利用している OS の種類によってデフォルトのセキュリティモデルが異なります。したがって、サーバーを構築する前に、まず自身が管理する環境で MAC システムが有効になっているか確認し、適切なツールを使用してポリシーを管理する必要があります。後述する各セクションでは、それぞれのシステムに特化した設定方法を詳しく解説します。

AppArmor の詳細な設定方法とプロファイル管理

AppArmor は、Ubuntu や Debian、openSUSE などのディストリビューションで標準採用されている MAC システムです。その最大の特徴は、ファイルシステムのパス（経路）に基づいてアクセス制御を行う点にあります。2026 年時点の Ubuntu 24.04 LTS では、システムインストール時に自動的に AppArmor が有効化されており、多くの基本サービスがデフォルトのプロファイルで保護されています。

AppArmor の設定管理の中心となるのは「プロファイル」と呼ばれるテキストファイルです。これらのファイルは通常 /etc/apparmor.d/ ディレクトリに保存されます。各プロファイルは、特定のアプリケーション（バイナリ）に対して適用されるルールセットを定義します。例えば、Nginx ウェブサーバーのプロファイル名は usr.sbin.nginx となりますが、これはインストールパスに基づいています。

AppArmor は主に三つのモードで動作します。それぞれのモードには明確な役割と使用シチュエーションがあります。

1. Enforce Mode（強制モード）: プロファイルに定義されたルールを厳格に適用し、違反したアクセスをブロックするとともにログを記録します。これが本番環境での推奨設定です。
2. Complain Mode（報告モード）: ルール違反が発生しても動作は継続され、エラーとしてログだけが残ります。新しいアプリケーションのポリシー作成や既存プロファイルの修正時に使用し、問題がないことを確認してから強制モードへ移行します。
3. Disabled Mode（無効化モード）: その特定のプロファイルを完全に無効化します。セキュリティリスクが高まるため、トラブルシューティング時などの一時的な回避策としてのみ使用すべきです。

これらのモードを切り替えるには、aa-enforce、aa-complain、aa-disable コマンドを使用します。例えば、Nginx のプロファイルを報告モードにする場合は sudo aa-complain /etc/apparmor.d/usr.sbin.nginx と入力します。また、現在のステータスを確認するには sudo aa-status コマンドが便利です。これにより、どのサービスが強制モードで保護されているか、違反が発生しているかがリスト表示されます。

カスタムプロファイルを作成する際は、対話形式でルールを生成できる aa-logprof ツールが非常に有用です。このツールは、システムログにある AVC（Access Vector Cache）の拒否メッセージを読み取り、ユーザーに許可・拒否を尋ねながら自動的にプロファイルを作成します。ただし、2026 年現在でも自動生成されたルールには過剰な権限が含まれるリスクがあるため、最終的な確認は必ず手動で行うことが推奨されます。

また、AppArmor の設定ファイルを編集する際は、構文エラーに注意する必要があります。例えば、パスの指定においてはワイルドカードを使用できますが、その使用方法によってセキュリティ強度が変わります。

• /usr/bin/example: この特定のファイルのみ許可します。
• /usr/bin/example p: 読み取りと実行を許可します（p は permission）。
• **/**: すべてのパスを許可します（これはセキュリティ上推奨されません）。
• /var/www/** rwix: web ディレクトリ内のすべてのファイルに読み書き実行権限を与えます。

このような細かなパーミッション指定が、AppArmor の柔軟性を高めています。設定変更後は sudo apparmor_parser -r /etc/apparmor.d/<プロファイル名> コマンドで即座に反映させることが可能です。また、aa-logprof を使用してインタラクティブな編集を行う際にも、ログを確認しながら慎重に判断を行う必要があります。

SELinux のポリシー構造と設定コマンドの運用

SELinux（Security-Enhanced Linux）は、Fedora や RHEL（Red Hat Enterprise Linux）などのディストリビューションで標準採用されている MAC システムです。AppArmor がパスベースであるのに対し、SELinux は「ラベル」または「コンテキスト」に基づいてアクセス制御を行います。このため、同じファイルシステムに置かれていても、そのファイルの種類や用途によって異なるルールが適用されます。

SELinux の設定管理において最も重要なのが「コンテキスト」です。SELinux では、すべてのファイルとプロセスに独自のラベル（例：user:role:type:level）が付与されています。典型的な例として、Web サーバーのドキュメントルート /var/www/html/index.html は httpd_sys_content_t というタイプが割り当てられています。一方、Nginx プロセス自体は httpd_t タイプとして実行されます。SELinux ポリシーでは、「httpd_t プロセスは httpd_sys_content_t ファイルにアクセスできる」というルールが定義されており、これを違反するとアクセス拒否（AVC Denial）が発生します。

SELinux の動作モードも三つ存在し、AppArmor と同様ですがコマンドが異なります。

1. Enforcing Mode: 強制モード。ポリシー違反をブロックしログを記録します。標準設定です。
2. Permissive Mode: 報告モード。違反しても動作は続行されますが、ログに警告が出ます。トラブルシューティング時に使用します。
3. Disabled Mode: 無効化モード。SELinux の機能自体を停止させます。セキュリティリスクが高いため通常推奨されません。

これらのモードは setenforce コマンドで変更できます（例：sudo setenforce 0 で Permissive、sudo setenforce 1 で Enforcing）。また、現在の状態を確認するには getenforce コマンドを使用します。さらに、SELinux の詳細な設定を管理するために sestatus コマンドも頻繁に使用されます。

SELinux のポリシー調整には、主に setsebool と semanage という二つの主要ツールが利用されます。

• setsebool: システムのブール値（スイッチ）を変更します。これにより、特定の機能（例：ネットワーク接続やファイル書き込み）を一時的に許可・禁止できます。永続的な変更には -P オプションを指定します。
• semanage fcontext: ファイルコンテキストのマッピングを変更し、新規作成されたファイルにも正しいラベルが自動的に付与されるように設定します。

例えば、Nginx が標準のドキュメントルート以外からコンテンツを読み込む必要がある場合、単に setenforce 0 として SELinux を無効にするのではなく、適切なブール値を設定するのがベストプラクティスです。

• sudo setsebool -P httpd_can_network_connect 1: Nginx が外部へネットワーク接続可能にする。
• sudo setsebool -P httpd_execmem 1: Nginx のメモリ実行権限を許可する（セキュリティリスクあり）。

2026 年時点の RHEL 9 や Fedora 41 では、SELinux ポリシーが非常に厳格に設定されています。特定のアプリケーションで問題が発生した際は、まずそのアプリケーションに関連するブール値を確認し、許可される範囲内で動作させるよう調整します。これにより、セキュリティを維持しつつ機能的な問題を解決できます。

Web サーバーとデータベースのポリシー設定比較実践例

実際の運用環境において、AppArmor と SELinux の設定がどのように異なるのかを具体的に示すために、Nginx（Web サーバー）と PostgreSQL（データベース）の組み合わせでのポリシー設定を比較解説します。これにより、それぞれのシステムにおけるセキュリティ制御のニュアンスの違いを理解できます。

まず Nginx に関する設定から始めます。Ubuntu 24.04（AppArmor）では、/etc/apparmor.d/usr.sbin.nginx というファイルがデフォルトで存在し、基本的な Web サーバーとしての動作を制限しています。しかし、カスタムのドキュメントルートを使用する場合や、特定のモジュールを追加する場合には、このプロファイルを編集する必要があります。

• AppArmor 設定例: プロファイル内に /var/www/myapp/** rw を追加します。これにより、/var/www/myapp ディレクトリ内の全ファイルへの読み書きが許可されます。
• SELinux 設定例: Nginx のプロセスは httpd_t です。ドキュメントルートのコンテキストを httpd_sys_content_t に合わせるため、sudo chcon -Rt httpd_sys_content_t /var/www/myapp を実行し、永続化には sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/myapp(/.*)?" を使用します。

PostgreSQL に関する設定ではさらに複雑になります。データベースは機密データを扱うため、ファイルアクセス制御が厳格です。

• AppArmor: [PostgreSQL のバイナリパス（例：/usr/lib/postgresql/16/bin/postgres）に対して読み書き権限を明示的に付与する必要があります。ログディレクトリへの書き込みも許可範囲に含まれます。
• SELinux: デフォルトで postgresql_t タイプが割り当てられています。しかし、コンテナ環境やカスタムポートを使用する場合は、ポートのラベル付けが必要です。sudo semanage port -a -t postgresql_port_t -p tcp 5432 のように、特定のポート番号を SELinux ポリシーに追加します。

両システムにおける設定の違いは、ファイルパスの指定の有無です。AppArmor はファイルシステム構造に依存するため、ディストリビューションごとのバイナリ配置（例：/usr/sbin/nginx vs /usr/bin/nginx）の変更に対応するためにプロファイルを調整する必要があります。一方、SELinux はコンテキスト（タイプ）に基づいているため、ファイルがどの場所に置かれていても、正しいラベルを付与されていれば動作します。

以下に、両システムの主要な設定コマンドと設定項目の比較を表にまとめました。この表を参照することで、それぞれのシステムで何を行うべきかが明確になります。

この比較からわかるように、SELinux はブール値やポートラベルの管理がより体系的ですが、その分コマンドの種類も多岐にわたります。AppArmor は直感的なファイルパス指定で済みますが、OS の変更に対応するメンテナンスコストが発生し得ます。運用環境では、アプリケーションの特性に合わせてどちらのシステムを優先的に利用するか検討する必要があります。

トラブルシューティングとログ解析の実践的ガイド

セキュリティポリシーを設定した際や、システムアップデート後にサービスが起動しないといったトラブルは必ず発生します。その際、最も重要なのが「AVC Denied」メッセージや AppArmor の拒否ログの正しい読み方です。これらのエラーメッセージを誤って解釈すると、セキュリティホールを開く危険な設定変更につながります。

まず SELinux の場合、/var/log/audit/audit.log が主要なログファイルとなります。このファイルには type=AVC msg=audit(...): avc: denied { read } for pid=... comm="nginx" name="/etc/nginx/nginx.conf" ... といった形式で記録されます。

• denied: アクセスが拒否されたことを示します。
• { read }: 試みられたアクション（読み取り、書き込み、実行など）。
• comm="nginx": プロセス名。
• name="/etc/nginx/...": 対象ファイルパス。

これを読み解く際に便利なのが audit2allow ツールです。このツールは、AVC エラーを解析し、許可するルール（ポリシーモジュール）を生成します。しかし、安易に audit2allow -w | audit2allow -i を実行してすべてのエラーを無条件で許可するのは禁物です。なぜなら、誤って重要なシステムファイルへの書き込み権限が与えられてしまう可能性があるからです。

推奨される手順は以下の通りです：

1. ausearch -m avc -ts recent | audit2allow -w を実行し、エラーの原因を特定する。
2. 問題のファイルやプロセスが本当にそのアクセス権限を持つべきか検証する。
3. 必要であれば、特定のファイルパスに対してのみ許可するルール（例：file_rule）を作成して適用する。
4. sealert -a <ログID> を使用し、より人間 readable な解説を表示させる。

AppArmor の場合も同様の考え方が必要です。dmesg コマンドや /var/log/syslog において apparmor="DENIED" と表示されるメッセージが検索対象となります。

• profile=: プロファイル名。
• operation=: 試みられた操作（read, write, open など）。
• path=: 対象パス。

AppArmor のトラブルシューティングには、aa-logprof が強力なサポートツールです。エラーが頻発している場合、このツールを起動すると対話形式でプロファイルへの追加を提案してくれます。例えば、/var/www/html/index.html の読み込み拒否が発生した際、「このパスの読み取りを許可しますか？」と問われ、Yes と答えると自動的にルールが追加されます。

• 警告: 自動生成されたルールの詳細は必ず確認してください。特に **（ワイルドカード）が含まれる場合は、意図しないファイルへのアクセス許可につながる可能性があります。

2026 年時点での最新ツールとして、SELinux のコンテキスト修正に特化した setfiles ツールや、AppArmor のプロファイル検証を行う apparmor_parser -r も標準装備されています。これらのコマンドを組み合わせて使用することで、システム全体のセキュリティと可用性のバランスを保つことが可能です。

Docker と Podman におけるコンテナ環境での設定

現代の Linux サーバーでは Docker や Podman といったコンテナ化技術が主流であり、MAC システムとの連携は必須事項となっています。コンテナ内のプロセスもホスト OS の MAC ポリシーの影響を受けるため、適切な設定を行わないとセキュリティリスクが増大します。

Docker における AppArmor: Ubuntu 24.04 などの AppArmor 標準ディストリビューションでは、Docker デーモンが起動する際にデフォルトのプロファイル（docker-default）を適用します。このプロファイルはコンテナに対して比較的緩い制限を課すよう設計されています。しかし、セキュリティを強化したい場合はカスタムプロファイルを作成して適用可能です。

• 設定方法: /etc/apparmor.d/docker-custom などのファイルを新規作成し、コンテナのアクセス制限を定義します。
• 適用コマンド: docker run --security-opt apparmor=profile_name <イメージ名> で指定できます。
• 注意点: 標準プロファイルを使用すると、セキュリティホールからコンテナ内への侵入が容易になる場合があります。重要データを含むコンテナではカスタムプロファイルの採用を検討すべきです。

Podman と SELinux: Fedora や RHEL 環境で標準的な Podman は、SELinux コンテキストを厳密に適用します。特に「Rootless Mode（非ルートモード）」での実行において、SELinux の役割は大きくなります。

• コンテナ作成時: podman run コマンドを実行すると、SELinux ポリシーに基づいてコンテナのファイルシステムラベルが自動的に生成されます。
• 設定確認: podman inspect <コンテナID> | grep Label でコンテナの SELinux ラベルを確認できます。
• ブール値: コンテナから外部ポートへの接続が必要な場合、setsebool -P container_can_network_connect 1 のようなブール値を調整する必要があります（バージョンにより異なります）。

コンテナ環境における MAC システムの違いは、セキュリティ境界の明確さにも影響します。SELinux を使用する場合、ホスト OS とコンテナ間の境界線が明確に定義されており、コンテナ内のプロセスがホストのシステムファイルへアクセスするのを防ぐ制御が強力です。一方、AppArmor はコンテナのプロセス自体を制限するアプローチを取るため、コンテナ内での挙動制御には優れていますが、ホストとの境界管理では SELinux に劣る場合があります。

2026 年時点でのベストプラクティスとして、以下の表に Docker と Podman における MAC の推奨設定をまとめました。

コンテナ環境を構築する際は、ランタイムの種類に合わせて適切な MAC ツールを選択し、その設定を CI/CD パイプラインに組み込むことが重要です。例えば、Docker Compose を使用する場合でも、security_opt セクションで AppArmor プロファイルを明示的に指定することで、セキュリティ強度を向上させられます。

最適な選択のための比較と導入戦略

最後に、AppArmor と SELinux のどちらを採用すべきかという最終的な判断基準を提供します。これは単なる機能比較ではなく、貴社の運用環境やチームのスキルセットに基づいた戦略的な選定が必要です。

まず、学習コストと可用性の観点から判断します。

• AppArmor が推奨されるケース: Linux 初心者やシステム管理者が限られている環境。Ubuntu や Debian を使用している場合、デフォルトで有効化されており、パスベースの設定はファイル管理の知識があれば直ちに適用可能です。また、コンテナ内での動作制御に優れており、軽量な Web サーバーや開発環境に適しています。
• SELinux が推奨されるケース: 高度なセキュリティ要件がある企業環境（金融、医療など）。Fedora や RHEL を採用している場合、ポリシーの柔軟性が高く、複雑なアクセス制御を定義する能力が備わっています。また、標準的な Linux ディストリビューションとの互換性が高いです。

次に、パフォーマンスとオーバーヘッドについて触れます。

• 多くのベンチマークにおいて、両者の性能差は 1% 未満と非常に小さいことが示されています。ただし、AppArmor はファイルシステムの状態を頻繁にチェックする性質上、I/O 負荷がわずかに高い場合があります。一方、SELinux はラベルの照合を行うため、メモリアクセスのオーバーヘッドが若干生じる可能性があります。
• 2026 年時点ではハードウェア性能が向上しているため、この差は通常の利用シーンでは無視できる範囲です。ただし、I/O バウンドなストレージシステムやリアルタイム性が要求される環境では、ベンチマークを事前に実施することを推奨します。

導入戦略の観点からは、段階的な移行が最も安全です。

1. 初期フェーズ: 報告モード（Complain/Permissive）で稼働させ、ログ収集を行う。
2. 検証フェーズ: ログに基づきポリシーを作成し、特定のサービスから開始する。
3. 本番フェーズ: 全体的に強制モードへ移行し、監視体制を整える。

このように段階的に進めることで、システムダウンを防ぎつつセキュリティを強化できます。また、2026 年以降の Linux システムでは、AI や機械学習アルゴリズムによる自動ポリシー生成がさらに進化すると予想されます。AppArmor の aa-logprof や SELinux の audit2allow はすでにその萌芽ですが、将来的には AI が AVC エラーを解析し、最適なルールを提案する機能も標準装備される可能性があります。

よくある質問（FAQ）

Q1: AppArmor と SELinux を同時に有効にすることは可能ですか？ A1: 技術的には両方インストールできますが、推奨されません。相互の競合により予期せぬ動作やパフォーマンス低下を招く恐れがあります。どちらか一方を選択し、ディストリビューションのデフォルト設定に従うのが安全です。

Q2: SELinux を無効化してもセキュリティは保てますか？ A2: いいえ、推奨されません。SELinux は DAC にはない追加の防御層として機能しており、これを無効化すると脆弱性を利用した攻撃に対する耐性が著しく低下します。無効化する場合は一時的なトラブルシューティングに限ってください。

Q3: AppArmor のプロファイル編集後にエラーが出る場合どうすればよいですか？ A3: まず aa-status でステータスを確認し、エラーメッセージを特定してください。その後、apparmor_parser -r <ファイルパス> を実行して再読み込みを試みます。修正に失敗した場合は、一度 aa-complain モードにして動作確認を行ってください。

Q4: SELinux のブール値を変更すると再起動が必要ですか？ A4: 通常は不要です。setsebool コマンドで即時変更できますが、永続化には -P オプションが必要です（例：-P httpd_can_network_connect 1）。これによりシステム起動時に設定が維持されます。

Q5: Docker コンテナ内で AppArmor を使用するにはどうすればよいですか？ A5: docker run --security-opt apparmor=custom_profile_name <image> のように指定します。ただし、ホスト OS で AppArmor が有効化されている必要があります。カスタムプロファイルは /etc/apparmor.d/ に作成し、aa-complain モードでテストしてください。

Q6: ポリシーが複雑になりすぎて管理できない場合どうすればよいですか？ A6: 一度にすべてのルールを定義するのではなく、最小限の権限から始め、エラーログに応じて徐々に追加していくアプローチ（ホワイトリスト方式）を取ることが推奨されます。また、ツールを活用して自動化することで負荷を軽減できます。

Q7: Ubuntu と Fedora の両方で同じ設定ファイルは流用可能ですか？ A7: いいえ、互換性はありません。AppArmor はパスベース、SELinux はタイプベースであるため、構文も内容も全く異なります。それぞれのシステムに合わせた設定ファイルを別途作成する必要があります。

Q8: 2026 年時点で AppArmor よりも SELinux が優れている点はありますか？ A8: セキュリティの粒度と柔軟性において SELinux がわずかに上回ります。特に、複雑なアクセス制御や、異なる OS バージョン間でのポリシー移植性を重視する場合は SELinux が有利です。

Q9: 設定ミスでシステムが起動しなくなった場合どう復旧しますか？ A9: セーフモードや rescue mode からブートし、setenforce 0 または aa-complain を実行して一時的に制限を解除してください。その後、ログを確認して問題の原因となるルールを修正します。

Q10: パフォーマンスへの影響は具体的にどの程度ですか？ A10: 一般的な Web サーバーやファイルサーバーでは 0.5% 未満のオーバーヘッドとされています。ただし、大量の I/O を行うストレージシステムやリアルタイム処理が必要な環境では、事前ベンチマークによる確認が必須です。

まとめ

本記事では、Linux における強制アクセス制御（MAC）システムの二大巨頭である AppArmor と SELinux について、2026 年時点の情報に基づき詳細に比較解説しました。以下の要点をまとめます。

• 基本構造の違い: AppArmor はパスベースで直感的、SELinux はタイプベースで柔軟性が高いです。
• 採用環境: U[bun](/glossary/bun-runtime)tu/Debian/openSUSE では AppArmor が標準、Fedora/RHEL では SELinux が標準です。
• 設定ツール: aa-* コマンド群が AppArmor を管理し、se* コマンド群が SELinux を管理します。
• コンテナ連携: Docker は AppArmor の柔軟性を、Podman は SELinux の厳密性を活用しています。
• トラブルシューティング: 各ログ形式（syslog vs audit.log）の理解と、安全な自動修正ツールの使用が重要です。

セキュリティは一度設定すれば終わりではなく、継続的な監視と調整が必要です。本ガイドを参考に、貴社の環境に最適な MAC システムを構築し、堅牢な IT インフラを実現してください。