3. 强制访问控制（MAC）：Bell-LaPadula 模型原理归纳总结
说到强制访问控制，很多人第一反应就是「高机密不能读到低机密」——嗯，这句话只对了一半。Bell-LaPadula 模型（简称 BLP）是 MAC 里最经典的一个，它解决的是「保密性」问题，不是完整性。我最早接触这个模型是在做政府项目的时候，甲方要求所有数据必须打标签，读写规则严格按安全级走。当时我就琢磨：这不就是操作系统里的多级安全吗？
说白了，BLP 模型就是一套数学化的规则集合。它用「主体」对「客体」的访问方式，加上安全级别的比较，来决定你能不能读、能不能写。你不需要记住那些复杂的符号，把两条核心规则吃透就够了。
3.1 模型核心概念
先搭个公共的认知框架。BLP 里有三样东西你得先记住：
- 主体（Subject）：活动的实体，比如进程、用户线程。它有一个安全级别。
- 客体（Object）：被动的实体，比如文件、数据库记录。它也有一个安全级别。
- 安全级别（Security Level）：一个二元组 (密级, 范畴)。密级如 绝密 > 机密 > 秘密 > 公开；范畴就是部门或者项目组。
密级是偏序的，可以比较大小。范畴是集合，用包含关系判断。两个安全级别比较的时候，密级必须大于等于，范畴必须包含——这就是「支配（dominate）」的概念。举个例子：(绝密, {A, B}) 支配 (机密, {A})，但 (绝密, {A}) 不支配 (机密, {B})，因为范畴没包含。
我的一点经验：刚开始做审计的时候，我老把「范畴」当成简单的分组。后来发现部门和项目的组合经常有重叠，比如同一个文件同时属于「核物理组」和「高能物理组」，你的主体如果只属于其中一个，即使密级够了也访问不了。所以审计标签必须检查范畴的集合包含关系，不能只看密级。
3.2 两条核心规则：不能向上读，不能向下写
BLP 模型定义了两条强制规则，这是整个模型的心脏：
- 简单安全属性（Simple Security Property）：主体只能读安全级别 ≤ 主体级别（支配它）的客体。简单说——不能向上读。
- *-属性（Star Property）：主体只能写安全级别 ≥ 主体级别（被它支配）的客体。简单说——不能向下写。
这俩规则加在一起，就保证了信息只能从低安全级流向高安全级，永远不会往下漏。你想想：一个低级别的用户不能读高级别的文件，也不能把高级别文件的内容通过写操作传给更低级别的用户——因为向下写被禁止了。
| 主体安全级 | 客体安全级 | 读操作 | 写操作 |
|---|---|---|---|
| 机密 | 公开 | 允许（公开 ≤ 机密） | 允许（公开 ≤ 机密，向下写不违反？注意：这里是主体>客体，向下写的规则禁止写更低级别，所以写允许吗？不，BLP 的 *-属性要求主体只能写 ≥ 自身的级别。机密主体写公开客体：客体级别 公开 < 主体级别 机密，违反 *-属性，禁止！） |
| 机密 | 绝密 | 禁止（绝密 > 机密，不能向上读） | 允许（绝密 ≥ 机密，允许写） |
| 绝密 | 公开 | 允许（公开 ≤ 绝密） | 禁止（公开 < 绝密，不能向下写） |
| 绝密 | 绝密 | 允许（相等） | 允许（相等） |
注意上面的第一行：机密主体读公开客体是允许的，但写公开客体是禁止的。这跟很多人的直觉不同——能读低密级，但不能往低密级里写。原因很简单：如果你能向下写，你就能把高级信息通过写操作「降级」泄密出去。
我曾经踩过的一个坑：审计一个 Linux 的 SELinux 策略时，发现有一条规则允许某个高安全级进程向一个公共目录写日志。表面上只是写个日志，对吧？但那个公共目录可以被低安全级用户读取。进程如果无意中把机密信息夹在日志里，就等于开了一个后门。我当时就意识到：BLP 的向下写禁止不只是在文件系统层面，在进程间通信、管道、共享内存上也必须检查。
3.3 模型扩展与安全级变换
实际系统里很少直接用一个静态的安全级别。你会发现有些操作需要临时提升权限，或者在不同安全级之间传递消息。BLP 模型后来有了几个常见扩展：
- 多级安全（MLS）：把 BLP 的规则直接实现到操作系统层面，比如 SELinux、Trusted Solaris。每个进程和文件都要带安全标签。
- 可信主体：某些系统进程（比如安全管理员）可以不受 *-属性约束，它们被标记为「可信主体」。但这个权限要严格控制，我见过有的项目给太多进程加了可信标签，结果 MAC 形同虚设。
- 安全级变换：在写操作时允许将客体的安全级别改成与主体相同的级别，或者创建新客体时继承主体级别。这个在数据库中很常见——插入一条记录，它的密级默认等于插入者的密级。
另外还要提一点：BLP 不保证完整性。它只管保密性，不管数据有没有被篡改。如果你需要同时保证保密和完整性，那得结合 Biba 模型或者 Clark-Wilson 模型，我后面章节会讲。
3.4 BLP 模型的知识结构图
3.5 审计时你该怎么检查 BLP 完整性
讲完理论，咱们看看审计实战。我个人在审计时，会按下面四个步骤检查 BLP 的落地情况：
- 标签体系是否完整：所有主体和客体有没有挂上安全标签？有没有未标记的进程或文件？我发现很多系统里「system」进程没标签，结果它啥都能读，MAC 形同虚设。
- 读规则是否正确：测试一下低密级主体能否访问高密级客体。用自动化脚本遍历文件系统，检查所有读操作是否都通过了支配检查。
- 写规则是否严格：特别注意那些「写操作」——高密级主体不能往低密级客体里写。我惯用做法：开一个高密级进程，尝试向低密级目录写文件，系统应该直接拒绝。
- 可信主体清单：看看系统中哪些进程被标记为「可信主体」。如果有超过 3 个，基本就有问题。理想情况下，只能有安全监控进程、审计进程等极少数核心进程拥有免检权限。
避坑指南：我曾经审计过一个云平台的多租户系统，他们把 BLP 模型用在租户隔离上。结果发现某个租户的虚拟机可以执行 dmesg 读取宿主机内核日志——因为 dmesg 的客体安全级被错误地设成了「公开」。这就是标签打错导致的泄漏。所以审计时必须手工检查每个系统调用和设备的标签配置，不能只跑自动化工具。
3.6 BLP 的局限与扩展
最后说两句它的短板，免得你觉得这模型万能。
- 不防完整性：高密级主体可以篡改低密级客体的数据（虽然不能写，但可以删除或修改？注意：BLP 的写操作通常包括修改和删除，如果允许高密级主体写低密级客体，但 *-属性禁止向下写，所以高密级不能修改低密级。但有些实现把「删除」视为独立操作，可能绕过。这个要具体看系统实现。实际上 BLP 没有涵盖完整性，比如一个高密级病毒可以感染一个低密级文件，因为低密级文件可以被高密级主体读（读没问题），但写不行。所以一般要结合 Biba 使用。
- 不处理隐蔽信道：利用共享资源（比如时间、锁、错误信息）来传递信息，BLP 管不了。正规的 MAC 审计还要做隐蔽信道分析，但这超出本章范围了。
- 管理负担大：每个客体都要分配安全级，大型系统里标签维护非常痛苦。我见过有的团队干脆把全部文件都标成同一级别，MAC 直接变成 DAC。
讲到底，BLP 是一个优雅的数学模型，但真正落地的时候你会发现，现实比公式复杂得多。你只有把标签体系、规则检查、可信主体控制都做到位，才能真正守住保密性这条线。