第3章: アクセス制御理論と権限管理 - マルチユーザーシステムの計算機科学的基盤
3.1 マルチユーザーシステムの歴史的発展
バッチ処理からタイムシェアリングへ
1950年代の計算機は単一ユーザーシステムでした。高価な計算資源を効率的に使用するため、ジョブをバッチ処理で順次実行していました。しかし、この方式では対話的な作業ができず、プログラマはパンチカードを提出して結果を待つ必要がありました。
1959年、MITのJohn McCarthyはタイムシェアリングの概念を提唱しました。複数のユーザーが同時に計算機を使用し、CPUタイムを細かく分割して各ユーザーに割り当てるという革新的なアイデアです。
> "タイムシェアリングは、ユーティリティとしての計算を可能にする。電力会社が電気を供給するように、計算サービスを提供できる。" — John McCarthy, 1961
CTSS: 最初の実用的マルチユーザーシステム
1961年から1963年にかけて、MITでCTSS（Compatible Time-Sharing System）が開発されました。Fernando Corbató率いるチームは、IBM 7090/7094上で最大30人のユーザーが同時に対話的に作業できるシステムを実現しました。
CTSSはマルチユーザー保護の原点となる重要な概念を導入しました：
- ユーザー識別（User Identification）: 各ユーザーに一意の識別子を割り当て
- パスワード認証: システムアクセス時の本人確認
- ファイルの所有権: 各ファイルが特定のユーザーに属する
- アクセス制御: ユーザーごとにファイルへのアクセスを制限
Corbatóは1966年にこの業績でチューリング賞を受賞しました。CTSSで確立された概念は、現代のすべてのマルチユーザーOSの基盤となっています。
Multics: セキュリティ工学の先駆け
1964年から開発されたMultics（Multiplexed Information and Computing Service）は、セキュリティを設計の中核に据えた最初の大規模システムでした。MIT、Bell Labs、GEの共同プロジェクトとして、以下の革新的な概念を導入しました：
保護リング（Protection Rings）
Multicsは8層の保護リングを実装し、ハードウェアレベルでの権限分離を実現しました：
リング0: カーネル（最高権限）
↓
リング1: システムサービス
↓
リング2: ユーティリティ
↓
...
↓
リング7: ユーザーアプリケーション（最低権限）
内側のリングのコードは外側のリングにアクセスできますが、逆は明示的なゲートを通じてのみ可能です。この概念は現代のx86プロセッサの保護モード（Ring 0-3）に継承されています。
アクセス制御リスト（ACL）
MulticsはACL（Access Control List）を導入しました。各オブジェクト（ファイル、セグメント）に対して、どのサブジェクト（ユーザー、プロセス）がどのような操作（読み取り、書き込み、実行）を許可されるかを細かく指定できます：
ファイル: /system/config
ACL:
- user:admin → read, write, execute
- user:operator → read, execute
- group:users → read
- user:guest → (no access)
3.2 アクセス制御の理論的基盤
Lampsonのアクセス制御マトリックス
1969年、Butler Lampsonは論文"Protection"でアクセス制御の数学的モデルを提示しました。このモデルはアクセス制御マトリックス（Access Control Matrix）として知られています。
| ファイルA | ファイルB | プロセスP | デバイスD |
--------------+-----------+-----------+-----------+-----------+
ユーザーAlice | rw | r | own | - |
ユーザーBob | r | rwx | - | rw |
プロセスP | - | r | - | r |
マトリックスの要素：
- 行（Subjects）: 能動的なエンティティ（ユーザー、プロセス）
- 列（Objects）: 受動的なエンティティ（ファイル、デバイス、メモリ）
- セル（Rights）: サブジェクトがオブジェクトに対して持つ権限
Lampsonのモデルは、セキュリティポリシーを形式的に記述し、分析するための基盤を提供しました。
実装アプローチ: ACL vs Capability
アクセス制御マトリックスは概念的なモデルであり、実際のシステムでは2つのアプローチで実装されます：
1. アクセス制御リスト（ACL）: 列ベースの実装
各オブジェクトに、そのオブジェクトにアクセスできるサブジェクトのリストを格納：
ファイルA.acl = [(Alice, rw), (Bob, r)]
ファイルB.acl = [(Alice, r), (Bob, rwx), (ProcessP, r)]
長所:
- オブジェクトの権限を一目で確認できる
- 権限の取り消しが容易
- ファイルシステムで広く採用
2. ケイパビリティ（Capability）: 行ベースの実装
各サブジェクトに、アクセス可能なオブジェクトへの参照（ケイパビリティ）を格納：
Alice.capabilities = [(ファイルA, rw), (ファイルB, r), (プロセスP, own)]
Bob.capabilities = [(ファイルA, r), (ファイルB, rwx), (デバイスD, rw)]
長所:
- 権限の委譲が自然
- 分散システムに適している
- 最小権限の実現が容易
UNIXは主にACLベースのアプローチを採用していますが、ファイル記述子はケイパビリティの一形態と見なすことができます。
DAC vs MAC: 2つのアクセス制御パラダイム
任意アクセス制御（Discretionary Access Control, DAC）
DACでは、オブジェクトの所有者がアクセス権限を決定します。UNIXの伝統的な権限モデルはDACです：
# Aliceがファイルを作成（所有者になる）
touch myfile.txt
# Aliceが権限を設定（所有者の裁量）
chmod 640 myfile.txt # owner:rw, group:r, others:none
長所: 柔軟で使いやすい 短所: マルウェアがユーザー権限を悪用可能
強制アクセス制御（Mandatory Access Control, MAC）
MACでは、システム全体のポリシーがアクセスを決定し、ユーザーはこれを変更できません。軍事・政府システムで採用されています。
セキュリティラベル:
Top Secret > Secret > Confidential > Unclassified
ルール（Bell-LaPadulaモデル）:
- No Read Up: 自分より高いラベルのデータを読めない
- No Write Down: 自分より低いラベルにデータを書けない
Bell-LaPadulaモデル（1973）は機密性を保護します。David Bell と Leonard LaPadulaがMITRE社で開発しました。
Bibaモデル（1977）は完全性を保護します。Kenneth Bibaが開発し、Bell-LaPadulaの双対として機能します：
- No Read Down: 信頼性の低いデータを読まない
- No Write Up: 信頼性の高いデータを汚染しない
現代のLinuxでは、SELinux（NSA開発）やAppArmorがMACを実装しています。Born2berootのBonusパートで使用するAppArmorもこの系譜に属します。
3.3 UNIX権限モデルの設計と進化
Thompson-RitchieのUNIX権限設計
1969年、Ken ThompsonとDennis RitchieがBell LabsでUNIXを開発した際、Multicsの複雑なセキュリティモデルを大幅に簡略化しました。
UNIXの基本権限モデル：
所有者(u) グループ(g) その他(o)
-------- ---------- --------
rwx rwx rwx
421 421 421
例: 755 = rwxr-xr-x
7 = 4+2+1 = rwx (owner)
5 = 4+0+1 = r-x (group)
5 = 4+0+1 = r-x (others)
3種類の権限：
- r（read, 4）: ファイル読み取り / ディレクトリ一覧
- w（write, 2）: ファイル書き込み / ディレクトリ内ファイル作成・削除
- x（execute, 1）: ファイル実行 / ディレクトリへのアクセス
3種類のユーザーカテゴリ：
- 所有者（owner）: ファイルを作成したユーザー
- グループ（group）: ファイルのグループに属するユーザー
- その他（others）: 上記以外の全ユーザー
この「3x3モデル」は、Multicsの複雑なACLに比べて単純ですが、ほとんどの実用的なケースをカバーできます。
ユーザーとグループの識別子
UNIXは数値識別子を使用してユーザーとグループを管理します：
UID（User ID）：
0 : root（スーパーユーザー）
1-999 : システムユーザー（デーモン用）
1000+ : 通常ユーザー
65534 : nobody（最小権限ユーザー）
GID（Group ID）：
0 : root/wheel グループ
1-999 : システムグループ
1000+ : ユーザーグループ
設計上の考察：
- UID 0は特別扱いされ、すべての権限チェックをバイパス
- これはフェイルセーフ設計ではなく、rootが必要な理由
- 現代の「最小権限の原則」に反するが、歴史的経緯から維持
/etc/passwd と /etc/shadow の分離
初期のUNIXでは、パスワードハッシュは/etc/passwdに格納されていました：
# 初期のUNIX /etc/passwd フォーマット
alice:$1$abc$xyz:1000:1000:Alice:/home/alice:/bin/bash
しかし、/etc/passwdは全ユーザーが読み取り可能である必要があります（ls -lなどがユーザー名を表示するため）。これはセキュリティ上の問題でした。
1988年、シャドウパスワードが導入され、パスワードハッシュは/etc/shadowに分離されました：
# /etc/passwd（全ユーザー読み取り可能）
alice:x:1000:1000:Alice:/home/alice:/bin/bash
# /etc/shadow（rootのみ読み取り可能）
alice:$6$rounds=5000$salt$hash:19000:0:99999:7:::
/etc/shadowのフィールド：
- ユーザー名
- パスワードハッシュ（$アルゴリズム$ソルト$ハッシュ）
- 最終パスワード変更日（1970年1月1日からの日数）
- パスワード変更可能になるまでの最小日数
- パスワードの最大有効日数
- 警告日数（期限切れ前）
- 非活性期間
- アカウント有効期限
パスワードハッシュの進化
UNIXパスワードのハッシュアルゴリズムは、計算能力の向上に伴い進化してきました：
1. DES crypt（1976-1990年代）
$フォーマットなし: DES (Data Encryption Standard) ベース
最大8文字、56ビット鍵
例: "ab12CD34" → "abXYZ123def"
2. MD5 crypt（1990年代-2000年代）
$1$salt$hash
例: $1$abc123$5XY/Z9abc...
より長いパスワード対応、1000回反復
3. SHA-256/SHA-512 crypt（2000年代-現在）
$5$ : SHA-256
$6$ : SHA-512
例: $6$rounds=5000$salt$hash...
設定可能な反復回数
4. Argon2（2015年-最新推奨）
$argon2id$v=19$m=65536,t=3,p=4$salt$hash
メモリハード関数、GPU攻撃に強い
/etc/login.defsでデフォルトアルゴリズムを設定できます：
# Debian/Ubuntu デフォルト
ENCRYPT_METHOD SHA512
SHA_CRYPT_MIN_ROUNDS 5000
3.4 特権昇格とsudoアーキテクチャ
setuidビットと特権昇格
UNIXには、一般ユーザーがプログラム実行時に一時的に異なる権限を得る仕組みがあります。
setuid（Set User ID）ビット：
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Apr 16 11:34 /usr/bin/passwd
^
setuidビット（sがxの代わり）
passwdコマンドはsetuidが設定されているため、一般ユーザーが実行してもroot権限で動作します。これにより、/etc/shadowを更新できます。
プロセスの3つのUID：
struct credentials {
uid_t real_uid; // 実UID: 実際のユーザー
uid_t effective_uid; // 実効UID: 権限チェックに使用
uid_t saved_uid; // 保存UID: 権限の一時的な放棄と復元
};
setuidプログラムを実行すると：
real_uid= 実行したユーザーeffective_uid= ファイルの所有者（root）saved_uid= ファイルの所有者（root）
プログラムは必要に応じて権限を放棄・復元できます：
// root権限を一時的に放棄
seteuid(getuid());
// 必要な時だけroot権限を復元
seteuid(saved_uid);
sudoの歴史と設計思想
1980年、ニューヨーク州立大学バッファロー校で、Bob CoggeshallとCliff Spencerがsudo（superuser do）を開発しました。
従来のsu（substitute user）の問題：
# suはroot パスワードの共有が必要
su -
Password: [rootパスワード]
# 複数の管理者がrootパスワードを知ってしまう
# 誰が何をしたか追跡できない
# パスワード変更時に全員に通知が必要
sudoの革新：
# sudoは個人のパスワードを使用
sudo apt update
[sudo] password for alice: [aliceのパスワード]
# メリット:
# - 各管理者は自分のパスワードを使用
# - すべての操作がログに記録
# - 細かい権限制御が可能
# - パスワードの集中管理不要
Saltzer-Schroederの設計原則
1975年、Jerome SaltzerとMichael Schroederは論文"The Protection of Information in Computer Systems"で、セキュアシステム設計の8原則を提示しました。sudoはこれらの原則を体現しています：
1. 最小権限の原則（Principle of Least Privilege）
各プログラムとユーザーは、タスクを完了するのに
必要な最小限の権限のみを持つべきである。
sudoは必要な時だけ、必要な権限のみを付与します：
# rootになる代わりに、特定のコマンドだけ許可
alice ALL=(ALL) /usr/bin/apt, /usr/bin/systemctl
# aliceはaptとsystemctlのみroot権限で実行可能
# 他のすべてのコマンドは通常権限
2. 完全仲介の原則（Principle of Complete Mediation）
すべてのアクセスは、毎回許可をチェックすべきである。
sudoは各コマンド実行時に権限をチェックし、ログに記録します：
sudo apt update
# チェック: aliceはaptを実行できるか？
# チェック: パスワードは正しいか？
# ログ記録: Dec 7 15:30:45 alice : COMMAND=/usr/bin/apt update
3. フェイルセーフデフォルトの原則
デフォルトは「拒否」であるべき。
明示的に許可されたアクセスのみ許可する。
sudoersのデフォルトは何も許可しません。明示的なルールが必要です。
sudoersファイルの文法
sudoersファイルはExtended Backus-Naur Form（EBNF）で定義された文法に従います：
# 基本形式
user host = (runas) commands
# 例の解説
alice ALL = (ALL) ALL
│ │ │ │
│ │ │ └── 実行可能なコマンド（ALL = すべて）
│ │ └──────── 実行時のユーザー（ALL = 任意のユーザーとして）
│ └────────────── 適用するホスト（ALL = すべてのホスト）
└──────────────────── ユーザー名
高度な設定例：
# グループ指定（%プレフィックス）
%sudo ALL = (ALL) ALL
# パスワードなしでの実行
alice ALL = (ALL) NOPASSWD: /usr/bin/systemctl restart nginx
# 特定コマンドの禁止
bob ALL = (ALL) ALL, !/usr/bin/su, !/usr/bin/bash
# コマンドエイリアス
Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping
alice ALL = (root) NETWORKING
3.5 PAM: 認証フレームワーク
PAMの歴史と設計
1995年、Sun MicrosystemsはPAM（Pluggable Authentication Modules）を開発しました。これにより、認証方法をアプリケーションから分離できます。
PAM以前の問題：
login → 独自の認証コード
passwd → 独自の認証コード
su → 独自の認証コード
sudo → 独自の認証コード
sshd → 独自の認証コード
問題: 各アプリケーションが認証を再実装
新しい認証方法の追加が困難
セキュリティ修正が分散
PAMによる解決：
┌─── pam_unix.so（パスワード認証）
│
login ─────┐ ├─── pam_ldap.so（LDAP認証）
passwd ────┼── PAM ───┤
su ────────┤ ├─── pam_google_authenticator.so（2FA）
sudo ──────┤ │
sshd ──────┘ └─── pam_pwquality.so（パスワード品質）
PAMの4つのモジュールタイプ
PAMは認証プロセスを4つのフェーズに分割します：
1. auth（認証） ユーザーの身元を確認：
# /etc/pam.d/common-auth
auth required pam_unix.so nullok_secure
2. account（アカウント） アカウントの状態を確認（有効期限、ログイン制限など）：
# /etc/pam.d/common-account
account required pam_unix.so
3. password（パスワード） パスワード変更時の処理：
# /etc/pam.d/common-password
password requisite pam_pwquality.so retry=3
password required pam_unix.so sha512 shadow
4. session（セッション） ログイン/ログアウト時の処理：
# /etc/pam.d/common-session
session required pam_limits.so
session required pam_unix.so
制御フラグ
各PAMモジュールには制御フラグがあります：
| フラグ | 意味 | |--------|------| | required | 必須。失敗しても他のモジュールを続行 | | requisite | 必須。失敗したら即座に拒否 | | sufficient | 成功したら認証完了。失敗しても続行 | | optional | 無視可能。他に成功/失敗がなければ参照 |
# 例: 2段階認証の設定
auth required pam_unix.so # パスワード必須
auth required pam_google_authenticator.so # OTP必須
# 両方成功しないとログインできない
3.6 監査とアカウンタビリティ
セキュリティログの理論
アカウンタビリティ（説明責任）は情報セキュリティの三要素（CIA）を補完する重要な概念です：
CIA + A:
- Confidentiality（機密性）
- Integrity（完全性）
- Availability（可用性）
- Accountability（説明責任）← セキュリティ監査の基盤
アカウンタビリティにより：
- 誰が、いつ、何をしたかを追跡できる
- 不正行為の抑止力となる
- インシデント発生時の調査が可能
- コンプライアンス要件を満たせる
syslog: UNIXログシステム
1980年代、Eric Allmanがsyslogを開発しました。これはUNIX系システムの標準ログフレームワークとなっています。
syslogの構造：
ファシリティ（施設） × 優先度（重要度）
│ │
│ ├── emerg (0) 緊急
├── auth ├── alert (1) 警報
├── authpriv ├── crit (2) 重大
├── cron ├── err (3) エラー
├── daemon ├── warning (4) 警告
├── kern ├── notice (5) 通知
├── mail ├── info (6) 情報
├── user └── debug (7) デバッグ
└── local0-7
設定例（/etc/rsyslog.conf）：
# 認証ログを専用ファイルに
auth,authpriv.* /var/log/auth.log
# すべてのエラー以上をsyslogに
*.err /var/log/syslog
# カーネルメッセージ
kern.* /var/log/kern.log
sudo監査ログ
sudoは詳細な監査ログを生成できます：
基本ログ（syslog経由）：
Dec 7 15:30:45 server sudo: alice : TTY=pts/0 ; PWD=/home/alice ;
USER=root ; COMMAND=/usr/bin/apt update
I/Oログ（入出力の完全記録）：
# /etc/sudoers
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
# 記録の再生
sudoreplay -l user alice
sudoreplay /var/log/sudo-io/00/00/01
I/Oログにより、管理者がsudoで実行したすべてのコマンドと出力を後から再生できます。これはセキュリティ監査と教育に非常に有用です。
---
3.7 Born2berootユーザー管理の実装
理論的基盤を理解したところで、Born2berootプロジェクトの要件を実装します。
ユーザーの種類と識別
LinuxはUID（User ID）でユーザーを識別します。第3.3節で説明した設計に基づき：
# ユーザー情報の確認
cat /etc/passwd
# フォーマット: username:x:UID:GID:comment:home_dir:shell
# 現在のユーザー情報
id
# 出力例: uid=1000(username) gid=1000(username) groups=1000(username),27(sudo)
# すべてのログインユーザー
who
ユーザーの分類：
- UID 0: root（特権ユーザー）
- UID 1-999: システムユーザー（デーモン用、ログイン不可）
- UID 1000+: 通常ユーザー（人間が使用）
新規ユーザーの作成
Born2berootでは、評価時に新しいユーザーを作成する能力を示す必要があります。
# adduserコマンド（Debian推奨 - 対話式）
sudo adduser newuser
# 実行すると以下が行われる:
# 1. 新しいユーザーアカウント作成
# 2. 専用グループ作成（ユーザー名と同じ）
# 3. ホームディレクトリ作成（/home/newuser）
# 4. /etc/skelからデフォルトファイルをコピー
# 5. パスワード設定
# 6. ユーザー情報入力
# useraddコマンド（低レベル - 手動オプション指定）
sudo useradd -m -s /bin/bash -c "New User" newuser
# -m: ホームディレクトリ作成
# -s: デフォルトシェル指定
# -c: コメント（フルネーム）
# パスワードは別途設定
sudo passwd newuser
グループ管理
Born2berootではuser42グループの作成が要求されます。
# グループ作成
sudo groupadd user42
# 確認
getent group user42
# 出力: user42:x:1042:
# ユーザーをグループに追加
sudo usermod -aG user42 username
# -a: append（追加）- これを忘れると他のグループから削除される
# -G: supplementary groups（副グループ）
# 確認
groups username
# 出力: username : username sudo user42
# 詳細表示
id username
# 出力: uid=1000(username) gid=1000(username) groups=1000(username),27(sudo),1042(user42)
重要: -aGの-aを忘れると、ユーザーが他のすべてのグループから削除されます。
グループからの削除
# ユーザーを特定のグループから削除
sudo gpasswd -d username groupname
# 出力: Removing user username from group groupname
# 確認
groups username
3.8 Born2berootのsudo厳格設定
第3.4節で説明したSaltzer-Schroederの原則に基づき、Born2berootは厳格なsudo設定を要求します。
sudo設定ファイルの編集
# 必ずvisudoを使用（文法チェック、ロック機能）
sudo visudo
以下の設定を追加します：
# Born2berootプロジェクトのsudo設定
# 1. パスワード試行回数を3回に制限（ブルートフォース対策）
Defaults passwd_tries=3
# 2. パスワードエラー時のカスタムメッセージ
Defaults badpass_message="Wrong password. Please try again."
# 3. sudoコマンドの監査ログ
Defaults logfile="/var/log/sudo/sudo.log"
Defaults log_input
Defaults log_output
Defaults iolog_dir="/var/log/sudo"
# 4. TTYモード要求（スクリプト経由の悪用防止）
Defaults requiretty
# 5. セキュアパスの設定（PATH injection攻撃防止）
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
各設定の意味
passwd_tries=3
パスワード試行回数を制限。3回失敗するとsudoは終了。ブルートフォース攻撃への対策。
sudo ls
# わざと間違えて3回入力
# 出力: sudo: 3 incorrect password attempts
log_input/log_output
第3.6節で説明したI/Oログを有効化。入出力の完全な監査証跡を記録。
# ログディレクトリの作成
sudo mkdir -p /var/log/sudo
sudo chmod 750 /var/log/sudo
requiretty
TTY（端末）からのみsudo実行を許可。リモート攻撃やスクリプト経由の悪用を防止。
注意: この設定により、cronからsudoを使用できなくなります。monitoring.shはrootのcronで実行する必要があります。
secure_path
sudo実行時のPATH環境変数を固定。攻撃者がPATHを操作して悪意のあるプログラムを実行することを防止。
ログ確認
# sudo使用履歴
sudo cat /var/log/sudo/sudo.log
# 最新のログを継続表示
sudo tail -f /var/log/sudo/sudo.log
# sudo実行回数のカウント
sudo grep -c 'COMMAND' /var/log/sudo/sudo.log
3.9 実践演習
評価シナリオ1: ユーザー作成とグループ追加
# 1. 新しいユーザーを作成
sudo adduser evaluator
# 2. user42グループを作成（必要な場合）
sudo groupadd user42
# 3. ユーザーをuser42グループに追加
sudo usermod -aG user42 evaluator
# 4. ユーザーをsudoグループに追加
sudo usermod -aG sudo evaluator
# 5. 確認
groups evaluator
# 出力: evaluator : evaluator sudo user42
評価シナリオ2: グループメンバーシップ変更
# 1. 現在のグループを確認
groups username
# 2. user42グループから削除
sudo gpasswd -d username user42
# 3. 確認
groups username
# "user42"が表示されないことを確認
# 4. 再度追加
sudo usermod -aG user42 username
# 5. 確認
groups username
# "user42"が表示されることを確認
評価シナリオ3: sudoログの確認
# 1. sudoコマンドを数回実行
sudo apt update
sudo systemctl status ssh
sudo cat /etc/passwd
# 2. sudoログを確認
sudo cat /var/log/sudo/sudo.log
# 3. sudo実行回数をカウント
sudo grep -c 'COMMAND' /var/log/sudo/sudo.log
3.10 トラブルシューティング
sudo権限が機能しない
症状：
sudo apt update
# 出力: username is not in the sudoers file. This incident will be reported.
解決：
# rootでログイン
su -
# ユーザーをsudoグループに追加
usermod -aG sudo username
# ログアウト・再ログインで反映
sudoersファイルの文法エラー
症状：
sudo: >>> /etc/sudoers: syntax error near line 25 <<<
sudo: no valid sudoers sources found, quitting
解決：
# suでrootになる
su -
# visudoで修正（自動的に文法チェック）
visudo
予防策: 必ずvisudoを使用する。直接編集しない。
グループ変更が反映されない
原因: 現在のセッションにはグループ変更が反映されない
解決：
# 方法1: 新しいグループでシェルを開始
newgrp groupname
# 方法2: ログアウト・再ログイン
exit
# 方法3: 新しいセッションで確認
su - username
groups
3.11 理論と実践の統合
この章で学んだ概念の関係を整理します：
理論的基盤
├── Lampsonのアクセス制御マトリックス（1969）
│ └── 行×列のアクセス権限モデル
├── DAC/MACの分類
│ └── UNIX = DAC（所有者による裁量的制御）
├── UNIX権限モデル（1969-1971）
│ └── 3x3モデル（user/group/others × rwx）
├── 最小権限の原則（Saltzer-Schroeder, 1975）
│ └── 必要最小限の権限のみ付与
└── PAM認証フレームワーク（1995）
└── 認証のモジュール化
Born2beroot実装
├── ユーザー・グループ管理
│ ├── adduser/useradd
│ ├── groupadd
│ └── usermod -aG
├── sudo厳格設定
│ ├── passwd_tries=3
│ ├── log_input/log_output
│ ├── requiretty
│ └── secure_path
└── 監査ログ
└── /var/log/sudo/sudo.log
3.12 次章への準備
次章ではSSH（Secure Shell）を学びます。SSHは以下の概念を応用します：
- 公開鍵暗号: RSA, Ed25519
- 認証プロトコル: パスワード認証 vs 公開鍵認証
- セキュアチャネル: 暗号化された通信路
- ポートフォワーディング: トンネリング
次章に進む前に、現在の状態のスナップショットを作成してください：
# 仮想マシンをシャットダウン
sudo shutdown -h now
# ホストマシンでスナップショット作成
VBoxManage snapshot "Born2beroot" take "After User and Sudo Config" \
--description "User management and sudo configuration completed"