Linuxセキュリティ機構の原理とDocker設定の必要性
Part 1: 原理 - Linuxのセキュリティレイヤー
ステップ1: Linux Capabilitiesとは
Linuxマニュアルより:
"For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero)." "Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled." — capabilities(7) - Linux Manual Page
重要な設計思想:
伝統的なUNIX:
root (UID=0) → 全ての権限を持つ (危険)
user (UID!=0) → 制限された権限のみ
現代のLinux (Capabilities):
root/user → 細分化された権限 (CAP_XXX) を個別に付与可能
├─ CAP_NET_ADMIN (ネットワーク管理)
├─ CAP_SYS_ADMIN (システム管理)
├─ CAP_SYS_PTRACE (プロセストレース) ← 今回の焦点
└─ ... 他40個以上
ステップ2: CAP_SYS_PTRACEの役割
Linuxマニュアルより:
"CAP_SYS_PTRACE: Trace arbitrary processes using ptrace(2); apply get_robust_list(2) to arbitrary processes; transfer data to or from the memory of arbitrary processes using process_vm_readv(2) and process_vm_writev(2); inspect processes using kcmp(2)." — capabilities(7) - Linux Manual Page
つまり:
CAP_SYS_PTRACEが必要な操作:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. ptrace(2) → 別プロセスのデバッグ
2. get_robust_list(2) → プロセスのロバストミューテックス情報取得
3. process_vm_readv(2) → 別プロセスのメモリ読み取り
4. process_vm_writev(2) → 別プロセスのメモリ書き込み
5. kcmp(2) → プロセス間のリソース比較
ステップ3: Seccompとは
Dockerドキュメントより:
"Secure computing mode (seccomp) is a Linux kernel feature. You can use it to restrict the actions available within the container. The default seccomp profile provides a sane default for running containers with seccomp and disables around 44 system calls out of 300+." — Docker Seccomp Documentation
セキュリティレイヤーの階層:
┌─────────────────────────────────────────────────────────┐
│ アプリケーション (例: GDB, strace) │
└────────────────────┬────────────────────────────────────┘
│ システムコール呼び出し
↓
┌─────────────────────────────────────────────────────────┐
│ Seccomp Layer (システムコールフィルタ) │
│ ──────────────────────────────────────────── │
│ ✓ 許可リスト: open, read, write, ... │
│ ✗ 拒否リスト: ptrace, process_vm_readv, ... │
└────────────────────┬────────────────────────────────────┘
│ 許可されたシステムコールのみ通過
↓
┌─────────────────────────────────────────────────────────┐
│ Capabilities Check (権限チェック) │
│ ──────────────────────────────────── │
│ CAP_SYS_PTRACE が必要か？ │
│ → あり: 許可 │
│ → なし: EPERM (Operation not permitted) │
└────────────────────┬────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────┐
│ Linuxカーネル (実行) │
└─────────────────────────────────────────────────────────┘
ステップ4: Dockerのデフォルトセキュリティ設定
Dockerドキュメントより:
"ptrace - Tracing/profiling syscall, which could leak a lot of information on the host. Blocked in Linux kernel versions before 4.8 to avoid seccomp bypass. Docker's default seccomp profile blocks ptrace syscalls." — Docker Seccomp Documentation
デフォルトで制限される理由:
理由1: セキュリティバイパス
ptrace を使うと seccomp を回避できる可能性
→ 攻撃者が制限を突破できる
理由2: 情報漏洩
他のプロセスをトレースすると、ホスト情報が漏れる
→ コンテナ隔離の破壊
理由3: 権限昇格
root権限プロセスにアタッチして権限を奪取可能
→ 危険性が極めて高い
Part 2: 可視化方法ごとの設定要件
方法1: malloc_info() - 設定不要 ✓
理由の詳細:
// malloc_info() の実装概要 (glibc malloc.c より)
int malloc_info(int options, FILE *fp) {
// 自プロセスのメモリ情報を取得
// arena linked list を辿る
// 各 arena の統計情報を XML 出力
// → 他プロセスへのアクセス不要
return 0;
}
重要な原理:
"malloc_info() operates on the calling process's own memory allocation data structures and does not need to trace or inspect other processes." — 調査結果
必要なシステムコール:
malloc_info() が使用するシステムコール:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✓ fopen/fwrite → ファイル書き込み (許可)
✓ malloc arena走査 → 自プロセス内メモリ (許可)
✗ ptrace → 使用しない
✗ process_vm_read → 使用しない
結論:
✅ --cap-add=SYS_PTRACE: 不要
✅ --security-opt seccomp=unconfined: 不要