强制访问控制（MAC）是由系统按预设安全策略统一实施的权限控制机制，不依赖用户自主授权，而是基于主体与客体的安全标签（等级和区间）强制比对，标签不匹配即拒绝访问，即使管理员或所有者也无法绕过。
服务器权限控制中的 MAC（强制访问控制）不是靠用户自己设权限，而是由系统按预设安全策略统一拦或放。它不看“谁 owns 这个文件”，而看“这个进程/用户有没有对应的安全标签”，标签不匹配就直接拒绝——哪怕你是管理员、是所有者，也绕不过去。
MAC 的核心机制：标签与策略硬绑定
MAC 要求每个主体（如进程、用户会话）和每个对象（如文件、端口、共享目录）都打上安全标签，通常包含两个维度：
- 等级（Level）：比如 Unclassified、Confidential、Secret，代表敏感度高低
- 区间（Category）：比如 Finance、HR、Project-X，代表业务归属或隔离域
系统内核在每次访问时自动比对双方标签。典型规则是：主体只能读取 ≤ 自身等级的对象，且必须覆盖对象的所有区间；写入则常要求等级严格相等、区间完全匹配（防止高密数据“下泄”到低密区）。
Windows 上的 MAC 实现：完整性级别（IL）
Windows 并未全盘照搬军用 MLS 模型，而是用轻量级的完整性级别实现 MAC 思想，主要服务于 IE、Edge、AppContainer 等沙箱场景：
- 进程默认运行在 Medium IL（普通用户程序）
- 系统服务、注册表关键键值、%SystemRoot% 下多数文件标记为 High IL
- IE Protected Mode 或 Edge 安全模式下，渲染进程运行在 Low IL
这意味着：一个 Low IL 进程即使拥有 DAC 的“完全控制”权限，也无法向 High IL 对象写入——系统内核直接拦截，连错误提示都可能被静默丢弃。这是你改了 NTFS 权限却仍无法修改某些系统文件的根本原因。
Linux 上的 MAC 实践：SELinux 与 AppArmor
生产环境最常用的是 SELinux（RHEL/CentOS 默认）和 AppArmor（Ubuntu/Debian 常用），二者都通过策略模块约束进程行为：
-
SELinux 基于类型强制（TE），给每个进程和文件分配 type 标签（如
httpd_t和httpd_sys_content_t），策略定义“哪些 type 可以对哪些 type 执行 read/write/bind 等操作” -
AppArmor 更面向路径，用配置文件声明某个可执行文件（如
/usr/sbin/nginx）能访问哪些路径、打开哪些端口、加载哪些 capability
调试建议：先用 getenforce 查当前模式；遇到访问失败，切到 Permissive 模式并查 ausearch -m avc -ts recent 日志，确认是否为策略拦截——而不是急着关 SELinux。
什么时候该用 MAC，什么时候不必
MAC 不是万能补丁，它解决的是 DAC 无法覆盖的风险点：
- 适合启用 MAC 的场景：处理涉密数据的政务系统、金融核心交易服务、多租户 SaaS 后端隔离、容器化应用的进程边界加固
- 不建议强行套用的场景：内部开发测试服务器、小型 NAS、仅做文件共享的 Windows 工作组环境——此时 DAC + 组策略 + 审计日志已足够
- 特别注意：MAC 策略一旦配置错误，可能导致服务启动失败、用户登录卡死、甚至系统无法引导。上线前务必在克隆环境验证，保留回滚手段（如 SELinux 的
setenforce 0临时降级）
