---
title: LSM とアクセス制御
url: https://doc.liz6.com/ja/linux-kernel/09-security-mechanisms/01-lsm-and-access-control
locale: ja
area: linux-kernel
tags:
- linux-kernel
- security-mechanisms
date: 2026-06-30
modified: 2026-07-16
description: 'カバー範囲: Linux Security Modules アーキテクチャ → SELinux/AppArmor/SMACK → LSM フック機構 → BPF LSM → キャパビリティ → キーリング → IMA/EVM カーネルバージョン: 2.6 ~ 6.x'
---
# LSM とアクセス制御
> カバー範囲: Linux Security Modules アーキテクチャ → SELinux/AppArmor/SMACK → LSM フック機構 → BPF LSM → キャパビリティ → キーリング → IMA/EVM
> カーネルバージョン: 2.6 ~ 6.x
## 概要
従来の Unix DAC（Discretionary Access Control）では、所有者/グループ/その他という3段階の権限しか表現できず、「この Web サーバーは /var/www のみを読み取り可能で、/home/user/.ssh にはアクセス不可」といったきめ細かなポリシーを表現できません。LSM は、重要なシステムコールのパスにフックを挿入することで、セキュリティモジュールが追加のアクセス制御判断を行えるようにします。
現在、主要な2つの LSM は、SELinux（型強制に基づく強制アクセス制御）と AppArmor（パスマッチングに基づくプロファイルポリシー）です。
## LSM フックアーキテクチャ
```c
// include/linux/lsm_hooks.h
// 200以上のフックがすべての機微な操作をカバーします:
struct security_hook_heads {
struct hlist_head file_open; // open() の最終ステップ → security_file_open()
struct hlist_head inode_create; // inode の作成
struct hlist_head inode_unlink; // unlink()
struct hlist_head socket_create; // socket()
struct hlist_head socket_bind; // bind()
struct hlist_head task_kill; // kill()
struct hlist_head sb_mount; // mount()
// ... その他200以上
};
// 呼び出しチェーン:
// security_file_open(file) → call_void_hook(file_open, file)
// → 登録されているすべてのモジュールのフックを走査 → いずれかがエラーを返すと → 操作を拒否
```
### フックの挿入ポイント
---
## SELinux: 型強制
```
コア概念:
- すべてにラベル (label) が付与される: ファイル、プロセス、ソケットなど
→ ls -Z: system_u:object_r:httpd_sys_content_t:s0
- ポリシーは「どのソース型が、どのターゲット型の、どのクラスにアクセスできるか」を定義する
→ ホワイトリストモデル: デフォルトは拒否、明示的に許可されたもののみが許可
- AVC (Access Vector Cache): ポリシー照会結果のキャッシュ (パフォーマンスの要)
SELinux モード:
/sys/fs/selinux/enforce
Enforcing (1): 拒否 + ログ記録
Permissive (0): 許可 + ログ記録 (デバッグ用)
Disabled: 完全にロードしない
ラベルの保存:
ext4/xfs: xattr security.selinux
tmpfs/procfs: 実行時に生成 (genfscon)
```
## AppArmor: パスマッチング
```
パスプロファイルモデル:
セキュリティポリシーは型に基づかず、パスマッチングに基づきます:
/usr/bin/nginx {
/var/www/** r,
/var/log/nginx/* w,
/run/nginx.pid w,
/tmp/** rw,
capability net_bind_service,
}
利点:
- SELinux より直感的 (パスを見ればポリシーがわかる)
- ポリシーファイルが独立している (プログラムごとに1つ)
欠点:
- パスで回避可能 (ハードリンク、bind mount)
- 複雑なグローバル制約の表現が困難
```
## SMACK: 簡略化された型強制
```
SELinux に似ているが 90% 簡略化:
- ラベルのみ、ロール/ユーザー/MLS はなし
- ルール: 「subject label が object label にアクセス」
- 用途: Tizen (サムスン)、Automotive Grade Linux
カーネルコンパイル: CONFIG_SECURITY_SMACK
```
## BPF LSM (5.7以降)
```c
// BPF プログラムで LSM フックを実装:
// bpf(BPF_PROG_LOAD, BPF_PROG_TYPE_LSM, ...)
// attach: bpf(BPF_RAW_TRACEPOINT_OPEN, lsm/file_mprotect)
// カーネルモジュール相比の利点:
// - カーネルモジュールをコンパイルする必要がない
// - verifier により安全性が保証される (パニックしない)
// - 配布と更新が容易
```
## キャパビリティ: ルート権限の分割
```c
// include/uapi/linux/capability.h
// ルートの全能力をきめ細かなビットに分割:
CAP_SYS_ADMIN // システム管理
CAP_NET_RAW // raw socket
CAP_NET_BIND_SERVICE // 1024未満のポートへのバインド
CAP_SYS_PTRACE // 他のプロセスの ptrace
CAP_KILL // 他のユーザーのプロセスへのシグナル送信
// ... 40以上のキャパビリティ
// コンテナセキュリティの重要ポイント:
// docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE
// → コンテナ内の root はポートバインドのみ可能、モジュールの読み込みは不可
```
## IMA/EVM: ファイル整合性
```
IMA (Integrity Measurement Architecture):
測定: ファイルが読み込まれるたびにハッシュを計算 → TPM に記録
評価: ファイルハッシュを検証 → 改ざんされたファイルを拒否
EVM (Extended Verification Module):
ファイルのメタデータ (xattr, モード, オーナー) が改ざんされないよう保護
HMAC (TPM キー使用) またはデジタル署名に基づく
```
## デバッグ
```bash
# SELinux
getenforce
ausearch -m avc --start recent # 最近の拒否イベント
sealert -a /var/log/audit/audit.log # 拒否理由の分析
# AppArmor
aa-status
cat /proc//attr/apparmor/current
# キャパビリティ
capsh --print # 現在のシェルが持つキャパビリティ
getpcaps
```
## 参考
- **ソースコード**: `security/` (lsm, selinux, apparmor, smack, integrity)、`include/linux/lsm_hooks.h`
- **カーネルドキュメント**: `Documentation/admin-guide/LSM/`
- **LWN**: 「The LSM hook interface」、「BPF LSM」
*キーワード: LSM, SELinux, AppArmor, BPF LSM, キャパビリティ, IMA, EVM, 型強制, AVC*