dac/cap/lsm

DAC 管基础，CAP 补 DAC，LSM 管全局最终决策。

DAC 先过 → CAP 兜底 → LSM 最后把关

Capability（CAP）：Linux 原生特权拆分机制，不属于 LSM 框架

LSM：内核安全钩子框架，用于实现 MAC（SELinux/AppArmor 等）

DAC（Discretionary Access Control）

本质：主体客体的身份匹配 + 权限位许可，是操作系统最基础的自主权限规则。

• 主体：进程 UID/GID
• 客体：文件 inode 的 UID/GID、rwx、ACL
• 特点：所有者自主决定权限，控制松散。

CAP（Capability）

本质：对 root 特权的细粒度拆分，是 DAC 检查失败时的豁免机制。

• 不是独立权限层，而是DAC 的补丁与兜底
• 让进程不必持有完整 root 即可绕过部分 DAC 限制
• 核心：CAP_DAC_OVERRIDE、CAP_DAC_READ_SEARCH

LSM（Linux Security Module）

本质：内核提供的强制访问控制（MAC）框架钩子，是权限检查的最终防线。

• 提供安全策略扩展接口
• 无论 DAC/CAP 是否通过，LSM 都可最终拒绝
• 实现：SELinux、AppArmor、Landlock 等

核心对比

标准检查顺序（文件访问场景）

开始 ↓ DAC 检查 ├─── 通过 → 去 LSM └─── 失败 → 查 CAP ├─── 有 CAP → 去 LSM └─── 无 CAP → 拒绝 ↓ LSM 检查 ├─── 通过 → 允许 └─── 失败 → 拒绝

前置检查

• 文件系统只读、文件不可变等基础校验（IS_RDONLY/IS_IMMUTABLE）。
• 文件系统自定义权限钩子（如 Ext4 加密）。

DAC 检查（自主访问控制）

• 核心：generic_permission()（fs/namei.c）。
• 流程：
  1. 匹配进程fsuid/gid与文件uid/gid，取出对应权限位（owner/group/other）。
  2. 检查 POSIX ACL（若启用）。
  3. 权限位与操作掩码（mask）匹配校验。
• 结果：DAC 不通过 → 进入 CAP 能力覆盖检查。

CAP 能力覆盖（Capability Override）

• 仅在DAC 失败时触发。
• 关键能力：
  • CAP_DAC_OVERRIDE：完全绕过文件 DAC 检查（读 / 写 / 执行）。
  • CAP_DAC_READ_SEARCH：仅允许目录读 / 搜索，绕过对应 DAC 限制。
• 逻辑：capable_wrt_inode_uidgid(..., CAP_DAC_OVERRIDE)→ 具备则直接通过，返回 0。

LSM 检查（强制访问控制）

• 入口：security_inode_permission()（security/security.c）。
• 触发时机：DAC + CAP 均通过后，才执行 LSM 钩子（如 SELinux/AppArmor）。
• 逻辑：遍历所有注册的 LSM 模块，执行策略检查；任一模块拒绝则返回-EACCES。

完整调用链（以open为例）

sys_openat └── may_open └── inode_permission ├── 文件系统自定义权限（如Ext4） └── __inode_permission ├── do_inode_permission │ ├── generic_permission（DAC） │ │ ├── UID/GID匹配 + 权限位检查 │ │ ├── POSIX ACL检查 │ │ └── 【DAC失败 → 检查CAP_DAC_OVERRIDE】 │ └── 【DAC/CAP通过 → 继续】 └── security_inode_permission（LSM） └── 执行SELinux/AppArmor等策略检查

关键结论

• 顺序固定：DAC 优先 → CAP 覆盖（仅 DAC 失败时） → LSM 最后。
• CAP 是 DAC 的旁路：不是独立检查层，仅用于绕过 DAC 限制。
• LSM 是最终防线：即使 DAC/CAP 都通过，LSM 仍可拒绝访问。
• mmap 例外已修复：内核 3.15+ 统一为 DAC→CAP→LSM 顺序。