🛡️ SELinux 運用管理

第1章：防御設計の基本思想と役割分担

1-1. なぜSELinuxが必要なのか

通常のLinuxでは、root権限（UID=0）はDAC（Discretionary Access Control：任意アクセス制御）を広範囲に迂回できるため、Webサーバー等のアプリケーションに脆弱性（RCE等）が存在し攻撃者にroot権限を取得されると、システム全体へ重大な影響を及ぼす可能性があります（/etc/shadowの盗み見、各種設定やバイナリの改ざん等）。

一方、SELinuxを有効化しているシステムでは、カーネルレベルでMAC（Mandatory Access Control：強制アクセス制御）が追加されます。仮に攻撃者がサービスプロセスを乗っ取り、そのプロセスがOS上でroot権限（UID=0）を得たとしても、SELinuxドメイン（例：httpd_t）から許可されていない操作はMACポリシーにより拒否されます。

1-2. ホスト内ゼロトラストアーキテクチャ図

SELinuxはLSM（Linux Security Module）フックを介して、システムコール処理中に呼び出されるカーネル内部のセキュリティフックにおいてアクセス制御を実施します。

┌──────────────────────────────────────────────┐
│               Rocky Linux 9                    │
│                                                 │
│  Firewalld (nftables)                          │
Internet ──▶│      │                             │
    │       │      ▼                             │
    ▼       │  Caddy プロキシ (Webサーバー/例: httpd_t)  │
FortiGate ──▶│      │                             │
             │      ├── Webコンテンツ (httpd_sys_content_t) │
             │      ├── Authentik (コンテナプロセス)         │
             │      └── Headscale (コンテナプロセス)         │
             │                                    │
             │  【 SELinux (MAC) 】                │
             │    └─ カーネル内部のセキュリティフックで監視  │
             └──────────────────────────────────────────────┘

1-3. 各防衛レイヤーの役割分担表

第2章：セキュリティコンテキスト（Security Context）の設計基準

SELinuxのアクセス制限は、プロセスやファイルなどのリソースに付与されたセキュリティコンテキスト（ラベル）に基づいて判定されます。

2-1. SELinuxにおけるセキュリティモデルの種別

2-2. コンテキスト構成の設計標準

ファイルシステム上のオブジェクト（ファイル、ディレクトリ等）やプロセス、ソケット等のすべてのオブジェクトは、以下のコンテキスト構造によって識別されます。

system_u : object_r : httpd_sys_content_t : s0

• ユーザー（system_u / unconfined_u 等）：SELinux独自のユーザー識別子。
• ロール（system_r / object_r 等）：プロセスやファイルの役割を定義。ファイルなどの静的オブジェクトは原則としてobject_r固定となります。
• タイプ（httpd_sys_content_t 等）：SELinuxアクセスの判定根拠となる最重要ラベル。プロセス側のタイプは「ドメイン」と呼ばれます。
• 感度レベル（s0 等）：マルチレベルセキュリティ（MLS/MCS）環境における機密レベル分類。

2-3. 実機によるコンテキスト確認手順（CLIリファレンス）

管理者は、各確認コマンドに-Zオプションを付与することで、セキュリティコンテキストを調査できます。

# 1. Webサーバープロセス（例：httpd_t または導入環境ごとの専用ドメイン）の確認
ps -eZ | grep -E '(httpd|caddy)'

# 2. 公開用ディレクトリ内のファイルラベル確認
ls -Z /var/www/html/index.html

# 3. 現在の作業ユーザー（管理者シェル）のコンテキスト確認
id -Z

第3章：単一アクセス処理の完全ライフサイクル（VFS / LSM / AVC）

1回のファイルアクセス要求（例：open()システムコール）が発生した際、Linuxカーネル内部でどのような順番で処理・評価が実行されるかを示す完全処理フローです。

[ Application (例: httpd) ]
      │
      ▼ 1. open("/var/www/html/index.html")
┌──────────────────────────┐
│ カーネル空間: VFS (Virtual File System) │
└──────────────────────────┘
      │
      ▼ 2. 任意アクセス制御の検証
