如何理解安全模型中低级别的进程可以写入到高级别的客体，但不能读呢？

kerryxi

学习SELinux中，了解到一个最基本的Bell-La Padula模型，其中描述如果进程当前的安全级别优于客体的安全级别，进程则可以"读取"客体。如果低于客体的安全级别，则可以"写入"客体，因此，同时读写客体只要这两个安全级别相等就可以了。



这里的安全体系的含义是什么？安全模型中低级别的进程可以写入到高级别的客体，但不能读呢？ 而高级别的进程只能读低级别的客体，但不能写呢？

谢谢！

beyondfly

最近学习SELinux的人有点多啊

mnipxh

防止窃取信息吧。
A低级别，B高级别
a不能读b，是为了防止泄露b已经读取的机密信息，好理解。
b不能写a，是为了防止b主动将机密信息透露给低级别的a，就酱。
相同级别的就随便搞好了。

windows下也是这套东西。
这个理论实践起来有点麻烦。
之前windows下用输入法启动cmd修改密码就是这样的，
输入法低级别，可以写，以写，写
。。。你懂的。

kiongf

假设你是神盾局的特工，级别为7级。你有九头蛇的机密信息，你只能报告(写)给高你级别的特工。但高级特工有权读你的信息，dan他并不会共享他的机密给你。因为他可能掌握高你一级，高你两级特工机密。写给你就意味泄露了其他高级特工的机密。
这是MLS机制.no read up. No write down

kerryxi

回复 4# kiongf


    谢谢,有一点点道理.

    做为信息来讲, 这个模型是有道理的. 低级别的要只能向高级别的汇报(写), 但不能看(读). 高级别的只能不能写低级别(泄密),但能够看低级别的信息(读).

    不过, 做为计算数据来说, 如果低级别的主体写高级别的, 不也违反了安全条例吗? 假如低级别的随意篡改高级别的机密数据, 或者安装一个木马等, 不就麻烦吗?    实际问题就是低级别的user怎么能够写root级别的文件数据呢?  应该是低级别不能读,也不能写高级别的客体才对啊.

     好像哪里理解还有问题.

kiongf

嗯。我理解你的疑问。我对也有疑问。主要是对这个读操作的疑问，读目录算不算读？如果算的话，那么是否可以理解为某个安全级别的进程被约束只能在同级别或者低级别的目录中。这样进程就无法写到高级别目录中。也就不会出现你所说的篡改高安全级别文件的可能性。
这只是我的猜测。需要验证下DAC下能否直接穿过不可读目录修改其中的文件。
希望你理解后，能够分享下心得。我在裁剪selinux的时候看到MLS用于政府军事机密就直接移除了，没往太深研究

注:已确认，DAC下进程无法穿过无读权限的目录，直接写入目录中的文件。因此很大可能性，低级别的用户只能在部分目录下活动，不会出现你所说篡改高机密文件的可能性

beyondfly

回复 6# kiongf


    SELinux中有一个dac_override的权限，进程有了这个权限以后，就不受DAC的限制了，比如，普通用户之间可以相互访问家目录

kerryxi

你的穿透试验是被DAC先挡住了,所以 "DAC下进程无法穿过无读权限的目录，直接写入目录中的文件". 此时还没有到达DAC的机制运作.

对于安全模型的安全级别, 还有一个疑问, 就是除了root用户之外, 我觉得DAC是没有安全级别的区分的,只有不同用户的区分. 只要用户相同或者属于某个GROUP,就可访问,不是就不能访问.  没看到哪里有安全级别的高低的说法.

另外, 对于SELINUX的MAC来说, 也没看到哪里有安全级别的高低之分, 我看到的只是type类型是否一致,如果一致就可访问, 不一致就不能访问. mac只是定义了一些policies, policies没看到分安全的等级.

所以, 对于安全模型中的安全级别High和low的区分, 不知道在DAC和MAC中怎么应用的.

beyondfly

