Linuxを守る「SELinux」と「AppArmor」は何が違うのか？：Linuxのセキュリティを比較【前編】

「Linux」を不正アクセスから保護するために、「SELinux」と「AppArmor」が活用できる。両者は具体的に何が違うのか。複数の観点から解説する。

[Jack Wallen，TechTarget]

　OS「Linux」は複数のセキュリティモジュールを標準で搭載する。その代表例が「SELinux」（Security-Enhanced Linux）と「AppArmor」だ。攻撃者による不正アクセスを防ぐため、アプリケーション分離機能を提供する点は共通だが、動作方法は異なる。以下でその違いを見ていこう。

SELinuxとAppArmorの違い

デフォルトの設定

併せて読みたいお薦め記事

Linuxの運用管理

• いまさら聞けない「Linux」コマンド　tarでファイルを操作する
• Linuxで「777」を設定してはいけない理由

　Linuxはディストリビューション（配布用パッケージ）によって、AppArmorとSELinuxのどちらが標準で有効化されているのかが異なる。具体的には、以下の「Red Hat Enterprise Linux」（RHEL）およびその派生ディストリビューションにおいて、標準でSELinuxが有効だ。

• RHEL
• Rocky Linux
• AlmaLinux
• CentOS Stream
• Fedora

　これに対して、以下の「Debian」とその派生ディストリビューションは、標準のセキュリティモジュールとしてAppArmorを採用している。

• Debian
• Ubuntu
• SUSE Linux
  • 商用版の「SUSE Linux Enterprise Server」
  • オープンソース版の「openSUSE」

　DebianベースのディストリビューションでSELinuxを利用できる一方、RHELベースのディストリビューションでAppArmorを利用することは推奨されていない。

アクセス制御

　SELinuxでは、セキュリティ属性の情報を示す「ラベル」をプロセスやファイルに割り当て、ラベルに基づいてセキュリティポリシーを構築する。セキュリティポリシーはエンドユーザーがアクセスできるもの、できないものを定義し、それに沿ってアプリケーションやプロセス、ファイルといったリソースに対するアクセス制御を実施する。セキュリティポリシーが未定義の場合、SELinuxはアクセスを許可しない。

　AppArmorはファイルパスごとにパーミッションの設定一式（プロファイル）を定義することで、アクセスを制御する。従来型の任意アクセス制御（DAC：Discretionary Access Control）は、リソースの所有者や管理者が他のエンドユーザーのアクセス権限を制御できるが、これはエンドユーザーの判断にアクセス権限の管理を委ねることになる。この欠点を補うためにAppArmorが提供するのが、強制アクセス制御（MAC：Mandatory Access Control）という仕組みだ。これによって、エンドユーザーの判断に左右されないセキュリティポリシーの運用が可能になる。

MLSとMCS

　「MLS」（Multi-Level Security）は、異なるセキュリティレベルを持つ情報の扱いを可能にするための仕組みだ。エンドユーザーとプロセスを「サブジェクト」、ファイルやデバイスなどのコンポーネントを「オブジェクト」として扱い、それぞれのセキュリティレベルの違いに基づいてアクセスを制限できる。

　「MCS」（Multi-Category Security）は、性質や用途に基づいた「カテゴリー」をオブジェクトに割り当て、カテゴリーに応じてアクセス制御をする仕組みだ。これによってSELinuxを利用するIT管理者は、異なるカテゴリーごとにアクセス制御をしやすくなる。

　SELinuxはMLSとMCSを使用するが、AppArmorはどちらも使用しない。

コンポーネント

　SELinuxは、主に以下のコンポーネントから成る。

• サブジェクト
  • エンドユーザーやプロセスなど、アクセス制御を要求する主体
• オブジェクト
  • ファイルやソケット、ネットワークインタフェースなど、アクセス制御の対象となる主体
• カーネルモジュール
  • SELinuxを実現するモジュール
• Access Vector Cache
  • パーミッションのキャッシュ
• Security Server
  • アクセス制限をするかどうかを決定する、SELinuxの中核的なプログラム群
• SELinux Policy Database
  • セキュリティポリシーを保管するデータベース

　AppArmorを構成する主要なコンポーネントは以下の通りだ。

• プロファイル
  • アクセス制御のルール一式
• Profile Loader
  • OS起動時にプロファイルを読み込んで適用する
• 支援ツール
• プロファイルの作成、編集、デバッグなどを実行するためのユーティリティー

アクセス制御レベル

　SELinuxで利用可能なポリシーは以下の2つだ。

1. Targeted
   • デフォルトのポリシー
   • 特定のプロセスに対するアクセス制御を実施する
   • 対象となったプロセスは特定のドメインでのみ実行され、ファイルへのアクセスが制限される
2. MLS
   • セキュリティレベルに基づいてアクセスを制御する

　モードは以下の3種類がある。

1. Enforcing
   • デフォルトのモード
   • 読み込んだセキュリティポリシーをシステム全体に適用する
2. Permissive
   • システムが全てのアクティビティーをログに記録し、アクティビティーの実行を拒否しない
3. Disabled
   • SELinuxを無効にする

　AppArmorのプロファイルは、動作に関わる以下の要素を含む。

1. Paths
   • プロセスがアクセスできるファイルを定義する
2. Capabilities
   • プロセスが特定の機能を使用することを制限する

　AppArmorには2つのモードがある。

• Enforce
  • ポリシーを強制的に適用する
• Complain
  • ポリシーに違反した挙動のみをログに記録する

使い勝手

　一般的にSELinuxの仕組みは複雑であるため、AppArmorよりも使い方が難しい。その分、SELinuxの方がより細かくアプリケーション分離を制御しやすい。SELinuxに精通していないIT管理者が誤ってSELinuxを無効にしてしまい、システムを脆弱（ぜいじゃく）にする場合がある。

　AppArmorはSELinuxと比べて習得と使用が簡単であるため、SELinuxよりも安全な選択肢だと言える。複雑な制御を必要とするIT管理者にとっては、SELinuxの方が適切だ。

　これらの違いを以下の表にまとめる。

表　SELinuxとAppArmorの違い

機能	SELinux	AppArmor
アクセス制御	ラベルをベースとしたセキュリティポリシー	パスをベースとしたセキュリティポリシー
MLS／MCS	MLSとMCSの両方を使用	MLSとMCSを使用しない
使いやすさ	AppArmorよりも習得が難しい	SELinuxよりも習得しやすく使いやすい
ディストリビューション	RHELベースのディストリビューションを中心に採用	Debianベースのディストリビューションを中心に採用

---

　次回は、SELinuxとAppArmorの利点および欠点を比べる。

TechTarget発　先取りITトレンド

米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。