┌──────────────────────────┐
│ DAC (Discretionary Access Control)   │
│ └─ UID/GIDおよびrwxパーミッションを評価 │
└──────────────────────────┘
      │
      ├─ [ 拒否 ] ──▶ エラー返却 (-EACCES) して終了
      ▼ [ 許可 ] 3. LSMフックの呼び出し
┌──────────────────────────┐
│ LSM Hook (security_file_open)        │
└──────────────────────────┘
      │
      ▼ 4. SELinux高速判定
┌──────────────────────────┐
│ AVC (Access Vector Cache) 検索        │
└──────────────────────────┘
      │
      ├─ [ キャッシュヒット (ALLOW) ] ─────────────┐
      ├─ [ キャッシュヒット (DENY) ] ──▶ 拒否処理へ │
      │                                         │
      ▼ [ キャッシュミス ] 5. セキュリティサーバー評価│
┌──────────────────────────┐
│ SELinux Security Server (ポリシーデータベース検索) │
│ └─ Active Policy DB (ポリシー定義) を参照         │
└──────────────────────────┘
      │
      ▼ 6. 判定結果をAVCへ追加登録
┌──────────────────────────┐
│ AVC Cache へ判定結果を登録             │
└──────────────────────────┘
      │
      ├─ [ 拒否 (DENY) ] ──▶ 監査ログ(audit.log)出力、エラー返却 (-EACCES)
      ▼ [ 許可 (ALLOW) ] 7. 物理ファイルシステムへの渡しの許可
┌──────────────────────────┐
│ Filesystem Driver (ext4 / xfs)        │
└──────────────────────────┘
      │
      ▼ 8. ディスク読み出し実行
┌──────────────────────────┐
│ Physical Disk / SSD                   │
└──────────────────────────┘

第4章：SELinux 内部エンジン構造（LSM、VFS、および AVC キャッシュ）

4-1. AVCキャッシュミス時の内部アクセスフロー

システムコールが発生した際、AVC内に判定ルールが存在しない場合の処理ルーティングです。

[ LSM フック呼び出し ]
          │
          ▼
【 AVC Cache 内を検索 】
          │
          ├─ (ヒットあり) ───────────── (判定結果返却) ──▶ [ 制御確定 ]
          │
          └─ (ミスなし) ──▶ 【 SELinux Security Server (ポリシーデータベース検索) 】
                                   │
                                   ▼ 照会
                             【 Active Policy DB 】
                                   │
                                   ▼ 判定算出
                             【 AVC Cache へ判定結果を登録 】
                                   │
                                   ▼
                             (判定結果返却) ─────────────▶ [ 制御確定 ]

4-2. AVC（Access Vector Cache）の判定キー

AVCは、「送信元ドメイン」「対象タイプ」「オブジェクトクラス」「アクセス権限」などをキーとして、LSMから渡される要求結果を高速にキャッシュ判定します。

第5章：Domain Transition（ドメイン遷移）の機構とexecve()

SELinuxのドメイン変更（例：シェル起動からWebプロセス起動時など）は、新しいバイナリプログラムをロードして実行するexecve()システムコールが発行された瞬間にのみ評価されます。

5-1. fork()とexecve()の違いとentrypoint属性の関係

• fork()：親プロセスのクローンを作成するだけであるため、実行バイナリ自体は変更されず、SELinuxドメインの遷移も発生しません。
• execve()：現在のプロセスイメージを完全に新しい実行プログラム（バイナリ）で置き換えます。SELinuxは「別プログラムが実行された瞬間」を検知し、エントリポイント（起点）チェックを実施します。
• ドメイン遷移の判定：SELinuxは、実行対象のバイナリファイルに対するexecute権限、実行ファイルの起点を示すentrypoint属性、ポリシー上で遷移を宣言するtype_transitionルール等を総合的に評価してドメイン遷移を決定します。

【 親プロセス 】(例: init_t)
       │
       ▼ fork() システムコール実行
