4. 强制访问控制
强制访问控制（Mandatory Access Control, MAC）是一种由系统强制实施、用户无法自行修改的访问控制策略。与自主访问控制（DAC）不同，MAC 中所有主体（进程/用户）和客体（文件/资源）都被分配了固定的安全属性，访问决策完全由系统根据预定义的安全策略规则判定，用户无权转让或修改权限。MAC 的核心在于“强制”二字——即使文件的所有者也不能随意改变其安全级别。
4.1 MAC 模型基本原理
MAC 模型建立在以下核心概念之上：
- 安全标签（Security Label）：每个主体和客体都被分配一个不可篡改的安全标签，通常包含密级（如绝密、机密、秘密、公开）和范畴（如项目A、部门B）。
- 安全策略（Security Policy）：系统内核强制执行的一组规则，决定主体能否访问客体。
- 参考监视器（Reference Monitor）：负责拦截所有访问请求并依据安全策略进行裁决的抽象机制。
关键特性：MAC 策略是全局性的、系统级的，用户无法绕过或修改。即使进程被恶意代码控制，也无法突破 MAC 规则的限制，因此 MAC 在对抗木马和权限提升攻击方面具有天然优势。
工程提示：在工程分析平台中，MAC 常用于隔离不同客户的项目数据（多租户场景）或保护核心算法模型不被低权限用户读取。
4.2 BLP 模型（Bell-LaPadula Model）
BLP 模型是第一个形式化的 MAC 模型，由 David Bell 和 Leonard LaPadula 于 1973 年提出，主要目标是保护数据的机密性（Confidentiality），防止信息从高安全级别流向低安全级别。
4.2.1 核心规则
| 规则名称 | 描述 | 通俗理解 |
|---|---|---|
| 简单安全属性（SS-Property） | 主体只能读取安全级别 ≤ 自身级别的客体（No Read Up） | 低级别用户不能读取高级别文件 |
| 星属性（*-Property） | 主体只能写入安全级别 ≥ 自身级别的客体（No Write Down） | 高级别用户不能将数据写入低级别文件 |
| 强星属性（Strong *-Property） | 主体只能写入安全级别 = 自身级别的客体 | 更严格的写限制，防止间接泄露 |
BLP 模型通过“不上读、不下写”的规则组合，确保信息只能向上流动或平级流动，无法向下泄露。
局限性：BLP 模型只关注机密性，不关注完整性。一个高级别进程可能向低级别客体写入垃圾数据，破坏数据完整性。此外，BLP 无法有效防御隐蔽信道（Covert Channel）攻击。
4.2.2 BLP 模型访问控制流程
4.3 Biba 模型（Biba Integrity Model）
Biba 模型由 Kenneth Biba 于 1977 年提出，与 BLP 模型对称，主要目标是保护数据的完整性（Integrity），防止信息从低完整性级别流向高完整性级别。
4.3.1 核心规则
| 规则名称 | 描述 | 通俗理解 |
|---|---|---|
| 简单完整性属性（SI-Property） | 主体只能读取完整性级别 ≥ 自身级别的客体（No Read Down） | 高完整性进程不能读取低完整性数据 |
| 星完整性属性（*-Integrity Property） | 主体只能写入完整性级别 ≤ 自身级别的客体（No Write Up） | 低完整性进程不能写入高完整性文件 |
Biba 模型通过“不下读、不上写”的规则组合，确保高完整性数据不会被低完整性数据污染。
BLP vs Biba 对比：
- BLP：保护机密性，防止高密级信息泄露到低密级。规则：不上读、不下写。
- Biba：保护完整性，防止低完整性数据污染高完整性数据。规则：不下读、不上写。
4.4 多级安全（Multi-Level Security, MLS）
多级安全（MLS）是 MAC 模型在实际系统中的应用实现，它将主体和客体划分为多个安全级别，并强制实施跨级别的访问控制策略。MLS 系统通常支持以下安全级别（从低到高）：
- 公开（Unclassified）：最低级别，可自由访问。
- 秘密（Confidential）：需要授权才能访问。
- 机密（Secret）：较高敏感度。
- 绝密（Top Secret）：最高敏感度。
4.4.1 多级安全架构
4.4.2 MLS 在工程分析平台中的应用场景
| 场景 | 安全级别划分 | MAC 策略 |
|---|---|---|
| 多租户数据隔离 | 租户A（机密）、租户B（秘密）、公共数据（公开） | BLP：租户A不能读取租户B数据；Biba：租户B不能污染租户A数据 |
| 核心算法保护 | 算法模型（绝密）、训练数据（机密）、日志（公开） | BLP：低权限用户不能读取模型；Biba：日志不能写入模型目录 |
| 合规审计数据 | 审计日志（机密）、操作记录（秘密）、系统事件（公开） | BLP：审计员可读所有级别；Biba：普通用户不能修改审计日志 |
4.5 MAC 模型的工程落地要点
- 安全标签管理：所有主体和客体在创建时必须分配安全标签，且标签必须由可信组件（如安全内核）维护，防止篡改。
- 策略组合：实际系统通常需要同时满足机密性和完整性要求，可采用 BLP + Biba 组合策略，或使用更现代的 SELinux 类型强制（TE）策略。
- 性能影响：每次访问都需经过参考监视器裁决，可能带来性能开销。工程中需优化规则匹配算法，或使用缓存机制。
- 隐蔽信道防御：MAC 模型无法完全防御隐蔽信道（如通过时序、资源占用传递信息），需结合其他安全机制。
工程避坑：不要试图在用户态实现 MAC 策略——用户态代码可以被绕过或篡改。MAC 必须在内核层面或通过硬件安全模块（如 TPM、ARM TrustZone）实现，才能保证“强制”特性。