BLP模型-编程知识

本篇文章是调研了许多资料后对 BLP 模型的一个总结
首发公号：Rand_cs

MLS，Multi-level Security，主要关心的是数据机密性

D. Elliott Bell 和 Leonard J. LaPadula 在 1996 年提出了基本的 BLP 模型，主要有两个性质：

The Simple Security Property states that a subject at a given security level may not read an object at a higher security level.

即 no read up，主体不能够“读”比自己安全级别高的客体，可以向下读以及平级读

The * (Star) Security Property states that a subject at a given security level may not write to any object at a lower security level.

即 no write down，主体不能够“写”比自己安全级别低的客体，可以向上写或平级写

（据说第二条性质叫做 *-property 是因为最开始不知道取什么名字，然后随手写下 *-property，后来也没找到更好的名字，于是这个名字就这样被草率的保留下来）

在这里插入图片描述

MIC，mandatory integrity control，关心的数据的完整性

相关理论模型为 Biba Model，一般来说写操作我们认为是可能会破坏数据的完整性，所以从数据完整性的角度来看，客体只信任级别比它高的主体对它进行写操作，模型中举了一个现实中的例子：将军可以给士兵下达命令，但是反过来不行。

Biba Model 同样也定义了两条规则，与 BLP 完全相反：

The Simple Integrity Property states that a subject at a given level of integrity must not read data at a lower integrity level (no read down).
The * (star) Integrity Property states that a subject at a given level of integrity must not write to data at a higher level of integrity (no write up).

对于完整性级别和安全性级别的关系，在 PitBull 系统中，完整性级别 = 安全性级别

在这里插入图片描述

后来 BLP 模型也考虑一定的数据完整性，对 *-property 这条性质加强，提出 Strong Star Property：主体只能对同级别的客体进行写操作，不再允许向上写。

在这里插入图片描述

而 SELinux 里，没有实现 MIC，但是实现的 MLS 中满足此 Strong Star Property。

上述都是理论模型，想要落地到实践，具体在某个操作系统上实现，只有上述概念不够。最明显的一个例子就是调度器这样的主体，它的功能是分发调度进程，调度需要换出换进所有其他进程的上下文，相当于说调度器需要读写所有安全级别的进程，那么应该给调度器什么安全级别？如果只有上述的概念，给什么级别都不行，给高安全级别，但是它要写低安全级别信息，给低安全级别但它又要读取高安全级别的信息。再者，在现实的系统中，安全级别可能需要动态的变化来保证一定的灵活性，比如说不同级别的用户先后从同一个 tty 登录，那相应的 tty 文件的级别应该也是不一样的，这就需要 tty 的级别动态的变化。

为此，BLP 模型又做了改进，引入了可信主体的概念，就相当于给某个主体开个后门，开放所有权限。

但是又有问题，这个后门开的太大了，直接就放开所有权限，认为此主体完全可信，这是有悖于 principle of least privilege 最小特权原则。在 Linux 的 DAC 模型中，如果需要特权操作直接给 root 权限，也是有悖于最小特权原则，所以有了 capability 将能力细分，有了 MAC 更加精细的进行访问控制。

因此，现实中对一个实体的信任只能在一定范围内，一个可信实体能同时获取所有的特权是不合理的。所以后来对 BLP 模型再做改进，一些需要特权操作的主体只有在指定的范围内是可信的，这样可以把权利非常集中的可信主体变换成权利相对分散的多个部分可信主体，符合最小特权原理。

对于如何实现特权分散，一些官方(Bell 等人、SELinux 等等) 后来一直都没有提出明确公开的理论模型，至少从目前公开的资料来看是这样。但是有相应的概念提出，在 GEMSOS 和 DG/UX 系统的一些手册和论文当中，明确提出了单级实体，多级实体的概念。这里的单级实体就是说主体和客体就一个安全级别标签，多级实体表示主体和客体有多个安全级别标签，可以看做是安全级别范围。网上也有一部分人提出了有关多级实体的理论模型，并提供了相应的数学证明。

总的来说，提出的方案便是多级实体。每个实体的有一个安全级别范围，主体访问客体时安全级别比较有了更大的灵活性。比如说对于某些主体想要进行特权操作(违反 BLP 的两条规则)，现在就可以不用给它完全可信主体的属性，放开所有权限。因为有了级别范围，可以在级别比较时多增加一些判断条件来达到信任只保证在一定范围内的目的。

