DAC与MAC是分层协作关系：MAC为不可绕过的安全底线，优先校验；DAC为日常灵活授权工具，在MAC允许范围内生效；二者协同实现可用性与安全性的统一。

DAC 和 MAC 不是互斥选项，而是分层协作的关系：DAC 负责日常灵活授权，MAC 提供底层强制约束。实际部署中，二者必须配合使用才能兼顾可用性与安全性。

DAC 是权限落地的日常工具

DAC（自主访问控制）让文件所有者或管理员能直接设置 NTFS 或 Linux 文件系统的 rwx 权限，支持用户、组、其他三类主体，操作直观、响应迅速。

• Windows 中通过“属性 → 安全”页添加用户/组并勾选“读取”“修改”等 ACE，本质就是写入 DACL
• Linux 中用 chmod 644 file 或 chown user:group file 即完成 DAC 级别授权
• 它适合快速响应业务需求，比如临时开放某个日志目录给运维组读取

MAC 是不可绕过的安全底线

MAC（强制访问控制）不依赖用户意愿，由系统策略统一执行。一旦触发，DAC 授权自动失效——这就是为什么普通用户即使拥有 secpol.msc 的完全 NTFS 权限，仍无法打开本地安全策略编辑器。

• Windows 中体现为完整性级别（Low/Medium/High/System）、Mandatory Label、SePrivileges 等内核级标记
• Linux 中典型实现是 SELinux 或 AppArmor，通过策略规则限制进程能访问哪些文件、端口、IPC 资源
• Android 11 后全面启用 MAC，每个应用运行在独立沙箱中，即使获得 root 也受 domain 约束

关键协同点：先过 MAC，再验 DAC

系统检查权限时严格遵循“MAC 优先”原则。一个访问请求必须同时满足两层校验：

• 第一步：确认主体（如进程）是否具备访问客体（如配置文件）所需的完整性标签或 SELinux type
• 第二步：在 MAC 允许范围内，再比对 DACL 或文件 mode 位，判断该主体是否有对应读/写/执行权
• 任一环节失败，访问即被拒绝。例如：某服务进程被标记为 unconfined_u:unconfined_r:unconfined_t，但目标文件要求 system_u:object_r:etc_t，即便 chmod 777 也无用

运维建议：按场景选择主控层级

不必强行统一用 MAC 管一切，应根据资产敏感度分级施策：

• 核心系统文件（/etc/shadow、注册表安全策略、数据库配置）——启用 MAC 策略锁定，禁用 DAC 修改能力
• 业务数据目录（如 /var/www/html、共享报表文件夹）——以 DAC 为主，辅以 MAC 标记防止越权进程读取
• 开发测试环境——可暂关 MAC（如 setenforce 0），但生产环境必须开启并定期审计 avc denied 日志