回复 1# kerryxi


    这个模型，说白了就是禁止上读下写，即禁止低级别的主体读高级别的客体信息，禁止高级别的主体往低级别的客体写数据。这个模型适用于军方都场合。在SELinux中，就是MLS这一特性了，在Linux中，kernel_t都是高级别的主体，级别为s15

kiongf

回复 8# kerryxi


    我觉得你可以搞混了。 MLS是属于MAC机制，不属于DAC机制。 DAC本身就没有安全级别这一说。它只由文件拥有者决定其他用户的权限(当然root用户是个特例）。
   
   
   SELinux起源于自1980年开始的微内核和操作系统安全的研究，最终形成一个叫做分布式信任计算机(Distribute Trusted Mach(DTMach))的项目。美国过安全局的研究组织参与了DTMach项目，付出了巨大努力，并且参与了大量的后续安全微内核研究。最终，这些工作和努力导致了一个新项目的诞生，那就是Flask。
MLS只定位于数据保密性而并不关心数据完整性和最小权能原则（Least Privilege），以及对进程的能力进行分类.

  我从资料上看到，MLS远在80年代就开始研究了，比SELinux, FLASK要早得多。开始针对于对进程能力进行分类，应该是FLASK架构的出现。 所以我觉得MLS是最初通过和DAC配合一起实现的。当然只是我的猜想。

  如果你系统上使用的安全策略打开了MLS选项，你查看进程或者是文件的security context应该是这种形式：
       system_u：object_r:bin_t:s0             ----        s0就是和MLS有关的敏感度。
  Reference policy打开MLS的选项在源码树/build.conf中。

至于安全级别的实现可以查看这个函数:
  security/selinux/ss/context_struct_compute_av()
649         avkey.target_class = tclass;
650         avkey.specified = AVTAB_AV;
651         sattr = flex_array_get(policydb.type_attr_map_array, scontext->type - 1);
652         BUG_ON(!sattr);
653         tattr = flex_array_get(policydb.type_attr_map_array, tcontext->type - 1);
654         BUG_ON(!tattr);
655         ebitmap_for_each_positive_bit(sattr, snode, i) {
656                 ebitmap_for_each_positive_bit(tattr, tnode, j) {
657                         avkey.source_type = i + 1;
658                         avkey.target_type = j + 1;
659                         for (node = avtab_search_node(&policydb.te_avtab, &avkey);
660                              node;
661                              node = avtab_search_node_next(node, avkey.specified)) {
662                                 if (node->key.specified == AVTAB_ALLOWED)
663                                         avd->allowed |= node->datum.data;
664                                 else if (node->key.specified == AVTAB_AUDITALLOW)
665                                         avd->auditallow |= node->datum.data;
666                                 else if (node->key.specified == AVTAB_AUDITDENY)
667                                         avd->auditdeny &= node->datum.data;
668                         }
669
670                         /* Check conditional av table for additional permissions */
671                         cond_compute_av(&policydb.te_cond_avtab, &avkey, avd);
672
673                 }
674         }
675
676         /*
677          * Remove any permissions prohibited by a constraint (this includes
678          * the MLS policy).
679          */
680       constraint = tclass_datum->constraints;
681         while (constraint) {
682                 if ((constraint->permissions & (avd->allowed)) &&
683                     !constraint_expr_eval(scontext, tcontext, NULL,
684                                           constraint->expr)) {
685                         avd->allowed &= ~(constraint->permissions);
686                 }
687                 constraint = constraint->next;

这个函数是内核用来检测是否有个授权规则是否存在（也就是一次存取操作是否合法）。
  655-668行就是检测 是否存在匹配source type/targe type/class/permission的allow规则
  如果匹配，还需要经过constraint的检测。 constraint权力比allow大，即使你定义了allow规则，允许init_t域访问bin_t类型的文件，
  但constraint禁止了，allow规则就无效了。
  constraint的信息来源于policy language的constraint语句和mls_constraint(顾名思义，这个就和MLS有关).
  安全级别的检测就是通过mls_constraint语句实现的。