【 子プロセス 】(ドメインは親と同一のinit_tを継承。プログラム自体は不変)
       │
       ▼ execve("/usr/sbin/httpd") 実行
       ├─ httpd_exec_t (バイナリファイル) の execute 権限を検証
       ├─ httpd_exec_t の「entrypoint」属性を検証
       │  (※entrypoint属性とは、「この実行ファイルを起点としてドメイン遷移を許可する」ためのSELinux属性です)
       └─ type_transition ポリシールールの整合性を検証
       ▼
【 遷移後プロセス 】(新ドメイン httpd_t として実行開始)

内部ポリシー（Type Enforcement）記述の対応例

上記のドメイン遷移を実現するために、ポリシー（.teファイル）内部には以下のルールが定義されています。

# 実行ファイル(httpd_exec_t)の実行を許可
allow init_t httpd_exec_t:file execute;

# execve実行時にinit_tからhttpd_tへのドメイン自動遷移を宣言
type_transition init_t httpd_exec_t:process httpd_t;

第6章：トラブルシューティングの優先順位と「正しい」解決プロトコル

不具合が発生した際、機械的にaudit2allowを用いてポリシーを生成・許可してしまうことは、最小権限の原則を破壊するおそれがあります。管理者は以下の「トラブルシューティングの優先順位」に沿って問題の解決を図らなければなりません。

6-1. トラブルシューティングの優先順位（4ステップ）

原因：cpやmv等の操作によって、一時的にファイルコンテキストが崩れていないか？
対処：標準データベースに基づき、セキュリティコンテキストを本来の初期ラベルに修復する。

原因：OSがあらかじめ用意している「動作許可スイッチ」がオフのままになっていないか？
対処：Boolean（機能スイッチ）を変更して機能を安全に開通させる。

原因：自社の独自ディレクトリ構造など、OS標準外のカスタムパスでファイルを配置していないか？
対処：semanage fcontextを用いて、自システム用の適用ディレクトリ定義ルールを永続登録する。

原因：自社開発プログラムなど、既存のラベル定義ではどうしても解決できない独自の挙動か？
対処：拒否ログ（audit.log）から必要最小限のallowルールを記述したモジュールをビルドして適用する。

第7章：実務におけるファイル操作と「ラベル崩れ」の挙動原理

OS上でファイルを移動（mv）またはコピー（cp）した際、SELinuxのコンテキストがどのように扱われ、どのように「ラベル崩れ」が発生するかを解説します。

7-1. コマンド別のコンテキスト挙動とinodeの関係

• 同一ファイルシステム内のmv挙動とinode：同一ファイルシステム内でmvコマンドを実行する場合、ファイルの実データは移動せず、ファイルを識別するinode番号および拡張属性（xattr）を保持したまま、ディレクトリエントリのみを変更します。そのため、ファイルの属性情報の一部であるセキュリティコンテキストもそのまま保持されます（移動先でラベル不一致が起きやすい原因）。
• restoreconコマンド実行時の内部API連携：restoreconを実行すると、コマンドはlibselinuxの参照ルーチン（selabel_lookup()）を呼び出してfile_contextsデータベースから正解のラベルを取得し、最終的にsetxattr()システムコールを発行してファイルシステムの拡張属性領域に正解コンテキストを書き込みます。

restorecon ──▶ libselinux ──▶ selabel_lookup() ──▶ file_contexts検索 ──▶ setxattr() (拡張属性を書き換え)

第8章：実効性の高いポリシー・パラメータ実装ガイド（差分表示）

強化案1：Webサーバープロセスから内部コンテナ（Authentik/Headscale）へのネットワーク接続許可

# --- Webサーバープロセスによるネットワークコネクト Boolean の状況確認 ---
getsebool httpd_can_network_connect

# --- 永続的な機能変更の実施 (差分) ---
+ sudo setsebool -P httpd_can_network_connect 1

強化案2：独自構成ディレクトリ（例: /var/web_custom）への適切なセキュリティコンテキスト永続追加

# --- データベースに独自パス用のコンテキスト定義を追加 (差分) ---
+ sudo semanage fcontext -a -t httpd_sys_content_t "/var/web_custom(/.*)?"

