Linuxのセキュリティを比較【前編】
Linuxを守る「SELinux」と「AppArmor」は何が違うのか?
「Linux」を不正アクセスから保護するために、「SELinux」と「AppArmor」が活用できる。両者は具体的に何が違うのか。複数の観点から解説する。
OS「Linux」は複数のセキュリティモジュールを標準で搭載する。その代表例が「SELinux」(Security-Enhanced Linux)と「AppArmor」だ。攻撃者による不正アクセスを防ぐため、アプリケーション分離機能を提供する点は共通だが、動作方法は異なる。以下でその違いを見ていこう。
SELinuxとAppArmorの違い
デフォルトの設定
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つだ。
- Targeted
- デフォルトのポリシー
- 特定のプロセスに対するアクセス制御を実施する
- 対象となったプロセスは特定のドメインでのみ実行され、ファイルへのアクセスが制限される
- MLS
- セキュリティレベルに基づいてアクセスを制御する
モードは以下の3種類がある。
- Enforcing
- デフォルトのモード
- 読み込んだセキュリティポリシーをシステム全体に適用する
- Permissive
- システムが全てのアクティビティーをログに記録し、アクティビティーの実行を拒否しない
- Disabled
- SELinuxを無効にする
AppArmorのプロファイルは、動作に関わる以下の要素を含む。
- Paths
- プロセスがアクセスできるファイルを定義する
- Capabilities
- プロセスが特定の機能を使用することを制限する
AppArmorには2つのモードがある。
- Enforce
- ポリシーを強制的に適用する
- Complain
- ポリシーに違反した挙動のみをログに記録する
使い勝手
一般的にSELinuxの仕組みは複雑であるため、AppArmorよりも使い方が難しい。その分、SELinuxの方がより細かくアプリケーション分離を制御しやすい。SELinuxに精通していないIT管理者が誤ってSELinuxを無効にしてしまい、システムを脆弱(ぜいじゃく)にする場合がある。
AppArmorはSELinuxと比べて習得と使用が簡単であるため、SELinuxよりも安全な選択肢だと言える。複雑な制御を必要とするIT管理者にとっては、SELinuxの方が適切だ。
これらの違いを以下の表にまとめる。
| 機能 | SELinux | AppArmor |
|---|---|---|
| アクセス制御 | ラベルをベースとしたセキュリティポリシー | パスをベースとしたセキュリティポリシー |
| MLS/MCS | MLSとMCSの両方を使用 | MLSとMCSを使用しない |
| 使いやすさ | AppArmorよりも習得が難しい | SELinuxよりも習得しやすく使いやすい |
| ディストリビューション | RHELベースのディストリビューションを中心に採用 | Debianベースのディストリビューションを中心に採用 |
次回は、SELinuxとAppArmorの利点および欠点を比べる。
TechTarget発 先取りITトレンド
米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.
TechTarget発 先取りITトレンド
米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
2
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
3
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
4
「テザリング依存」に潜む落とし穴 “遅いVPN”を解消するネット構築術
-
5
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
6
「IT運用・情報システム業務」に関するアンケート
-
7
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
8
Claude利用8割のGMO、AI人材の評価軸が「トークン管理」に変わった
-
9
AI導入が失敗する“真犯人”は現場のマニュアル 7割が陥る「標準化」のわな
-
10
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
「IT史に名を残すシステム障害」8選
-
5
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
6
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
7
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
「標的型攻撃メール」事例・サンプル集
-
10
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー