ORCON
摘要
ORCON是基于客体（或其包含的信息）的创建者的访问控制。这种访问控制的目标是允许客体（或其所包含的信息）的创建者控制信息的传播。客体的创建者可能并不是客体的拥有者。ORCON是MAC和DAC的组合，基本规则是：客体的所有者不能更改客体的访问控制。当一个客体被复制时，该客体的访问控制限制被复制并绑定到该客体的副本。创建者可以根据每个主体和每个客体更改访问控制限制。PAC是实现ORCON的一种较为理想的方式。
1. ORCON的缘起
ORCON的提出源于下面这个问题：如果客体的创建者想在客体被分发后，仍然保持着对此客体的控制权，那么我们应该采取什么样的措施来满足这种需求？由于传统的强制访问控制（MAC）和自主访问控制（DAC）不能满足这种需求，Graubert制订了一项名为ORCON或ORGCON（Originator Controlled Access Control，创建者控制访问控制）的安全策略。在这项策略下，一个主体只有在客体的创建者同意的条件下才能将对该客体的权限转交给另一个主体。
例如：国防部长起草了一份政策文件，并发给他的秘书征求意见。未经部长许可，秘书不得将文件发给其他人。也就是说，部长控制文件的分发。这种策略就是ORCON。
2. 为什么MAC和DAC不能解决ORCON问题
实际上，一个客体的创建者是一个组织，而不是一个单独的个体。客体的一个单独的作者不控制信息的分发，代表客体创建者的组织才控制信息的分发。
假设一个主体s（s属于S）代表组织X将一个客体o(o属于O)标记为ORCON。组织X允许客体o被发放给另一个代表组织Y的主体，但要遵守以下限制：
（a）未经X的许可，客体o不能被发放给代表其他组织的主体。
（b）o的任何副本必须具有相同的限制。
自主访问控制无法满足上述限制条件，因为客体的拥有者可以设置所需的任何权限，X不能执行条件（b）。
强制访问控制在理论上可以满足上述限制条件，但实际上存在一个严重的问题：没有将包含o，X和Y的单独类别C与其他主客体关联起来。如果一个主体y（y属于Y）希望读o，则x（x属于X）将创建一个o的副本\(o^{'}\)。副本\(o^{'}\)在C中，所以除非z（z属于Z）也在C类中，否则y不能赋予z对\(o^{'}\)的访问权限。
假设组织W的一个成员w想要给组织Y的成员提供文档d的访问权限，但该文档不会与组织X或Z的成员共享。因此，d不能在C类中，因为如果它在C类中，成员x（x属于X）和z（z属于Z）可以访问d。所以，必须创建另一个包含d、W和Y的类别。成千上万种的成员间的关系和大量的文件，将会产生大量的类别，类别数量过多，可行性太低。
强制访问控制的另一个问题来自abstraction。使用类别（categories）的组织根据“need to know”的基础授予个人访问权限。有一个正式的书面政策，根据共同特征和限制确定谁需要访问权限。这些限制适用于非常高的级别（国家，企业，组织等）。这需要一个中央交换所来进行分类。建立强制执行ORCON的类别意味着对类别进行单独的控制而不是进行集中的控制，并且使用规定每个分区谁可以访问的一组规则。
ORCON不提取这些内容。ORCON是一个分散的访问控制系统，其中每个创建者都决定谁需要访问数据。没有一套集中的规则控制对数据的访问;访问由创建者完全自行决定。因此，用MAC实现ORCON的需求并不合适。
3. ORCON是如何实施的
实现ORCON的方案是结合MAC与DAC，基本规则如下：
-
客体的拥有者不能更改客体的访问控制权限。
-
当一个客体被复制时，该客体的访问控制权限也被复制并绑定到复制后的客体。
-
创建者可以根据每个主体和每个客体更改访问控制权限。
前两条规则来自MAC，它们说明系统控制着所有访问，并且没有人可以改变管理访问这些客体的规则；第三条规则来自DAC，并赋予创建者决定谁可以访问该客体的权力。因此，这种混合方案既不是MAC也不是DAC。
这里需要注意的是，与客体相关的访问控制在客体的创建者，而不是客体的拥有者的控制之下。拥有意味着只有部分控制。只有当客体的创建者允许时，客体的拥有者才可以决定给谁访问。客体的拥有者不能凌驾于客体的创建者之上。
在1989年美国国家计算机安全大会上，Graubert提出了一个称为PAC（Propagated Access Control）的解决方案，PAC兼具了MAC和DAC的一些特征。与DAC相似的是，PAC可以在一个PAC列表（PAC list或称PACL）中以列表形式保存。PACL（类似于ACL）与客体相关联，独立于与客体关联的敏感性标签。因此，像DAC一样，PAC可以根据主体/客体进行调整。与控制读和写的ACL不同，PACL仅用于控制读，因为ORCON问题是一种uncontrolled的读。
DAC和PAC之间的另一个区别是，有权更改PACL的唯一用户是PACL的创建者，而不是与PACL相关联的客体的拥有者。为了使创建者能够改变客体的PACL，创建者的身份必须与该客体相关联。
PACL（及其相关的访问控制限制）最重要的特征是PACL（及其相关的访问控制限制）传播到新的客体。只要一个合法的主体读取客体，客体的PACL就会与主体相关联。任何由主体创建的新客体都会获取主体的PACL。在这方面，PACL类似于同样用于传播的Compartmented Mode Workstations（CMW）的浮动信息标签。这说明了PACL和传统ACL之间的另外两个不同之处。首先，ACL只与客体相关联；PACL与主体和客体相关联。其次，PACL传播到客体和主体，传统的ACL不会传播。只要主体/客体包含数据，PACL就会与主体和客体保持一致。
为了更好地理解PACL的使用，下面我们举一个例子。
创建者X（通过它的代表主体x）创建客体A并将PACL与客体A相关联。PACL告诉我们X是PACL的创建者，并且只有主体y（代表接收者Y）可以读取该客体。那么，以下命题成立：
-
主体y读取客体，从而，PACL与客体y相关联。
-
如果主体y创建新的客体C，则PACL与客体C关联。
-
虽然主体y可能是客体C的所有者，但它不是PACL的创建者。因此，它不能更改PACL，因此不能给任何其他主体读取客体C的访问权限。
-
但是，因为y是客体C的所有者，所以y仍然可以对客体C施加额外的基于DAC的读取限制以及基于DAC的写入限制。
请注意，PACL可能会合并。
让我们继续当前的例子，现在我们假设某个主体w（代表创建者W）创建客体B并将PACL与客体B相关联。该PACL告诉我们只有主体y和z可以读取客体B。为了避免混淆，我们将该PACL称为PACL_W（与客体A相关的PACL称为PACL_X）。已经读取客体A的主体y现在读取客体B。自然PACL_W将与主体y相关联。但是，PACL_X已经与主体y相关联。因此，这两个PACL会一起进行“与”运算，并将生成的PACL（称为PACL_XW）与主体y相关联。PACL_XW由PACL_X和PACL_W共同的主体组成（本例中为主体y），并列出两个创建者（本例中为W和X）。随后由主体y创建的任何客体都将具有与其关联的PACL_XW。这是合理的，因为主体y包含来自X和W的ORCON数据，因此需要两个主体（创建者）的许可才能将数据发送到任何新主体。
PAC机制的一个后果是由主体创建的所有后续客体都会获取主体的PACL。在某些情况下，这不是我们想要的，我们希望的是，只要主体包含引起PACL建立的ORCON数据，PACL就会传播到新客体。在UNIX下，有一种实现我们期望的方式。在UNIX下，由进程表示的主体被fork和exec命令赋予生命。fork命令从初始进程（父进程）创建一个新进程，并且该新进程是原始进程的副本。exec命令清除新进程的地址空间（消除进程的所有内存），并将其替换为由exec指定的新代码体。与进程关联的PACL表示当前进程地址空间中的数据。当清除进程空间时（由exec执行），关联的PACL被替换为与exec中指定的代码体关联的PACL。如果执行代码体的PACL为空，则新进程的PACL设置为空。