# --- 追加された新規ルール定義データベースを、実物理ディレクトリへ強制同期・修復 (差分) ---
+ sudo restorecon -R -v /var/web_custom

第9章：日常運用・保守コマンドリファレンス

# 現在のSELinux詳細稼働ステータスを確認
sestatus

# 一時的に警告のみのPermissiveモードに切り替えて不具合をテストする
sudo setenforce 0

# テスト完了後、即座に本来の安全なEnforcing (強制) モードに戻す
sudo setenforce 1

第10章：AVC Denialログの解読実践

SELinuxがシステム動作を拒否（Denial）した際、監査ログ（/var/log/audit/audit.log）に記録される生ログ情報を正確に分析・解読するための解説です。

10-1. 実際のAVC拒否ログの完全構造

以下は、Webサーバー（httpd）がシステム機密ファイル（/etc/shadow）を不正に読み込もうとした際に記録された代表的なAVC拒否ログです。

type=AVC msg=audit(1685000000.123:456): avc:  denied  { read } for  pid=1234 comm="httpd"
name="shadow" dev="dm-0" ino=98765
scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file

10-2. ログパラメータの詳細解読表

10-3. ログが示すアクセス拒否マッピング

[ 主体 (プロセスドメイン) ] httpd_t
          │
          │ 操作: read (読み取り) を要求
          ▼
 [ 客体 (オブジェクトタイプ:クラス) ] shadow_t : file
          │
          ▼
 【 判定結果: DENIED (ポリシーにallowルールが存在しないため遮断) 】

第11章：ゼロトラスト原則とSELinuxの機能対応（マトリクス）

11-1. ゼロトラストコア原則とSELinux機能の対応

NIST SP 800-207などのセキュリティフレームワークの思想を、OS内部で実際に具現化するための適用関係を定義します。

11-2. ゼロトラストアーキテクチャ全体におけるSELinuxの位置づけ

SELinuxはゼロトラストそのものを実現する製品ではありませんが、「侵害を前提とした設計（Assume Breach）」や「最小権限（Least Privilege）」をホストOS内部で実装する代表的な仕組みの一つです。他の認証・ネットワーク・監査技術と組み合わせることで、ゼロトラストアーキテクチャ全体を支える重要なコンポーネントとなります。

第12章：SELinux 運用で絶対に覚えておくべき5原則

① Enforcing（強制モード）を基本運用とする

本番サーバーでは常にEnforcingモードを維持します。これをPermissiveやDisabledに変更することは、カーネルレベルの多層防衛線を放棄することを意味します。

② Permissive（許容モード）は調査・診断目的のみに留める

何らかのエラーが発生した際、トラブル原因がSELinuxにあるかを切り分けるために一時的にsetenforce 0を使用することは有効です。しかし、原因特定後は必ずログを分析し、適切な設定を施したうえで即座にEnforcingに復帰させます。

③ 不具合発生時は「restorecon」を最初に疑う

ファイル作成やディレクトリ移動後、「なぜかアクセスできない」というトラブルが発生した際、最初に実行すべきコマンドはrestoreconです。システム設計書の不適切なコマンドや手順により付着した誤ったラベルを規定状態にリセットすることで、大半のトラブルは解決します。

④ 「audit2allow」を安易に使用しない

エラーログをそのまま流し込んで許可ルールを自動生成するaudit2allowの多用は、セキュリティホールの原因となります。原因そのものを精査し、アプリケーションの設定変更等で対応できない場合のみ最小限のルールを適用します。

⑤ 運用中に「Disabled（無効）」に変更しない

動作を完全に停止させるDisabled設定への移行は、システム全体を再起動しなければ元に戻せません。さらに、無効化されている間に作成・変更されたファイルにはラベルが付与されないため、再度有効化の際にシステム全域の再ラベリング（autorelabel）が必要になります。

第13章：コンテナ時代におけるSELinuxの設計標準（Podman / container_t）

コンテナ技術（Podman / Docker）が標準となった現代のLinux設計において、SELinuxはホストシステムをコンテナ内の不正プロセスから隔離（コンテナブレイクアウト対策）するために極めて重要な役割を果たします。