（另外使用安全级别范围的形式，还可以用来实现 MIC 来保证数据完整性，具体怎么操作待调研）

具体以 SELinux 中对 BLP 模型的实现来说明：

SELinux 中安全上下文的格式如下：

在这里插入图片描述

其中第四部分为安全级别范围，低安全级别表示当前有效的安全级别，高安全级别只有进行特权操作时才会用到。

SELinux 中使用 mlsconstrain 语句检查主体客体的安全级别是否符合 BLP 模型，语法格式如下：

mlsconstrain  class_set  perm_set  expression ;
#expression部分为u r t l h的布尔表达式
#u1, r1, t1, l1, h1 – source user, role and type, low security level, high security level; 
#u2, r2, t2, l2, h2 – target user, role and type, low security level, high security level;

其中 l1 表示主体的低安全级别，h1 表示主体的高安全级别，l2 表示客体的低安全级别，h2 表示客体的高安全级别，t1、t2 分别为主体客体的类型，也可以看做是属性，给主体一个 “部分可信属性” 就是在此部分实现。

在 SELinux 当中，对于安全级别之间的比较有 4 情况，l1 dom l2，表示主体的安全级别大于等于客体的安全级别， l1 domby l2 表示小于等于，l1 eq l2 表示相等，l1 incom l2 表示不相关(本文不涉及)

SELinux 当中对于“读”操作的限制：

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute }(( l1 dom l2 ) or(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or( t1 == mlsfileread ) or( t2 == mlstrustedobject ));

如果 l1 和 l2 表示主体和客体当前有效的安全级别，如果 l1 dom l2，说明主体安全级别高于或等于客体，可以读

否则说明主体安全级别小于客体，表明主体想要进行特权操作了，那么需要客体当前有效的安全级别落在主体的安全级别范围内，即 l1 <= l2 <= h1，另外这个主体还需要 “部分可信主体属性” t1 = mlsfilereadtoclr

上面两条都不满足，如果主体具有 “完整的可信主体读属性”，或者客体具有 “可信客体属性”，那么也允许读。(可信客体这个概念应该是 SELinux 中使用的，其他地方暂时为看见)

SELinux 当中对 “写” 操作的限制：

mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_file } { write create setattr relabelfrom append unlink link rename mounton }(( l1 eq l2 ) or(( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or(( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or( t1 == mlsfilewrite ) or( t2 == mlstrustedobject ));

如果 l1 = l2，说明主体和客体的低安全级别相等，允许写。这里便是实现 strong *-property 的地方，按照最初的 BLP 模型，这里应该是 l1 domby l2 的时候都允许写，但现在加强了，只有主体和客体的安全级别相等的时候才允许写。

如果低安全级别主体想要往高安全级别客体写，即 l1 domby l2(这里其实就是 l1 < l2，没有等于，应为如果有等于，则在 l1 eq l2 的时候便会判断通过了)，说明想要违反 strong *-property，违反完整性规则，那么需要额外条件 h1 dom l2，可以这样理解：因为在完整性规则描述中，高级别可以向低级别进行写操作，所以既然主体的低安全级别已经小于了客体的低安全级别，那么就必须要满足主体的高安全级别大于客体的低安全级别（主体的安全级别范围里至少有一个要大于等于客体的安全级别）。另外，该主体还需要有 “部分可信主体属性” t1=mlsfilewritetoclr

如果高级别主体想要往低级别客体进行写操作，即 l1 dom l2(这里其实就是 l1 > l2，没有等于，应为如果有等于，则在 l1 eq l2 的时候便会判断通过了)，这是在最初的 BLP 模型中就是禁止的。想要进行此操作需要额外条件 h1 domby h2，可以这样理解：最初的 BLP 模型中所说低级别主体可以向高级别主体写，所以虽然现在主体的低安全级别大于了客体的低安全级别，那么只要主体的高安全级别小于客体的高安全级别那也可以放行(客体的安全级别范围中至少有一个要大于等于主体的安全级别)。另外，该客体还需要有 “部分可信客体属性”，这里因为向下写是将信息泄露到下级客体，所以需要客体可信。

上面两条都不满足的话，如果主体具有 “完整的可信主体写属性”，或者客体具有 “可信客体属性”，那么也允许写。

从上面可以看出如果主体想要进行特权操作，仍然需要安全级别范围满足一定条件，并且具有“部分可信”的属性，满足最小特权原则。