13-1. Podmanにおける SELinux 隔離アーキテクチャ

Podmanで起動したコンテナ内のプロセスは、ホストOS上で一般的にcontainer_tというセキュリティドメインを自動的に付与されて実行されます。

[ ユーザー空間 ] (ホストOSプロセス) ──▶ httpd_t (Webドメイン)
                                          │ (SELinuxによって相互に厳密に隔離)
 [ コンテナ空間 ] (Podman内プロセス)  ──▶ container_t (コンテナ汎用ドメイン)

この隔離構造により、仮にコンテナ内部でroot権限（UID=0）を取得され、かつコンテナエンジンの脆弱性が突かれてホスト上のファイルシステムに直接アクセスされたとしても、カーネルはcontainer_tからホストOSの一般領域（httpd_sys_content_t等）へのアクセスをポリシーに基づき拒否します。

13-2. ボリュームマウント時のコンテキスト付与フラグ（:z / :Z）

ホスト上のディレクトリをコンテナ内にマウントしてデータを共有（ボリュームマウント）する場合、SELinuxラベルのミスマッチによりコンテナ内からファイルを開けなくなる不具合が発生します。これを解決するため、マウント指定時に属性付与フラグを指定します。

• :z（共有ラベル）：マウント対象ディレクトリに対して、すべてのコンテナプロセスから共有可能なタイプcontainer_file_t / container_share_tを割り当てます。

# 複数コンテナ間で同じ共有ディレクトリをマウントする設定例
podman run -v /var/web_custom:/data:z -d container_image

• :Z（排他ラベル）：マウント対象ディレクトリに対して、該当コンテナインスタンス専用の一意なMCSカテゴリラベル（例：system_u:object_r:container_file_t:s0:c12,c34）を強制割り当てします。他のコンテナからのアクセスは完全に遮断されます（排他的・専用のボリューム向け）。

# 対象コンテナだけが専有する秘密の領域をマウントする設定例
podman run -v /var/auth_secret:/data:Z -d container_image

13-3. udicaを用いたコンテナ専用SELinuxポリシーの動的生成

「コンテナから特定のホストネットワークやファイルポートのみに安全にアクセスさせたい」という高度な要件に対して、すべての制限を解除する--privilegedを使用することはセキュリティ上推奨されません。Red Hat系ディストリビューションに標準で備わるツールudicaを使用すると、コンテナの構成ファイルをスキャンし、該当コンテナ専用のカスタムSELinuxポリシー（.pp）を安全に動的生成できます。

# 1. コンテナのJSON仕様をエクスポート
podman inspect <コンテナID> > container_spec.json

# 2. udicaを使用して、セキュリティ仕様に適合した最小権限ポリシーソースを生成
udica -j container_spec.json my_container_policy

# 3. 生成されたポリシーモジュールをコンパイルしてロード
semodule -i my_container_policy.pp

これにより、コンテナに対しても最小権限の原則（Least Privilege）を強制した、高セキュリティな運用が確立されます。

第14章：OS内部における完全セキュリティ実行スタック

外部からの要求パケットがネットワーク、アプリケーションを経て、最終的にOS内部のディスクにデータを永続化するまでの全体の技術スタック図です。

[ Userspace (ユーザー空間) ]
  Caddy / Apache (httpdプロセス)
       │
       ▼ システムコール (open, execve, write等)
────────────────────────────────────────────────────────
[ Kernel Space (カーネル空間) ]
  VFS (Virtual File System / 仮想ファイルシステム)
       │
       ▼
  DAC (任意アクセス制御: パーミッションrwxチェック)
       │
       ▼ [ DAC通過 ] LSMセキュリティフックの呼び出し
  SELinux (LSM 実装モジュール)
       ├── AVC (Access Vector Cacheによる高速判定)
       └── SELinux Security Server (判定未存在時のポリシーデータベース検索)
       │
       ▼ [ SELinux許可 ]
  Filesystem Driver (ext4, xfsなどのファイルシステムドライバ)
       │
       ▼
  Physical Disk / SSD (ストレージデバイス)